"IPsec для любознательных, ч.2 ответы на вопросы"
Ровно неделю назад написал вот этот псто.
Большое спасибо всем за ответы! Много очень толковых мыслей. Я прям очень-очень рад, что читатели такие умнички!
Отдельное огромное спасибо уважаемым klink0v и vovin.
Так вот, по завершению дебага, выяснилось, что ларчик открывался крайне хитрожопо и весьма неожиданно.
Если опустить все особенности IPsec-а, то в сухом остатке мы имеем непроходимость IKE-пакетов из Минска в Москву.
Причем, не всяких, а именно КРУПНЫХ.
Изначально стояла авторизация по сертификатам - соответственно, пакеты были большие.
И вот, 2-го апреля совершенно внезапно "сломалось".
Техпод провайдера оказался, как чаще всего и бывает - крайне лаконичен и совершенно бесполезен:
"Мы не советуем нашим абонентам использовать VPN".
Я продебажил и в качестве "костыля" поставил авторизацию по PSK - всё опять "взвилось".
Окей, теперь осталось выяснить, в чем же именно дело.
Тест MTU в обе стороны никаких проблем не показал - 1500, всё по фен-шую.
Лирическое отступление.
"Половина знания - хуже незнания." © неизвестный автор.
Есть такая штука, как сетевые атаки "teardrop" и "bonk".
Здесь рассматривать их не буду, это долго. Кому интересно - подчитайте.
Если кратко - посылается пакет, предполагающий фрагментацию (флаг MF = 1) с особым содержимым.
Так вот, не мудрствуя лукаво, некоторые тупые и/или рукожопые инженеры просто и тупо запрещают прохождение UDP-пакетов с флагом MF = 1.
Как вы догадались, тут был именно такой случай.
Как это говно диагностировать?
Последовательно и симметрично проделываем следующее:
Включаем tcpdump и посылаем на него пакет, например командой:
sendip -p ipv4 -is source_address -p udp -us 5600 -ud 51423 -d r3000 -v destination_address
Мы должны наблюдать прохождение.
А теперь - момент истины. Посылаем еще один пакет, но с флагом MF:
sendip -p ipv4 -is source_address -p udp -us 5600 -ud 51423 -d r3000 -v destination_address -ifm 1
Если этот пакет не дошел - ЭТО ОНО.
Важный нюанс: согласно RFC, если пришел пакет с "MF = 1" стек ждёт последний пакет БЕЗ флага MF, после этого "собирает" их и отдаёт приложению.
Именно поэтому - слушать надо строго на "железном" интерфейсе железного сервера с прямым белым IP-адресом. Гипервизоры - реассемблят пакеты.
Посылать же можно откуда угодно, хоть из-за NAT-а. (Исходящий порт при этом может измениться, это - нормально).
Собрав эти данные, я вспомнил, что в этом провайдере кучу лет назад работал инженер, с которым у нас был "пивной уровень знакомства".
Написал ему письмо.
О, чудо! Он до сих пор там работает и даже готов помочь.
Описал ситуацию. Ну, разумеется - "они ничего не делали" в плане фильтрации. Но: переключали аплинки как раз в районе 1 или 2 числа.
Мы провели с ним эксперимент - переключились на другой аплинк. Вуаля - всё заработало.
Далее тривиально, он написал письмо в аплинк с детальным описанием ситуации. И, как ни странно, аплинк сегодня всё исправил.
После окончания работ и проверок, товарищ меня спросил:
"хотел поинтересоваться тебя вообще не интересует поработать у нас на фултайм?"
Учитесь, развивайтесь и старайтесь делать мир лучше.
Это окупается.
__
Большое спасибо всем за ответы! Много очень толковых мыслей. Я прям очень-очень рад, что читатели такие умнички!
Отдельное огромное спасибо уважаемым klink0v и vovin.
Так вот, по завершению дебага, выяснилось, что ларчик открывался крайне хитрожопо и весьма неожиданно.
Если опустить все особенности IPsec-а, то в сухом остатке мы имеем непроходимость IKE-пакетов из Минска в Москву.
Причем, не всяких, а именно КРУПНЫХ.
Изначально стояла авторизация по сертификатам - соответственно, пакеты были большие.
И вот, 2-го апреля совершенно внезапно "сломалось".
Техпод провайдера оказался, как чаще всего и бывает - крайне лаконичен и совершенно бесполезен:
"Мы не советуем нашим абонентам использовать VPN".
Я продебажил и в качестве "костыля" поставил авторизацию по PSK - всё опять "взвилось".
Окей, теперь осталось выяснить, в чем же именно дело.
Тест MTU в обе стороны никаких проблем не показал - 1500, всё по фен-шую.
Лирическое отступление.
"Половина знания - хуже незнания." © неизвестный автор.
Есть такая штука, как сетевые атаки "teardrop" и "bonk".
Здесь рассматривать их не буду, это долго. Кому интересно - подчитайте.
Если кратко - посылается пакет, предполагающий фрагментацию (флаг MF = 1) с особым содержимым.
Так вот, не мудрствуя лукаво, некоторые тупые и/или рукожопые инженеры просто и тупо запрещают прохождение UDP-пакетов с флагом MF = 1.
Как вы догадались, тут был именно такой случай.
Как это говно диагностировать?
Последовательно и симметрично проделываем следующее:
Включаем tcpdump и посылаем на него пакет, например командой:
sendip -p ipv4 -is source_address -p udp -us 5600 -ud 51423 -d r3000 -v destination_address
Мы должны наблюдать прохождение.
А теперь - момент истины. Посылаем еще один пакет, но с флагом MF:
sendip -p ipv4 -is source_address -p udp -us 5600 -ud 51423 -d r3000 -v destination_address -ifm 1
Если этот пакет не дошел - ЭТО ОНО.
Важный нюанс: согласно RFC, если пришел пакет с "MF = 1" стек ждёт последний пакет БЕЗ флага MF, после этого "собирает" их и отдаёт приложению.
Именно поэтому - слушать надо строго на "железном" интерфейсе железного сервера с прямым белым IP-адресом. Гипервизоры - реассемблят пакеты.
Посылать же можно откуда угодно, хоть из-за NAT-а. (Исходящий порт при этом может измениться, это - нормально).
Собрав эти данные, я вспомнил, что в этом провайдере кучу лет назад работал инженер, с которым у нас был "пивной уровень знакомства".
Написал ему письмо.
О, чудо! Он до сих пор там работает и даже готов помочь.
Описал ситуацию. Ну, разумеется - "они ничего не делали" в плане фильтрации. Но: переключали аплинки как раз в районе 1 или 2 числа.
Мы провели с ним эксперимент - переключились на другой аплинк. Вуаля - всё заработало.
Далее тривиально, он написал письмо в аплинк с детальным описанием ситуации. И, как ни странно, аплинк сегодня всё исправил.
После окончания работ и проверок, товарищ меня спросил:
"хотел поинтересоваться тебя вообще не интересует поработать у нас на фултайм?"
Учитесь, развивайтесь и старайтесь делать мир лучше.
Это окупается.
__