Dotarcie do klienta IKEv2 pod jego przydzielonym wirtualnym IP

Brama musi zainicjować połączenie do laptopa połączonego z nią przez IKEv2, używając wirtualnego adresu przydzielonego temu klientowi. Tunel jest podniesiony, klient osiąga wszystko za bramą, a kierunek odwrotny nadal zawodzi. Ta asymetria jest normalna: wynegocjowana polityka opisuje, które adresy mogą rozmawiać, a nie która strona może inicjować. Trzy rzeczy muszą się zgadzać, zanim żądanie zainicjowane przez bramę zacznie działać.

Tunel nie naprawia adresu źródłowego

CHILD SA obejmuje parę selektorów ruchu, po jednym na stronę, i zezwala na ruch w obu kierunkach tej pary. Nie mówi nic o tym, który partner pierwszy otworzył wymianę IKE. Brama, która początkowo nasłuchiwała tunelu, nadal może wysłać pierwszy pakiet aplikacji, pod warunkiem że wybrane źródło i cel mieszczą się w zainstalowanych selektorach. Gdy żądanie wychodzi przez niewłaściwy interfejs, po prostu nie kwalifikuje się do tunelu.

Routing w stronę klienta jest konieczny i niewystarczający. Polityka musi dopuścić źródło, którego faktycznie użyłeś.

Czytaj zainstalowaną politykę, nie plik konfiguracyjny

Zacznij od aktywnego skojarzenia i jego selektorów, ponieważ dynamiczne przydzielanie zmienia to, co jest zainstalowane w jądrze.

ipsec statusall
ip xfrm policy

Wyjście stanu podaje nazwę połączenia, przydzielony adres wirtualny i selektory obecnie obowiązujące dla tego partnera. Zrzut polityki pokazuje te same selektory jako stan jądra, i to właśnie jego faktycznie konsultuje wybór pakietów. Porównaj selektor po stronie bramy ze źródłem, którego użyje twoja aplikacja, ponieważ niezgodność od razu wyjaśnia błąd. Czytaj bieżący adres klienta, a nie adres z poprzedniej sesji, ponieważ ponownie przydzielony VIP unieważnia starą politykę.

Klient musi nasłuchiwać tam, gdzie trafia pakiet

Nawet doskonała polityka trafia na zamknięty port, gdy usługa wiąże się tylko z loopback. Nasłuch musi być na przydzielonym adresie lub na lokalnym adresie wieloznacznym.

ss -ltnp 'sport = :9090'
iptables -S INPUT

Lista gniazd pokazuje, czy port jest powiązany z adresem wirtualnym, a reguły zapory pokazują, czy nowe połączenia są akceptowane z chronionego źródła. Reguła napisana dla nawiązanych połączeń nie wpuszcza połączenia, które inicjuje brama. Zachowaj własne uwierzytelnianie usługi, ponieważ dotarcie przez tunel ustala tylko, z której sieci przyszedł pakiet. Klient za własnym NAT nadal nie potrzebuje przekierowania portu przychodzącego, ponieważ te żądania podróżują wewnątrz istniejącego tunelu.

Przetestuj nowy kierunek osobno

Działające żądanie od klienta do serwera nigdy nie ćwiczy tej ścieżki. Wygeneruj żądanie z bramy i obserwuj oba końce.

ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090

Wyszukiwanie trasy odpowiada, jakiego źródła i interfejsu użyłaby brama, i to jest wartość, którą polityka musi dopuścić. Zapis powinien pokazać, że żądanie wychodzi wewnątrz ESP, a nie jako zwykły TCP na interfejsie publicznym. Na kliencie przechwyć odszyfrowany ruch, aby potwierdzić dotarcie i odpowiedź usługi. Jeśli żądanie znika bez ESP na łączu, podejrzewaj adres źródłowy przed zaporą klienta.

Powtórz test po wymianie kluczy lub ponownym połączeniu, ponieważ VIP może się zmienić. Ścieżka, która działa tylko do następnej sesji, nie jest działającą ścieżką.