Przełącznik „zezwalaj na sieć lokalną” w kliencie VPN brzmi, jakby obejmował wszystko w budynku. W praktyce zwykle dodaje kilka wyjątków dla adresów prywatnych do trasy domyślnej tunelu i na tym poprzestaje. Twoja sieć VLAN magazynu pozostaje osiągalna tylko wtedy, gdy trasa dla tego konkretnego prefiksu przetrwa pojawienie się tunelu, a w wielu klientach tak się nie dzieje.

To pytanie o routing, a nie ustawienie VPN, co jest dobrą wiadomością: ma konkretną odpowiedź.

Co faktycznie obejmuje zezwalanie na sieć lokalną

Klienci implementują tę opcję różnie. Niektórzy dodają trasy do podsieci, do której podłączona jest maszyna, inni dodają zakresy RFC 1918, a nieliczni wykluczają tylko bramę domyślną. Żaden z nich nie wie, że router biurowy obsługuje także sieć VLAN magazynu, segment laboratoryjny albo podsieć drukarek, bo tych prefiksów nie ma w sieci, którą klient widzi. Zamiast zakładać, że etykieta opisuje twoją topologię, przeczytaj dokumentację samego klienta, aby poznać dokładne zachowanie.

Ta różnica ma największe znaczenie w projekcie z pełnym tunelem, w którym klient celowo zastępuje trasę domyślną, aby cały ruch szedł przez VPN. Taki jest cały sens tego projektu i to właśnie sprawia, że lokalne trasowane sieci znikają. Nigdy nie były objęte własną trasą; jechały na trasie domyślnej, która właśnie została zastąpiona. Klient nie potrafi trasować czegoś, o czym nie wie, że istnieje, a uczy się tylko prefiksów przypisanych do własnego interfejsu. Wszystko inne musi opisać ktoś, kto zna topologię.

Trasy połączone kończą się na pierwszym routerze

Stacja robocza pod 192.168.10.20/24 z bramą 192.168.10.1 automatycznie otrzymuje trasę połączoną dla 192.168.10.0/24. Sieć VLAN magazynu pod 192.168.20.0/24 to inny prefiks, osiągalny tylko przez tę bramę, a stacja nie ma dla niego trasy poza domyślną. Zanim tunel się podniesie, zwykła trasa domyślna wysyła ruch magazynu do 192.168.10.1 i wszystko działa.

Gdy VPN instaluje domyślną trasę pełnego tunelu, pakiety do 192.168.20.1 podążają za nową trasą domyślną do tunelu. Zdalna brama nie ma pojęcia, gdzie mieszka ten prefiks, więc je odrzuca albo przesyła w bezużyteczne miejsce. Na sieci VLAN magazynu nic nie było źle skonfigurowane; jej ścieżka była pożyczona, a pożyczkę zażądano z powrotem.

Pokusa jest sięgnięcie po szeroki wyjątek, na przykład parę tras /1 albo drugą trasę domyślną. Oprzyj się jej. Im węższy wyjątek, tym łatwiej go wyjaśnić, prześledzić i usunąć, gdy sieć się zmieni.

Umieść wyjątek w tabeli, która wygrywa

W obrębie jednej tabeli routingu /24 bije /0 lub /1 dzięki dopasowaniu najdłuższego prefiksu, więc konkretna trasa do sieci VLAN magazynu przez lokalną bramę wystarczy, pod warunkiem że tabela jest w ogóle sprawdzana. W Linuksie zwykła postać jest krótka:

ip route add 192.168.20.0/24 via 192.168.10.1 dev eth0

Routing polityk komplikuje tę gwarancję. Wcześniejsza reguła może skierować ruch do tabeli, której własna trasa domyślna prowadzi do tunelu, i wtedy główna tabela z twoim /24 nigdy nie zostanie osiągnięta. Sprawdź reguły, zanim uznasz trasę za autorytatywną, bo poprawnie wyglądający wpis w niewłaściwej tabeli wyjaśnia awarię, która wygląda jak zepsuta trasa.

Następnie utrwal wpis przez mechanizm obsługiwany przez klienta albo menedżer sieci, który zarządza interfejsem. Trasa wpisana w wierszu poleceń znika przy następnym ponownym połączeniu, a trasa przypisana do jednej bramy Wi-Fi nie przenosi się do następnej sieci, którą odwiedzi laptop.

Nazwy i polityka nie podążają za trasami

Naprawa trasy przywraca pakiety, nie nazwy. Jeśli urządzenia lokalne są rozwiązywane przez wstrzyknięty resolver, który nic o nich nie wie, montowanie nadal się nie udaje, mimo że adres jest osiągalny. Lokalne nazwy wymagają lokalnego lub dzielonego układu DNS, a to osobna decyzja od wyjątku trasowania.

Polityka to znów osobna sprawa. Filtr dostępu lokalnego klienta VPN może celowo zabraniać ruchu do zakresów prywatnych, a trasa nie unieważnia tej reguły. W niezaufanej sieci adres prywatny nie jest też dowodem, że celem jest twój serwer magazynu, więc wyjątek powinien być tak samo konkretny jak trasa.

Umowa, którą można przekazać dalej

Gotowy projekt powinien czytać się jak krótka lista: ogólny ruch internetowy idzie przez tunel, a te nazwane lokalne prefiksy zachowują swoją ścieżkę przez lokalny router. Zapisz prefiksy, następny przeskok i towarzyszący im sufiks DNS, i utrzymuj listę tak krótką, żeby ktoś mógł ją zweryfikować bez czytania tabeli routingu.

Uważaj na nakładanie się zakresów lokalnych i zdalnych. Sieć VLAN magazynu, która dzieli prefiks z czymś za VPN, zostanie rozwiązana na trasę bardziej szczegółową, a wynikające z tego zachowanie jest mylące w sposób wyglądający na przerywany. Przenumerowanie jednej strony jest zwykle tańsze niż wieczne debugowanie tej niejednoznaczności.

Przetestuj umowę dwa razy: raz z tunelem podniesionym, a raz z opuszczonym. Jeśli lokalna ścieżka działa tylko w jednym z tych stanów, wyjątek nie jest jeszcze umową.

Powiązane artykuły