VPN i sieć domowa w tej samej podsieci: najpierw prześledź trasę
Oba adaptery roszczą sobie 192.168.1.0/24 i wygrywa tylko jedna trasa. Prześledź listę adapterów, zwycięską trasę i drogę powrotną, zanim przenumerujesz lub obwinisz DNS.
Łączysz się z VPN-em biurowym, ikona w zasobniku zmienia się na zieloną, intranet się ładuje, a drukarka dwa metry dalej przestaje odpowiadać. Udział, który działał rano, kończy się przekroczeniem czasu na tej samej maszynie, a żaden dziennik nie wspomina drukarki. Odruchem jest DNS, bo nazwa, która się nie rozwiązuje, wygląda jak nazwa, która nie istnieje, ale problem jest w adresie: dwa adaptery roszczą sobie teraz 192.168.1.0/24 i tylko jedna trasa może wygrać ten prefiks. Przejdź to w tej kolejności i zobaczysz, który adapter go przejął, zanim cokolwiek zmienisz.
Zacznij od objawu, nie od tunelu
Wskazówką jest zakres. Jeśli intranet działa, a każde urządzenie lokalne zawodzi, tunel jest zdrowy, a ścieżka lokalna nie. Jeśli urządzenia lokalne działają, a intranet zawodzi, jest odwrotnie. Jeśli wszystko działa poza jednym hostem, patrzysz na jeden adres, który istnieje po obu stronach.
Zapisz jeden adres lokalny i jeden zdalny, zanim dotkniesz ustawienia. „Drukarki” nie da się przetestować; 192.168.1.40 da się. Ten jeden krok zapobiega najczęściej traconej godzinie w tym problemie, czyli przepisywaniu ustawień DNS z powodu decyzji o routingu.
Krok 1: zobacz oba adaptery roszczące sobie prefiks
Otwórz Połączenia sieciowe (ncpa.cpl) i przeczytaj oba adaptery obok siebie. Adapter Ethernet pokazuje 192.168.1.50/24 z bramą 192.168.1.1. Adapter VPN pokazuje 192.168.1.201/24, wysłany przez serwer. Oba są legalne, oba uważają, że prefiks jest on-link, a stos utrzyma dla niego jedną trasę.
Get-NetIPAddress -AddressFamily IPv4 wylicza adresy, a Get-NetIPInterface | Sort-Object InterfaceMetric pokazuje kolejność, w jakiej stos ich użyje. Ta kolumna metryki to decyzja, którą właśnie odczytasz, więc zapisz liczby zamiast próbować je zapamiętać.
Odpowiedz tanio na teorię DNS: Resolve-DnsName printer.office.lan zwraca ten sam adres co wczoraj. Nazwa się rozwiązała; potem pakiet wyszedł przez niewłaściwy adapter. Dwie minuty tutaj oszczędzają popołudnie w ustawieniach resolvera.
Krok 2: przeczytaj trasę, która naprawdę wygrała
Find-NetRoute -RemoteIPAddress 192.168.1.40 wypisuje interfejs, następny przeskok i źródło, których stos użyłby dla tego adresu. Traktuj to wyjście jako odpowiedź, nie jako podpowiedź. route print -4 daje całą tabelę, gdy chcesz zobaczyć, który wpis przegrał i o ile.
Konkretność wygrywa z zamiarem. Wypchnięty 192.168.0.0/25 bije lokalny 192.168.0.0/24, bo prefiks jest dłuższy, więc 192.168.0.0 do 192.168.0.127 wychodzą tunelem, a górna połowa zostaje lokalna. Zniknięcie połowy sieci bez komunikatu o błędzie jest poprawnym zachowaniem tej tabeli.
tracert -d 192.168.1.40 potwierdza to spoza tabeli: jeśli pierwszy przeskok to adres tunelu, a nie twój router, trasa jest całą historią. W Linuksie tym samym pytaniem jest ip route get 192.168.1.40, które wypisuje adres źródłowy i urządzenie w jednej linii. Gdy odpowiedź wymienia tun0, przestań patrzeć w przeglądarkę.
Krok 3: sprawdź drogę powrotną, zanim obwinisz klienta
Poprawna trasa w przód i tak zawodzi, jeśli druga strona nie może odpowiedzieć. Gdy do sieci klienta dociera się przez tunel, brama tej sieci musi wiedzieć, gdzie mieszka pula tunelu: ip route add 10.8.0.0/24 via 192.168.1.12 na tym routerze, i push „route 192.168.1.0 255.255.255.0” z serwera, aby klienci znali drogę powrotną.
Bez pierwszego wpisu odpowiedź opuszcza cel w stronę swojej bramy domyślnej, która przekazuje prywatny adres dostawcy i go odrzuca. Objaw jest jednokierunkowy i łatwy do błędnego odczytania: żądania pojawiają się na tun0, odpowiedzi nigdy.
Reguła masquerade na hoście VPN usuwa potrzebę tej trasy statycznej: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Ukrywa też prawdziwe adresy źródłowe, co utrudnia każde późniejsze pytanie o dzienniki. Host docelowy z niewłaściwą bramą domyślną daje tę samą ciszę, z przekierowaniem ICMP w najlepszym przypadku i czarną dziurą w normalnym, dlatego przechwycenie należy do obu końców.
Krok 4: wybierz naprawę, z którą możesz żyć
Stosuje się do tego pięć napraw i nie są one wymienne. Wybieraj według tego, co musi pozostać osiągalne jednocześnie, a nie według tego, które polecenie jest najkrótsze.
| Repair | What it fixes | What it costs |
|---|---|---|
| Flip interface metrics | Alternating access: office now, home later, never both | Get-NetAdapter -Name "Ethernet 2" | Set-NetIPInterface -InterfaceMetric 21; set the VPN adapter back to 5000. A client that rewrites metrics on connect defeats it |
| Renumber one side | Every host reachable in both directions | DHCP reservations, printer queues, firewall rules and hard-coded addresses all move |
| Narrow the advertised prefix | Remote hosts really live in the upper half | Breaks the day someone adds a host below the cut |
| Translate with client-nat | Both address plans stay untouched | Stateless per-client mapping, unreadable logs, anything embedding addresses breaks |
| Publish one service with DNAT | One service on the VPN host reachable from the LAN | Both address plans stay; source addresses and reverse lookups stop being meaningful |
Metryki są tanią opcją i tą, po którą ludzie sięgają najpierw. Zmiana dotyczy interfejsu, więc działa, dopóki tunel jest podniesiony, i należy do skryptu obok klienta, a nie do powłoki, którą zapomnisz. Nie może dać jednoczesnego dostępu do tego samego adresu w dwóch sieciach, i to jest granica, która spycha całą resztę w dół tabeli.
Przenumerowanie sieci domowej na 10.10.0.0/24 to czyste rozwiązanie: jedno odnowienie dzierżawy DHCP plus rezerwacje, kolejki wydruku i twardo zakodowane adresy, które wspominają stary zakres. Przenumerowanie strony biurowej zwykle nie jest twoją decyzją. IPv6 całkowicie usuwa kolizję, gdy obie sieci je obsługują, używając unikalnego prefiksu lokalnego z fd00::/8 zamiast czegoś łatwego do zapamiętania, ale testuj aplikację po TCP, nie pingiem, bo ICMP może działać, gdy usługa nie.
Własna opcja tłumaczenia OpenVPN to ostatnia deska ratunku, wypychana z serwera do wpisu katalogu właściwego dla klienta. Przyjmuje cztery parametry po nazwie opcji — kierunek, sieć, maskę i alias — a alias nie jest opcjonalny: push "route 192.168.2.0 255.255.255.0" i push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". Sieć i maska to zakres, który widzi klient (192.168.2.0/24), alias to prawdziwy zakres biurowy po stronie serwera (192.168.1.0/24), a wypchnięta trasa czyni ten widoczny zakres osiągalnym. Biuro pojawia się wtedy dla tego klienta pod 192.168.2.x. Udokumentuj mapowanie w profilu, inaczej następna osoba będzie to debugować jako awarię routingu.
Publikowanie jednej usługi to wąska wersja tłumaczenia i wcale nie potrzebuje opcji OpenVPN. Reguła DNAT na hoście VPN publikuje ponownie jeden port, więc sieć zachowuje swoje adresy i dociera do usługi pod adresem hosta, który już zna. Koszt jest zwykły: usługa widzi host VPN jako źródło, więc dzienniki na klienta i wyszukiwania wsteczne przestają cokolwiek znaczyć. To obejmuje jedną kolejkę wydruku lub jedną stronę administracyjną, a nie hosty po obu stronach, które się nawzajem osiągają.
Co nadal nie będzie działać i co warto zapisać
Rozgłaszanie nie przechodzi przez trasowany tunel. DLNA, UPnP, przeglądanie NetBIOS i Wake-on-LAN zależą od rozgłaszania lub multicasu, którego urządzenie tun nie przenosi, więc żadna trasa nie naprawia wykrywania. Mostkowanie przez dev tap rozszerza segment, a wraz z nim rozgłaszanie DHCP, ARP i każdy inny pakiet wykrywania; preferuj trasę do hosta unicast, na przykład route 192.168.2.1 255.255.255.255, dla adresu po stronie sieci zdalnego routera.
Dwa routery, które oba używają 192.168.1.1 na tej samej drodze, należą do tej samej rodziny problemów: adres lokalny zawsze wygrywa, więc strona zdalnego routera pozostaje nieosiągalna, dopóki jedna sieć się nie przeniesie. Dodanie drugiego adaptera niczego nie zmienia w żadnym z obu przypadków.
Zapisz dowody, zanim cokolwiek edytujesz: ip route get lub Find-NetRoute, ping -c 3 do danego adresu, traceroute, i tcpdump -ni tun0 icmp na kliencie, potem tabelę routingu i liczniki NAT na serwerze. Ping, który działa w jedną stronę i umiera w drugą, wskazuje drogę powrotną, nie tunel, i właśnie ta jedna różnica decyduje, która z powyższych napraw jest naprawdę potrzebna.