Podzielone trasy L2TP na Macu: dlaczego adres hosta nie działa

VPN się łączy, pasek menu to pokazuje, a host wewnętrzny nadal kończy się przekroczeniem czasu. W tej sytuacji są trzy możliwe przyczyny, a to, która obowiązuje, zależy od sposobu skonfigurowania tunelu. Albo polecenie trasy użyło adresu hosta tam, gdzie wymagany był adres sieci, albo sam profil instaluje trasę domyślną, która połyka decyzję, albo klient jest tunelem PPP, który potrzebuje haka zamiast klucza profilu. Sprawdź je w tej kolejności, bo pierwszą najtaniej wykluczyć.

Miejsce docelowe to adres sieci, maska opisuje prefiks

networksetup -setadditionalroutes przyjmuje trójki celu, maski podsieci i bramy. Wywołanie, które wysyła jedną podsieć wewnętrzną przez tunel, wygląda tak:

sudo networksetup -setadditionalroutes "VPN (L2TP)" 192.168.1.0 255.255.255.0 10.2.0.0

Zwróć uwagę, czym jest cel: adresem sieci, a nie adresem serwera, do którego próbujesz dotrzeć. W przypadku, który dał początek temu artykułowi, identyczne polecenie z 192.168.1.20 w tym miejscu nie zrobiło nic pożytecznego, a zastąpienie go przez 192.168.1.0 zadziałało natychmiast. Ta sama maska, ta sama brama, jedna inna liczba. To cała awaria w miniaturze.

Przyczyna jest arytmetyczna, nie polityczna. Adres hosta sparowany z maską /24 nie opisuje 192.168.1.0/24; opisuje coś, czego tabela routingu nie może użytecznie utrzymać, więc wpis jest odrzucany lub ignorowany, a tunel ostatecznie przenosi mniej, niż zamierzałeś.

Gdy chcesz dokładnie jednego hosta, użyj adresu hosta z maską 255.255.255.255. Mieszane pary są miejscem, w którym to się psuje, a nie samo użycie adresu hosta. /32 zbudowana z jednego adresu to legalna trasa; /24 zbudowana z jednego adresu to błąd.

Wywołanie zastępuje listę, a nazwa jest dosłowna

Dwa zachowania zaskakują przy pierwszej próbie. Polecenie ustawia pełną listę tras dodatkowych zamiast dopisywać, więc wywołanie dodające jeden prefiks po cichu usuwa pozostałe, które były wcześniej. Zbuduj cały zbiór w jednym wywołaniu.

Nazwa usługi też nie jest etykietą, którą wymyśliłeś. Odczytaj ją z narzędzia i skopiuj dokładnie, wraz z przyrostkiem typu:

networksetup -listallnetworkservices

Nazwa różniąca się jednym znakiem nie daje błędu wartego czytania ani trasy. Kopiowanie i wklejanie to właściwa technika, a nie przepisywanie z pamięci.

Gdy profil rości sobie prawo do trasy domyślnej

Podzielone trasy przegrywają z trasą domyślną dla każdego celu, którego wyraźnie nie obejmują, a profil L2TP skonfigurowany dla pełnego tunelu instaluje dokładnie to. Jeśli profil mówi, że wszystko idzie przez tunel, lista tras dodatkowych zmienia się bardzo niewiele. Twój wpis nie jest błędny; jest po prostu nieistotny dla celów, których nigdy nie wymienia. Kontrola nad tym zwykle znajduje się w ustawieniu profilu dotyczącym wysyłania całego ruchu, a nie w jakimkolwiek poleceniu trasy.

Zdecyduj, którego modelu naprawdę chcesz, zanim zaczniesz edytować kolejne wpisy. Pełny tunel z wyjątkami to inna konfiguracja niż podzielony tunel z określonymi prefiksami, a mieszanie obu daje tabelę, której nikt nie potrafi przewidzieć.

Jeśli organizacja wymaga pełnego tunelu, przestań próbować dzielić go lokalnie i zanieś wymaganie temu, kto posiada politykę. Lokalnie dodana trasa, która jej przeczy, i tak zostanie usunięta przy następnej aktualizacji profilu.

Tunele PPP potrzebują haka zamiast klucza

Dla tuneli opartych na PPP defaultroute to klucz profilu, który tworzy trasę domyślną; usuń go, a klient przestanie rościć sobie prawo do każdego celu. Trasy dodaje się potem po pojawieniu się interfejsu, zwykle z /etc/ppp/ip-up:

#!/bin/sh
/sbin/route add -net 192.168.1.0 -interface ppp0

Trzymaj skrypt w posiadaniu roota i wykonywalny, i dodaj zabezpieczenie na nazwie interfejsu, gdy na maszynie istnieje więcej niż jeden profil tunelu. Hak uruchamiany dla każdego połączenia PPP i zakładający jedną nazwę urządzenia to mały błąd o długim życiu.

Zweryfikuj podział trzema żądaniami

Przechwyć tabelę podczas połączenia i zanotuj, który interfejs obsługuje tunel. Następnie sprawdź konkretny cel, zamiast ufać statusowi wyjścia polecenia, które go utworzyło. Kod wyjścia mówi, czy narzędzie przyjęło argumenty, a nie czy ruch idzie zamierzoną drogą.

Zakończ trzema żądaniami, które dowodzą podziału: jeden host wewnętrzny po adresie, jedna nazwa wewnętrzna przez wewnętrzny resolver i jedna witryna publiczna, która nadal powinna używać połączenia lokalnego. Jeśli witryna publiczna też przechodzi teraz przez tunel, podział nigdy nie nastąpił, cokolwiek zdaje się mówić lista tras.

Połącz się jeszcze raz i powtórz żądanie wewnętrzne, ponieważ trasy dodane ręcznie mogą przeżyć interfejs, który je uwiarygodnił i po cichu zamienić ruch w czarną dziurę po upadku tunelu.