Проблема многоадресности SCTP

Мы разработали многосетевое приложение сейчас, пока тестируем мою настройку:

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

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

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

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


sctp
person user3553856    schedule 01.10.2014    source источник

Ответы (1)


arrow_upward
2
arrow_downward

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

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

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

Однако ключевым моментом RFC4960 (SCTP) является важность времени для преобразования имени хоста в IP-адреса. В нем говорится, что «в случаях, когда преобразование имени связано с потенциально большой задержкой, получатель INIT ДОЛЖЕН отложить преобразование имени до получения фрагмента COOKIE ECHO от партнера. В таком случае получатель INIT ДОЛЖЕН построить Укажите файл 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 на исходный адрес, который был в IP-заголовке INIT.

person Karthik Balaguru    schedule 11.10.2014