Racoon на Linux - начальная потеря пакетов
Я настроил два блока Linux, чтобы они автоматически использовали IPSec-соединение транспортного уровня всякий раз, когда им нужно обмениваться данными. Конфигурация основана на Racoon с аутентификацией X509 и bundle_complex опция установлена в on, а также политики, которые требуют как ESP, так и AH между двумя полями.
Хотя конфигурация работает, вообще говоря, первые несколько пакетов всегда теряются, например:
$ ping -c 3 A.B.C.D
PING A.B.C.D (A.B.C.D) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
64 bytes from A.B.C.D: icmp_req=3 ttl=64 time=0.497 ms
Есть ли способ предотвратить это, например, "задерживая" пакеты до согласования транспорта IPSec?
2 ответа
Первый пакет (и все остальные до завершения согласования) всегда отбрасывается.
Это верно для каждой реализации ISAKMP, с которой я имел дело. Я не верю, что есть какая-то причина, по которой он не может буферизовать отбрасываемые пакеты; скорее, не должно.
Это расширение осознанного проектного решения, которое используется во всей инфраструктуре маршрутизации Интернета: не удерживайте пакеты.
Системы маршрутизации в Интернете всегда отбрасывают пакет, а не задерживают его, когда они не могут (почти) немедленно направить его. Потери пакетов в Интернете в целом можно легко снизить до гораздо более низких уровней, просто храня пакет в буфере до тех пор, пока для него не останется места. Но в этом и заключается проблема; перегруженный маршрутизатор, работающий на 200 мс в очереди "первым пришел - первым вышел", задержал бы каждый отдельный пакет на эти 200 мс.
Возвращение к ситуации ISAKMP; удерживать пару пингов до тех пор, пока путь не будет готов к их переносу - это прекрасно, но что если это постоянный поток из сотен тысяч пакетов UDP? А что, если удаленная система недоступна, поэтому ISAKMP сидит и ждет сообщения согласования ISAKMP 2 в течение 60 секунд?
Хотя они не являются непреодолимыми инженерными проблемами, общепринятым мнением в интернет-сообществе инженеров является то, что клиентским системам гораздо проще и проще самим решать проблемы с потерей пакетов, в основном за счет использования устойчивых к потерям протоколов, таких как TCP.
Вы можете автоматически запустить туннель IPSEC до того, как начнется поток трафика (обычно эти первые отброшенные пакеты инициируют согласование IKE). Вот как это сделать с помощью StrongSwan:
auto = ignore | add | route | start
what operation, if any, should be done automatically at IPsec
startup; currently-accepted values are add, route, start and
ignore (the default). add loads a connection without starting
it. route loads a connection and installs kernel traps. If
traffic is detected between leftsubnet and rightsubnet , a con‐
nection is established. start loads a connection and brings it
up immediatly. ignore ignores the connection. This is equal to
delete a connection from the config file. Relevant only
locally, other end need not agree on it (but in general, for an
intended-to-be-permanent connection, both ends should use
auto=start to ensure that any reboot causes immediate renegotia‐
tion).
Хотя я до сих пор не понял, как сделать то же самое с енотом, но, думаю, должно быть что-то подобное.