pfSense jako serwer i klient VPN: dwie ścieżki, jeden router

Jedno urządzenie może patrzeć w dwóch kierunkach naraz: użytkownicy mobilni łączą się do wewnątrz, a to samo pudełko łączy się na zewnątrz z dostawcą wyjścia, aby wybrany ruch wychodził przez inną sieć. Włączenie obu usług zajmuje minuty; współistnienie wymaga projektu, bo druga rola przepisuje tablicę tras, na której opiera się pierwsza. Trzy warunki decydują, czy układ działa, mianowicie czy usługa przychodząca zachowuje własną trasę powrotną, czy tunel wyjściowy wciąż dociera do swojego partnera i czy ruch, który chciałeś przekazywać, jest wybierany do wyjścia. Pomylisz jeden i dostaniesz dwa tunele, które oba zgłaszają połączenie, podczas gdy nic użytecznego między nimi nie przechodzi. Poniższe kontrole ustalają każdy warunek w kolejności, w jakiej awarie zwykle się pojawiają.

Nazwij obie role, zanim dotkniesz jakiegokolwiek ustawienia

Zapisz cztery fakty dla każdej instancji: jej zdalnego partnera, materiał uwierzytelniający, pulę adresów, którą rozdaje, i sieci za nią. Obie instancje są osobnymi obiektami na urządzeniu i powinny pozostać osobne także w twoich notatkach. Prawie każdy późniejszy mylący objaw bierze się z mieszania ich wartości, a dwie instancje dzielące jeden zestaw notatek to sposób, w jaki zła pula trafia do złego pola.

Usługa przychodząca potrzebuje sieci tunelowej, która nie pokrywa się z adresami tunelu wyjściowego ani z żadną siecią prywatną, którą urządzenie trasuje. Nakładanie się to jedyny błąd, który jednocześnie daje objawy w obu rolach, i znacznie taniej jest złapać go na papierze. Porównaj obie pule i każdą trasowaną sieć prywatną w jednym miejscu, zanim skonfigurujesz którąkolwiek z usług.

Wspólny sprzęt nie oznacza wspólnych poświadczeń, a certyfikat klienta z puli dostępu zdalnego nie powinien być użyteczny wobec dostawcy wyjścia. Osobny materiał zamienia też unieważnienie w decyzję lokalną, a nie wydarzenie dla całej floty.

Trzymaj odpowiedzi serwera na ścieżce WAN

Odpowiedzi, które urządzenie generuje samo, są pierwszą ofiarą niedbałej trasy domyślnej. Gdy przychodzi enkapsulowany pakiet użytkownika mobilnego, odpowiedź jest ruchem powstałym lokalnie i musi wyjść przez interfejs, którym ten użytkownik przyszedł. Jeśli klient wyjściowy zainstalował trasę domyślną, która ją przechwytuje, odpowiedź trafia do złego tunelu, a sesja się zatrzymuje, podczas gdy usługa wciąż wygląda zdrowo.

Nie ma jednego pola wyboru, które to rozstrzyga, bo decyzja dotyczy tego, jaki ruch klient wyjściowy może przechwytywać. Albo nie ściągasz żadnych tras i kierujesz tylko to, co wybierzesz, albo ściągasz trasy i dodajesz wyjątki, które utrzymują własne usługi urządzenia w ruchu. Zapisz wybór obok instancji, inaczej następna osoba założy ten drugi.

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

Czytaj tablicę tras według najdłuższego dopasowania, a nie według kolejności, w jakiej coś konfigurowałeś. Pytanie brzmi, który wpis wygrywa dla adresu partnera wyjścia i który wpis wygrywa dla odpowiedzi usługi przychodzącej, a te dwie odpowiedzi mogą się różnić.

Nie pozwól tunelowi wyjściowemu zjeść własnego punktu końcowego

Klient wyjściowy musi dotrzeć do publicznego adresu swojego partnera, aby w ogóle ustanowić tunel. Jeśli ten adres sam jest trasowany do tunelu, klient goni własny ogon: transport nigdy nie wstaje albo wstaje i spada w chwili instalacji trasy. Dziennik wygląda jak przekroczenie limitu czasu uwierzytelniania, a nie usterka routingu, dlatego trasa zasługuje na pierwszą kontrolę.

