Klient VPN z routingiem dociera do serwera, ale nie do hostów LAN

Klient z routingiem może się połączyć i mimo to tracić każdą odpowiedź od hosta LAN. Dodaj trasę powrotną na bramie, a następnie sprawdź przekazywanie i filtrowanie pakietów.

Tunel się podnosi, klient pinguje serwer VPN, a udział na maszynie o jeden skok dalej nigdy nie odpowiada. Nic w konfiguracji klienta tego nie wyjaśnia, bo żądanie naprawdę opuściło klienta i naprawdę dotarło. Zawiodła droga powrotna, a urządzeniem, które zawiodło, jest zwykle brama LAN, a nie host VPN. Śledzenie pakietu odpowiedzi wyjaśnia całą tę klasę objawów.

Śledź odpowiedź, nie żądanie

Serwer VPN odszyfrowuje pakiet klienta i przekazuje go do LAN, pozostawiając adres klienta w polu źródłowym. Host docelowy odpowiada na ten adres, a teraz o wszystkim decyduje jego własna tablica routingu. Jego brama domyślna nie wie nic o puli tunelu, więc odpowiedź wychodzi w stronę dostawcy internetu i zostaje gdzieś na tej drodze odrzucona.

U klienta objawem jest ciche przekroczenie czasu: brak odmowy, brak resetu, po prostu nic. Przeglądanie udziału zawiesza się, ping zgłasza brak odpowiedzi, a logi serwera wyglądają zdrowo, bo serwer zrobił swoje.

Umieść trasę powrotną tam, gdzie patrzą hosty

Każdy host LAN pyta swoją bramę domyślną, więc brama jest jedynym urządzeniem, które musi wiedzieć, gdzie znajduje się pula tunelu. Dodaj tam trasę statyczną, a każdy host odziedziczy właściwą drogę bez ingerencji.

Jeśli brama rozdaje swój adres jako opcję DHCP, rozprowadź trasę w ten sposób, aby nowe maszyny pobrały ją automatycznie. W przeciwnym razie trasa żyje w jednym pliku konfiguracyjnym i znika przy następnej przebudowie.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Dlaczego NAT źródłowy wydaje się to naprawiać

Maskowanie puli klientów za adresem serwera VPN usuwa problem przez usunięcie adresu klienta z pakietu. Odpowiedzi wracają wtedy do serwera, który już wie, jak dotrzeć do tunelu, i wszystko działa. Kosztem jest to, że hosty wewnętrzne nie widzą już, kim jest klient, a każde połączenie wygląda, jakby pochodziło z jednej maszyny.

Ta wymiana czasem jest słuszna, na przykład gdy urządzeniu dostawcy nie można nadać trasy statycznej. Nie rób reguły szerszej niż bieżąca pula, bo reguła napisana dla /24 przestaje pasować w dniu, gdy pula zostanie przenumerowana na /16, a pierwszym znakiem jest grupa nowych klientów, którzy się łączą i do niczego nie docierają.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

Ścieżka w chmurze wymaga trzech ustawień

W VPC ta sama luka wraca w innej postaci, bo podsieć nie ma żadnej trasy dla zakresu klientów. Tablica routingu potrzebuje wpisu dla puli tunelu wskazującego interfejs sieciowy instancji, a na interfejsie trzeba wyłączyć sprawdzanie źródła i miejsca docelowego, aby platforma przyjmowała pakiety, których źródłem nie jest jego własny adres. Grupy zabezpieczeń i ACL sieci muszą także przepuszczać pulę w obu kierunkach.

Każde pominięcie daje inny częściowy błąd. Pomiń wpis w tablicy routingu, a prywatne instancje odpowiedzą do podsieci, która nie potrafi przenieść odpowiedzi z powrotem do puli. Przy włączonym sprawdzaniu platforma odrzuca odpowiedź po tym, jak instancja już ją wysłała. Bez reguły grupy zabezpieczeń samo żądanie nigdy nie dociera, a klient widzi przekroczenie czasu o warstwę wcześniej.

Wykonaj kontrole w tej kolejności

Potwierdź przekazywanie i politykę filtrowania, zanim obwinisz routing, bo host, który nie będzie przekazywał, zawodzi w ten sam cichy sposób. Następnie odczytaj obowiązujące ustawienie drogi powrotnej na interfejsie, który niesie tunel, ponieważ ścisły filtr może odrzucić odpowiedzi nadchodzące z nieoczekiwanego kierunku.

Zakończ zrzutem wykonanym na hoście LAN, gdy klient go pinguje. Żądanie, które dociera bez pasującej odpowiedzi, dowodzi drogi powrotnej, a żądanie, które nigdy nie dociera, przenosi winę z powrotem na serwer lub tunel.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

Kontrola źródła i miejsca docelowego jest udokumentowana w przewodniku po elastycznych interfejsach sieciowych. Ustaw ją na interfejsie, który faktycznie niesie ruch tunelu, a nie na niepowiązanym adapterze podłączonym do tej samej instancji.

Powiązane artykuły