SCTP Многодомность выпуск

Question

Мы разработали многосетевое приложение в настоящее время во время тестирования моих настроек является:

ETH4 в качестве основного интерфейса подключена спиной к спине на другую машину. Eth5 как вторичный интерфейс, подключенный обратно к другой машине.

я сделать мой porimary интерфейс вниз сейчас, когда INIT будет отправлен он достигает всматриваться машины, кажется, используя вторичный интерфейс, но источник IP адрес хранится имеет первичный интерфейс только из-за которого, когда сверстников машина пытается ответить INIT_ACK он пытается отправить на первичный интерфейс ip, который не работает, и из-за ICMP он выдает пакет.

Я не слишком хорошо разбираюсь в маршрутизации, но кажется, что какая-то маршрутизация не была настроена правильно, почему она всегда использует первичный ip?

Я тестировал ту же самую часть, когда я подключил свой первичный & вторичный интерфейс через маршрутизатор, но с той же проблемой.

Answer 1

В интересах всех, я только что коснулся нескольких пунктов, прежде чем подойти к главному пункту.

Конечная точка SCTP может иметь более одного IP-адреса. То есть приложение может открывать SCTP-сокет и связывать выборочный набор адресов или всех IP-адресов с этим сокетом. Ассоциация в SCTP находится между двумя конечными точками. Конечные точки SCTP должны обмениваться списком IP-адресов, чтобы каждая конечная точка могла получать сообщения с любого из адресов в другой конечной точке. Обмен списком IP-адресов выполняется во время начала объединения. Тем не менее, SCTP должен использовать один IP-адрес в качестве первичного адреса для связи, а другие IP-адреса должны использоваться для повторной передачи в случае непрерывного отказа отправлять данные или контрольные куски.

Из RFC4960 (SCTP) вы заметите, что «во время инициирования ассоциации, если в принимаемом INIT присутствует параметр Host Name, конечная точка должна разрешить это имя узла в список IP-адресов (адресов) и получить транспортный адрес (ы) этого партнера, объединив разрешенный IP-адрес (ы) с портом источника SCTP. "

Однако ключевой момент от RFC4960 (SCTP) - это важность времени для разрешения имени хоста на IP-адреса. В нем говорится, что «в случаях, когда перевод имен предполагает потенциальную длительную задержку, получатель INIT ДОЛЖЕН отложить разрешение имени до получения куба COOKIE ECHO от партнера. В этом случае получатель INIT СЛЕДУЕТ построить State Cookie с использованием полученного имени хоста (вместо транспортных адресов назначения) и отправьте INIT ACK на исходный IP-адрес, из которого был получен INIT ».

Если мы рассмотрим ваш сценарий только из приведенной выше информации: Учитывая, что основной интерфейс сбрасывается после отправки INIT-фрагмента и предполагается, что время для разрешения имени хоста на IP-адреса занимает слишком много времени на сервере , можно предположить, что INIT-ACK отправлен на IP-адрес источника (первичный интерфейс), из которого был получен INIT.

Однако, если вы внимательно прочитали RFC SCTP, в RFC4960 (SCTP) содержится явная заметка о INIT-ACK, в которой утверждается, что «INIT ACK ДОЛЖЕН быть отправлен на исходный адрес INIT». См. RFC3286 (SCTP), который, как представляется, передает его как механизм защиты, поскольку он утверждает, что «поскольку INIT ACK всегда возвращается к исходному адресу INIT, слепой атакующий не получит Cookie."

Теперь, если мы рассмотрим ваш сценарий, принимая во внимание вышеприведенную информацию: Ясно, что сервер всегда будет отправлять ответ INIT ACK chunk на исходный адрес, который был в IP-заголовке INIT.