У меня есть туннель IPsec, работающий (чистый IPsec, без L2TP / GRE с использованием strongswan 5.5.1) на экземпляре Debian 9 VPS.
В настоящее время это только IPv4, поэтому net.ipv4.ip_forward установлен на 1 в sysctl.
Клиенты могут успешно подключаться к удаленному экземпляру через Интернет, используя общедоступный IP-адрес сервера.
Адрес удаленного узла установлен на A.B.C.1 с участием /etc/network и клиенты получают адреса из подсети A.B.C.0/24 (начиная с A.B.C.2) выше, который установлен в ipsec.conf. Я могу пинговать сервер со стороны клиента, используя его IP-адрес в этой подсети.
Дело в том, что интернет-трафик не может быть маршрутизирован через туннель (проверка выполняется путем отправки ICMP на 8.8.8.8 через туннель ipsec). Меня очень беспокоит мой iptables-fu, но я действительно потратил кучу времени, чтобы понять, что не так, и все равно не добился успеха.
Вот правила из моего filter цепочка iptables:
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p esp -j ACCEPT
-A INPUT -p ah -j ACCEPT
-A INPUT -p udp -m udp --dport 500 -j ACCEPT
-A INPUT -p udp -m udp --dport 4500 -j ACCEPT
-A FORWARD -s A.B.C.0/24 -m policy --dir in --pol ipsec -j ACCEPT
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
COMMIT
И nat цепочка:
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A POSTROUTING -s A.B.C.0/24 -o <public interface> -m policy --dir out --pol ipsec -j ACCEPT
-A POSTROUTING -s A.B.C.0/24 -o <public interface> -j MASQUERADE
COMMIT
Когда я пытаюсь передать несколько запросов tcpdump дает мне следующие строки:
18:32:21.884250 IP my.local.ip > server.public.ip: ESP(spi=...,seq=...), length 104
18:32:21.884250 IP A.B.C.2 > 8.8.8.8: ICMP echo request, id 34822, seq 1024, length 30
18:32:21.884282 IP server.public.ip > 8.8.8.8: ICMP echo request, id 34822, seq 1024, length 30
По-видимому, либо iptables сбрасывает запрос на 8.8.8.8 или его ответ где-то теряется, потому что не может быть направлен обратно клиенту IPsec.
Как я могу правильно направить трафик или, по крайней мере, определить причину проблемы?
Спасибо.
Конечно не может. Согласно вашей первоначальной информации, вы используете режим IPSec на основе политик, который также называется наследие IPSec. В этом случае только трафик, соответствующий политики безопасности - SP - перенаправляется на удаленный шлюз безопасности. Что печальнее и важнее - это не направлен, он хирургическим путем удаляется из обычного потока пакетов вашей ОС и пересылается через туннель. Таким образом, в этом случае вам необходимо описать весь трафик, который вы хотите пройти через туннель, в ваших политиках - и - предупреждение о спойлере - обычно это технически невозможно.
Так вот причина Зачем эта установка называется наследие - в большинстве случаев вам нужен режим маршрутизации IPSec, поэтому вы либо используете режим VTI в своем стеке, либо используете промежуточный интерфейс маршрутизации с промежуточной инкапсуляцией, например GRE, - поэтому в ваших политиках вы только описываете соответствующий трафик как GRE-трафик между локальным и удаленным концом туннеля (с обеих сторон), а вы просто используете маршрутизацию.
VTI, с другой стороны, не использует промежуточную инкапсуляцию и является чисто интерфейсом IPSec.
Оба подхода поддерживаются strongswan.
К сожалению, процедура настройки этих методов выходит за рамки этого ответа, однако я дал достаточно шаблонов для поиска в Google (кажется, это простая задача).