Sprawdź trasę przed poświadczeniami i ponownie po podniesieniu tunelu, bo wpis może być poprawny przy starcie i błędny minutę później. Adres partnera musi wskazywać zwykłą ścieżkę WAN, nigdy urządzenie tunelowe. Gdy transport się ustabilizuje, ciekawe pytanie przenosi się na ruch przekazywany, a to jest następna decyzja.

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

Wybierz, którzy użytkownicy dostają wyjście

Polityka źródła należy do wejścia, w którym ruch wchodzi na urządzenie, więc wybierz pulę dostępu zdalnego lub węższe tożsamości w niej. Zachowaj cele prywatne i wyjątki zarządzania, których nigdy nie wolno wysyłać do wyjścia, i umieść te reguły przed szeroką. Ścieżka wyjścia potrzebuje wtedy własnej translacji lub trasowanego układu powrotnego, co w większości projektów oznacza wychodzący NAT na interfejsie wyjścia obejmujący pulę. Translacja nie wybiera wyjścia; przepisuje tylko to, co już wyszło, więc reguła NAT na niepowiązanym WAN nic nie zmienia w wyborze.

Potwierdź, że strona odległa zezwala na ruch przekazywany z tego projektu, bo niektórzy dostawcy zezwalają, a inni nie. Różnica objawia się jako tunel, który się łączy i nic nie niesie, co łatwo odczytać jako usterkę lokalną. Przetestuj trzy przepływy osobno, bo zawodzą niezależnie, a dwa z trzech to na wpół zbudowany projekt.

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

Pierwsze polecenie to zewnętrzne połączenie użytkownika mobilnego i działa, gdy klient zgłasza zakończenie sekwencji inicjalizacji. Drugie, uruchomione z tego podłączonego laptopa, powinno zgłosić adres dostawcy wyjścia, a nie twój adres WAN. Trzecie działa na urządzeniu związane z adresem z puli i testuje politykę źródła dla ruchu przekazywanego, nie angażując w ogóle zdalnego użytkownika. Jeśli zamiast tego odpowiada z WAN, polityka nie pasowała, a żadna edycja NAT nie naprawi problemu wyboru.

Zdecyduj, co się dzieje, gdy wyjście zawiedzie

Zapisz zachowanie przy awarii, zanim ona nastąpi: gdy tunel wyjściowy spada, czy użytkownicy wracają do zwykłego WAN, czy są zablokowani, dopóki wyjście nie wróci? Obie odpowiedzi są do obrony, a urządzenie nie wybierze za ciebie. Usunięta trasa lub polityka wskazująca martwą bramę nie daje automatycznie wyniku pełnej blokady. Jeśli chcesz blokady, polityka musi to powiedzieć wprost, i trzeba to przetestować przez odebranie wyjścia, a nie przez rozmyślanie o nim. Jeśli chcesz powrotu, ogłoś to użytkownikom, bo ruch, który po cichu wybiera zwykłą ścieżkę, to dokładnie ten ruch, który ktoś uważał za objęty.

Wyłącz instancję klienta, zobacz, do czego połączony użytkownik jeszcze dociera, i uruchom ją ponownie. Żądanie, które wygasa, to wynik pełnej blokady, o który prosiłeś; to, które odpowiada adresem WAN, to powrót, którego nie udokumentowałeś. Powtórz kontrolę dla IPv6 i DNS, bo polityka napisana dla IPv4 nic nie mówi o ruchu AAAA, a resolver przepchnięty przez którykolwiek tunel odpowiada stamtąd, skąd zapytanie naprawdę wychodzi.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

Przepis Netgate na trasowany OpenVPN pokazuje, jak polityka źródła, przypisanie interfejsu i translacja wychodząca pasują do siebie, a jego zasięg między witrynami to część, której nie należy kopiować w całości. Czego ci nie powie, to który z trzech powyższych warunków twój własny projekt już złamał.