Я сконфигурировал два 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?
Вы можете автоматически запустить туннель 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).
Хотя я до сих пор не понял, как сделать то же самое с енотом, но, думаю, должно быть что-то подобное.
Первый пакет (и все остальные до завершения согласования) всегда отбрасывается.
Это верно для каждой реализации ISAKMP, с которой я имел дело. Я не верю, что обязательно есть причина, по которой это не мог буферизировать отбрасываемые пакеты; скорее это не должен.
Это продолжение осознанного дизайнерского решения, которое используется во всей инфраструктуре маршрутизации Интернета: Не держите пакеты.
Системы маршрутизации в Интернете всегда отбрасывают пакет вместо того, чтобы задерживать его, когда они не могут (почти) немедленно направить его. Потери пакетов в Интернете в целом можно легко снизить до гораздо более низкого уровня, просто сохраняя пакет в буфере до тех пор, пока для него не останется место. Но в этом проблема; перегруженный маршрутизатор, работающий на 200 мс в очереди «первым пришел - первым вышел», задержит каждый пакет на эти 200 мс.
Возвращаем это к ситуации ISAKMP; удерживать пару эхо-запросов до тех пор, пока путь не будет готов к их переносу, - это прекрасно, но что, если это постоянный поток из сотен тысяч пакетов UDP? А что, если удаленная система недоступна, поэтому ISAKMP находится в ожидании сообщения согласования ISAKMP 2 в течение 60 секунд?
Хотя это не непреодолимые инженерные проблемы, общепринятое мнение в сообществе интернет-инженеров состоит в том, что гораздо проще и легче заставить клиентские системы самостоятельно решать проблемы потери пакетов, в первую очередь за счет использования устойчивых к потерям протоколов, таких как TCP.