Handshake PiVPN działa, strony się zatrzymują: sprawdź MASQUERADE

Telefon pokazuje tunel jako połączony, klient zgłasza adres prywatny, a pierwsza strona nadal wisi w połowie ładowania. Ten zestaw wysyła większość ludzi do ustawień szyfrowania i temperatury procesora, gdzie naprawdę nic nie jest zepsute. Tunel się podniósł, więc negocjacja się zakończyła; nie powiódł się kolejny krok, gdy serwer próbuje przekazać pakiety klienta do internetu. Przejdź tą samą drogą, którą idą te pakiety, a niezgodność zwykle widać w jednym wierszu tabeli NAT.

Zacznij od tego, do czego klient ma i nie ma dostępu

Z podłączonego klienta wczytaj stronę, która znajduje się w publicznym internecie, i zauważ, czy zawodzi natychmiast, czy zacina się w połowie. Następnie otwórz zasób na własnym prywatnym adresie serwera VPN i porównaj oba wyniki.

Adres tunelu, który odpowiada na ping, podczas gdy publiczne witryny kończą się przekroczeniem czasu, jest oznaką problemu z przekazywaniem lub tłumaczeniem, a nie zepsutego handshake’u. Panel stanu samego klienta nie potrafi ich rozróżnić, bo wie tylko, że kanał sterujący jest podniesiony. Sprawdź na serwerze interfejs tunelu za pomocą ip -br addr show tun0 i potwierdź, że adres przydzielony klientowi mieści się w puli, którą skonfigurowałeś. Jeśli pula i adres klienta się nie zgadzają, najpierw to napraw, bo każda reguła poniżej dopasowuje się do puli.

Następnie zapytaj serwer, którego interfejsu użyłby do osiągnięcia publicznego adresu. ip route get 203.0.113.9 wypisuje wybrane urządzenie i źródło w pierwszym wierszu. Zapisz nazwę tego urządzenia, bo właśnie ta wartość musi być w regule NAT.

Przeczytaj regułę, która decyduje, czy pakiety wychodzą

MASQUERADE przepisuje pakiet tylko wtedy, gdy pakiet opuszcza interfejs nazwany w regule. Reguła ograniczona do urządzenia przewodowego nic nie robi dla ruchu wychodzącego przez Wi-Fi, a pakiet zachowuje prywatny adres źródłowy aż do routera nadrzędnego. Ten router nie ma trasy powrotnej do twojej puli tunelu, więc odrzuca odpowiedź, a klient widzi połączenie, które się otwiera i potem umiera. Objaw rośnie wraz z tym, ile strony dotrze, zanim potrzebna jest pierwsza odpowiedź.

Wypisz żywą tabelę i czytaj kolumnę interfejsu wyjściowego, zamiast tylko szukać słowa MASQUERADE. Wynik w formie dodawania łatwiej porównać niż sformatowaną listę:

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

Na Raspberry Pi, które kiedyś używało Ethernetu, a teraz używa Wi-Fi, nieaktualna nazwa jest prawie zawsze całą historią. Instalator zapisał, jakie urządzenie było obecne podczas konfiguracji, a zapisany zestaw reguł odtwarza je przy każdym rozruchu. Zanim cokolwiek innego zmienisz, porównaj urządzenie z wyszukiwania trasy z tym w regule. Jeśli się zgadzają, interfejs nie jest twoim problemem i powinieneś przejść do liczników w ostatniej sekcji. Jeśli się różnią, poprawka to zmiana jednego słowa w pliku trwałości.

Popraw zapisany zestaw reguł, nie tylko działający

Edycja samej żywej tabeli utrzymuje się do następnego restartu, a to dokładnie tyle, ile trzeba, by przekonać cię, że problem jest rozwiązany. Reguły, które wracają przy starcie, mieszkają w pliku, który przeładowuje pakiet trwałości zapory. Na obrazach Pi opartych na Debianie ten plik to zwykle /etc/iptables/rules.v4.

Zrób kopię, zanim go dotkniesz, potem zastąp interfejs wyjściowy w wierszu MASQUERADE urządzeniem, które zapisałeś, na przykład -o wlan0 zamiast -o eth0. Zostaw zakres źródłowy tak, jak jest, chyba że zmieniła się pula klientów. Przeładuj i potwierdź, że reguła wskazuje teraz właściwe urządzenie:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

Dwa sąsiednie ustawienia łatwo zapomnieć. sysctl net.ipv4.ip_forward musi zgłaszać 1, a router nadrzędny nie może sam filtrować prywatnych adresów źródłowych.

Udowodnij, że reguła działa, a potem wyizoluj to, co wciąż jest wolne

Liczniki to jedyny uczciwy dowód, że reguła zadziałała. Uruchom szczegółową listę, rozpocznij pobieranie na kliencie i uruchom ją ponownie. Kolumny pakietów i bajtów obok twojej reguły powinny rosnąć, a reguła, która zostaje na zerze, nadal nie pasuje. Jeśli liczniki się ruszają, ale strony nadal zawodzą, porównaj zakres źródłowy z rzeczywistą pulą za pomocą grep -n "^server " /etc/openvpn/server.conf. Jeśli się ruszają i strony się ładują, ale przepustowość jest słaba, tłumaczenie jest gotowe, a pozostały problem jest gdzie indziej.

Porównaj dwa transfery z tego samego klienta, jeden do hosta w sieci lokalnej, a drugi przez tunel do tego samego hosta. Wolno w obu przypadkach wskazuje na łącze nadrzędne Pi lub połączenie Wi-Fi, a nie na VPN. Wolno tylko przez tunel wskazuje na MTU i retransmisje, które możesz sprawdzić za pomocą ip -s link show tun0 przed zmianą jakiegokolwiek ustawienia szyfrowania.

Aby cofnąć eksperyment, przywróć kopię i przeładuj ją, a potem potwierdź, że pierwotna reguła i jej liczniki wróciły. Zapisz urządzenie wyjściowe i polecenie przeładowania w notatkach serwera, bo następna zmiana łącza nadrzędnego znowu odkryje tę samą niezgodność. Reguła wskazująca złe urządzenie pozostaje niewidoczna, dopóki ruch jej nie potrzebuje.