Odpowiedź VPN między lokalizacjami nie przechodzi przez tunel

Spędziłem przedpołudnie nad tunelem, który podniósł się czysto i przenosił ruch dokładnie w jednym kierunku: oddział docierał do serwera plików w centrali, a każde połączenie otwarte z centrali do oddziału ginęło na pierwszym SYN. SA były aktywne, liczniki tunelu rosły, a uzgadnianie nigdy nie było problemem. Odpowiedź była trasowana gdzieś, czego tunel nie obejmuje, i ten wybór należy do drugiej strony. VPN między lokalizacjami przenosi tylko pakiety, które host przekazuje bramie, i każdy host podejmuje tę decyzję osobno, w każdym kierunku, z własnej tablicy routingu.

Oba kierunki są trasowane osobno

IP nie pamięta kierunku rozmowy. Każdy host, który wysyła pakiet, wykonuje własne wyszukiwanie najdłuższego prefiksu, wybiera jeden następny skok i zapomina decyzję. Żądanie i odpowiedź to dwa niepowiązane pakiety, które przypadkiem należą do tego samego połączenia, a tunel to jeden skok, którego każde z nich może użyć albo nie. Nic w wymianie IKE nie uczy zdalnego serwera, jak dotrzeć do twojej podsieci; negocjacja zgadza się tylko co do tego, które prefiksy mogą być szyfrowane.

To porozumienie jest drugą bramą. W strongSwan selektory ruchu to leftsubnet i rightsubnet, a pakiet, którego źródło lub cel wypada poza uzgodnioną parę, nie jest szyfrowany, cokolwiek mówi tablica routingu. Prefiks trasowany do tunelu, ale nieobecny w selektorach, to cicha jednostronna awaria: trasa wygląda dobrze, pakiet i tak wychodzi jawnie albo jest odrzucany, i tylko dziennik charona się skarży.

Zdalny host nie wie nic o twoim tunelu

Wewnątrz zdalnej sieci LAN odpowiedź jest zwykłym pakietem zaadresowanym do twojego klienta. Host docelowy nie widzi nagłówka IPsec i nie ma powodu preferować bramy VPN; szuka twojego prefiksu, nie znajduje niczego konkretniejszego niż swoja trasa domyślna i podąża nią. Jeśli trasa domyślna wskazuje główny firewall, firewall albo ma trasę z powrotem do tunelu, albo nie. Gdy nie ma, dostajesz ciche odrzucenie, ICMP unreachable albo odpowiedź, która wychodzi interfejsem od strony internetu i ginie.

Drugi interfejs wystarczy, by to zepsuć, nawet gdy trasa istnieje. NAS z łączem zarządzania w innym VLAN, serwer z zapasowym uplinkiem, reguła polityki wysyłająca jeden zakres źródeł do drugiej tablicy: każde z tego może przechwycić odpowiedź. W Linuksie ip rule show i ip route show table all pokazują reguły i tablice, które domyślna lista ukrywa.

Przeczytaj decyzję na maszynie, która wysyła odpowiedź

Zapytaj jądro, zanim cokolwiek zmienisz, i podaj mu adres źródłowy, bo reguły zależne od źródła zmieniają odpowiedź.

ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"

Wynik podaje interfejs wychodzący i następny skok. Jeśli interfejs nie jest tym zwróconym do bramy VPN, znalazłeś usterkę, a pozostała praca to wybór, gdzie powinna być trasa. Ping z bramy niewiele tu dowodzi: odpowiada adresem, który zdalny host potrafi umiejscowić, a nie adresem twojego laptopa.

W Windows odpowiednikami są Find-NetRoute -RemoteIPAddress 10.10.5.10 dla decyzji i Get-NetRoute dla tablicy. Trasa dodana przez New-NetRoute z wyższą metryką niż domyślna przegrywa po cichu, więc czytaj kolumnę metryki, nie wpis. Potem potwierdź pakietami: tcpdump -ni any "host 10.10.5.10 and tcp port 445" na zdalnym interfejsie LAN pokazuje żądanie, a ten sam filtr po stronie tunelu pokazuje, czy wróciła odpowiedź. Żądanie widoczne bez odpowiedzi oznacza, że odpowiedź została zatrasowana gdzie indziej albo odrzucona; odpowiedź na niewłaściwym interfejsie daje ci winnego, zanim dotkniesz trasy.

Gdy brama serwera nie jest punktem końcowym VPN

Wiele lokalizacji stawia firewall między serwerami a koncentratorem. Ten firewall przekazuje odpowiedź, więc potrzebuje trasy dla prefiksu twojego klienta wskazującej bramę VPN oraz polityki przekazywania w obu kierunkach. Urządzenia stanowe pogarszają sprawę: żądanie przeszło przez firewall od hosta LAN, któremu pozwolił, odpowiedź przychodzi teraz z innego kierunku, a wpis śledzenia połączeń już nie pasuje, więc pakiet jest odrzucany jako nieprawidłowy, a nie jako zabroniony. Dlatego dziennik polityki wygląda na pusty, gdy ruch znika.

Brama ma własny drugi filtr. Filtrowanie odwrotnej ścieżki w Linuksie odrzuca pakiety, których źródło nie jest osiągalne przez interfejs, którym przyszły, i to jest dokładnie kształt legalnej asymetrycznej ścieżki powrotnej. przewodnik strongSwan po przekazywaniu wymaga właśnie dlatego net.ipv4.ip_forward i poluzowanego net.ipv4.conf.all.rp_filter. Ścisła wartość 1 na którejkolwiek bramie po cichu psuje poprawną trasę, a nstat -az pokazuje odrzucenia, jeśli wiesz, gdzie patrzeć.

Trasuj albo tłumacz, a potem zweryfikuj w obu kierunkach

Dwie naprawy nie są równoważne. Dodanie trasy zostawia adres klienta nietknięty, więc reguły oparte na źródle, dzienniki audytu i aplikacje zapisujące wywołującego nadal działają; ceną jest to, że każdy skok podejmujący decyzję potrzebuje trasy, czyli więcej miejsc na błąd. Maskowanie na zdalnej bramie zwija ścieżkę powrotną do jednego skoku, bo odpowiedź jest teraz adresowana do samej bramy, i ukrywa, który klient co zrobił.

iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADE

Wybierz to świadomie: gdy klienci zaczną pojawiać się jako adres bramy, ACL oparte na źródle przestają ich rozróżniać, a conntrack musi utrzymywać mapowanie, żeby odpowiedź została zapisana z powrotem do tunelu. Jeśli selektory nadal wykluczają prefiks klienta, NAT nic nie zmienia, bo żądanie nigdy nie weszło do tunelu.

Zanim uznasz to za naprawione, potwierdź cztery rzeczy po kolei: trasę na hoście, który wysyła odpowiedź, trasę na każdym skoku, który ją przekazuje, selektory obejmujące oba prefiksy i zapis pokazujący, że odpowiedź wchodzi do tunelu z oczekiwanym źródłem. Potem powtórz test z drugiej lokalizacji. Jeden przechodzący kierunek to projekt na wpół otwarty, a drugi kierunek zwykle zawodzi z innego powodu niż ten, który właśnie naprawiłeś.