NAT sieci LAN przez tun0 na bramie VPN OpenBSD

Dwóch inżynierów z tą samą bramą OpenBSD często poda ci dwa różne zestawy reguł dosięgnięcia sieci zdalnej i oba można obronić. Wybór między translacją źródła a trasą powrotną wcale nie jest kwestią składni. Wszystko sprowadza się do tego, co druga strona już wie o 192.168.88.0/24 i co musisz zachować w logach. Popełnij tu błąd, a linia nat-to będzie wyglądać idealnie, podczas gdy odpowiedzi znikną w zdalnej bramie domyślnej.

Routing i przepisywanie odpowiadają na różne pytania

Tablica routingu decyduje, że 172.20.0.0/16 jest osiągalne przez tun0, i ta decyzja zapada, zanim skonsultowana zostanie jakakolwiek translacja pf. Potem translacja źródła zmienia nagłówek pakietu, tak że zdalny koniec widzi adres tunelu bramy zamiast hosta LAN. Żaden z mechanizmów nie zastępuje drugiego: reguła nat nie może wyczarować trasy, a trasa nie przekona zdalnego routera, który nigdy nie słyszał o twojej prywatnej podsieci. Gdy drugiej stronie brakuje drogi powrotnej, odpowiedzi są odrzucane lub przekazywane do jej bramy domyślnej, i żadne dostrajanie reguł tego nie naprawi.

Mówiąc wprost, przekazywanie odpowiada na pytanie, dokąd idzie ruch, a translacja – skąd wydaje się pochodzić. Trzymaj je w osobnych przegródkach, projektując zestaw reguł.

Trzy warunki, które decydują

Zadaj trzy pytania po kolei, a projekt zwykle wybiera się sam. Czy sieć zdalna ma statyczną trasę wskazującą adres tunelu dla 192.168.88.0/24, czy jej administrator kontroluje routery na tej drodze? Jeśli tak, pozwól adresom LAN podróżować bez zmian i całkowicie pomiń translację. Czy potrzebujesz widoczności poszczególnych klientów po drugiej stronie, czy to dla polityki dostępu, czy dla śladu audytowego? Jeśli tak, zachowanie źródła jest warte pracy nad routingiem. Czy adres tunelu jest wystarczająco stabilny, by wpisać go w trasę zdalną, czy zmienia się między połączeniami?

Jeśli którakolwiek odpowiedź brzmi nie lub nie wiadomo, nat-to jest opcją pragmatyczną i zarazem odwracalną. Reguła translacji znika w jednej linii, gdy druga strona doda porządną trasę. Trasa powrotna, której nigdy nie zainstalowano, kosztuje cię wątek wsparcia za każdym razem, gdy ktoś pyta, dlaczego tunel działa tylko w jedną stronę.

Umieść fragment tak, aby pf naprawdę go ocenił

Poniższy fragment zakłada, że LAN to 192.168.88.0/24, sieć zdalna to 172.20.0.0/16, a interfejsem tunelu jest tun0. Nic w nim nie wybiera następnego skoku. Przepisuje tylko źródło w pakietach, które już wychodzą przez tunel.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

Dwa szczegóły w tej pierwszej linii dźwigają większość ciężaru. Nawiasy wokół tun0 mówią pf, aby przy każdej budowie wpisu stanu odczytał adres interfejsu, co ma znaczenie, gdy tunel zostanie ponownie przenumerowany po ponownym połączeniu. Słowo match znaczy, że reguła przepisuje, a potem spada dalej, więc osobna reguła pass nadal musi wpuścić przepływ. Interfejs nazwany w linii match musi też być tym, który wybiera tablica routingu, inaczej pf oceni regułę na innej ścieżce wyjściowej niż ta, którą pakiet naprawdę podąża.

Nie zapomnij o stronie jądra. Przekazywanie IPv4 musi być włączone, a stanowe reguły pass dla tunelu i LAN muszą istnieć, zanim to wszystko nabierze sensu. Sekcja PF NAT w FAQ OpenBSD to właściwe źródło kolejności słów kluczowych.

Zweryfikuj zestaw reguł, zanim zaufasz ruchowi

Najpierw sprawdź składnię za pomocą pfctl -nf /etc/pf.conf, które analizuje plik bez jego ładowania. Potem wczytaj politykę i odczytaj, co jądro naprawdę trzyma, ponieważ reguła poprawnie przeanalizowana wciąż może być przesłonięta lub przypięta do niewłaściwego interfejsu. pfctl -sn wypisuje reguły translacji w postaci wczytanej, a pfctl -sr wypisuje reguły filtrowania w kolejności oceny.

Następnie obserwuj kabel. Na bramie tcpdump -ni tun0 'host 172.20.0.10' pokazuje, czy adres źródłowy opuszczający tunel to adres tunelu, czy host LAN. Szybki netstat -rn -f inet potwierdza, na który interfejs rozwiązuje się cel. Gdy ruch zacznie płynąć, pfctl -ss wylicza wpisy stanu; jeśli przepływ nie utworzył stanu, pakiet nigdy nie trafił na regułę, która by go utworzyła.

Jeśli strona tunelu wygląda dobrze, a odpowiedzi wciąż nie nadchodzą, przestań edytować pf. Pozostała usterka jest na zdalnym routerze, gdzie odpowiedź jest wysyłana w stronę prywatnego adresu, którego ta strona nie może osiągnąć.

Kiedy translacja kosztuje więcej, niż oszczędza

Translacja ukrywa klientów i czasem to jest dokładnie zła wymiana. Nakładające się podsieci to jeden przypadek: jeśli druga strona również używa wewnętrznie 192.168.88.0/24, prezentowanie hostów LAN jako bramy pogarsza kolizję zamiast ją łagodzić. Polityki IPsec wybierające ruch według pary adresów to drugi przypadek, ponieważ baza polityk bezpieczeństwa jest dopasowywana przed translacją i nigdy nie widzi przepisanego pakietu. Każde wdrożenie, które rozlicza, ogranicza lub audytuje per użytkownik, również traci tożsamość, której potrzebuje w chwili, gdy źródło zapada się do jednego adresu.

Przenośne pochodne pf to osobna pułapka. Produkty generujące własne pliki reguł oczekują, że NAT będzie konfigurowany przez ich interfejs, a fragmenty edytowane ręcznie są nadpisywane przy następnym przeładowaniu. Zestawy reguł skopiowane z poradników napisanych przed powstaniem słowa kluczowego match nie wczytają się na obecnym jądrze, więc przenieś składnię i przeczytaj błąd zamiast zgadywać.

Reguła decyzyjna, która przetrwa kontakt z prawdziwymi sieciami, jest krótka: zainstaluj trasę powrotną, kiedy możesz, tłumacz, kiedy nie możesz, i zapisz, który z trzech warunków skłonił cię do tego wyboru. Ta notatka oszczędza następnej osobie popołudnie.