VPN passthrough
Pod mrożącym krew w żyłach określeniem, które widnieje w tytule niniejszego wpisu kryje się całkiem prosty mechanizm. Często pojawia się on w opcjach konfiguracyjnych przeróżnego sprzętu sieciowego i niejednokrotnie traktowany jest na zasadzie „jeżeli działa, nie dotykaj”. Tak naprawdę nie ma w takim podejściu do sprawy nic złego, ale czasami warto wiedzieć, co można osiągnąć, świadomie zmieniając tego typu opcje. Mechanizm ten nie jest niczym więcej, jak elementem umożliwiającym zestawienie tunelu VPN przechodzącego przez translację adresów (czyli popularny NAT). W zależności od konkretnych protokołów, które wykorzystywane są przez nasz tunel VPN, mechanizm ma mniej lub więcej zadań do wykonania. Popatrzmy na trzy konfiguracje:
-
Najprościej jest w przypadku bardzo popularnego ostatnio OpenVPNa. Wykorzystuje on tylko pojedynczy port TCP lub UDP, wobec czego nie potrzebuje żadnego wsparcia ze strony routerów ani ścian ogniowych, przez które ruch jest przesyłany. Co więcej, port ten może być niemal dowolnie zmieniany, a jedyne ograniczenia narzucane są przez konkretne implementacje protokołu (przykładowo routery Mikrotik obsługują konfiguracje OpenVPNa jedynie za pośrednictwem portów TCP).
-
Z zupełnie inną sytuacją mamy do czynienia w przypadku tuneli wykorzystujących protokół GRE (np. PPTP). Ponieważ GRE jest jednym z protokołów IP (podobnie jak TCP lub UDP) i w dodatku nie wykorzystuje pojęcia „portu”, mechanizmy translacji adresów nie są w stanie poprawnie obsłużyć takiego połączenia, ponieważ nie mają sposobu, aby odróżnić pakiety przynależące do różnych sesji. Jak więc routery radzą sobie z takim problemem i co kryje się pod hasłem „passthrough”? Okazuje się, że istnieje coś takiego, jak rozszerzony nagłówek GRE, który zawiera pole „Call ID”. I właśnie to pole wykorzystywane jest w roli wyznacznika konkretnego połączenia (zupełnie jak porty w przypadku TCP lub UDP). Zawartość wspomnianego pola wybierana jest przez klienta VPN dość losowo, a samo połączenie zapamiętywane jest przez NATownicę jako para „Call ID” + adres IP systemu docelowego.
-
Trzecim scenariuszem, który warto opisać jest konfiguracja tunelu z udziałem protokołu IPSEC (np. tandem L2TP/IPSEC). IPSEC, podobnie jak ma to miejsce w przypadku PPTP, także używa protokołów IP innych, niż TCP i UDP. Są to m.in AH (protokół numer 0x33) oraz ESP (0x32). Ponieważ nie istnieje „rozszerzony nagłówek ESP”, trzeba było opracować inną metodę na połączenie IPSECa i NATa. Rozwiązaniem okazał się mechanizm nazwany „NAT Traversal”, który działa dwuetapowo. Jeszcze przed zaszyfrowaniem danych mechanizm określa, czy oba urządzenia zestawiające tunel obsługują NAT-T. Jeżeli odpowiedź jest pozytywna, to wyszukiwane są routery „robiące NAT” pomiędzy naszymi urządzeniami (proces nazwany został „NAT Discovery”). Jeżeli także i tutaj uzyskamy pozytywną odpowiedź, to… cały ruch pomiędzy końcami tunelu opakowywany jest w datagramy UDP, unikając w ten sposób konieczności przesyłania czegokolwiek innego, niż ruch na portach udp/500 (IKE) oraz udp/4500 (NAT-T). Cały mechanizm bardzo ładnie opisany został TUTAJ.