PiVPN-handshake werkt, pagina’s blijven hangen: controleer de MASQUERADE

Uw telefoon toont de tunnel als verbonden, de client meldt een privéadres, en de eerste pagina blijft toch halverwege het laden hangen. Die combinatie stuurt de meeste mensen naar cipherinstellingen en CPU-temperaturen, waar niets echt mis is. De tunnel kwam omhoog, dus de onderhandeling is afgerond; wat mislukte is de stap erna, wanneer de server clientpakketten naar het internet probeert door te geven. Volg dezelfde route die die pakketten nemen, en de mismatch is meestal zichtbaar in één regel van de NAT-tabel.

Begin bij wat de client wel en niet kan bereiken

Laad vanaf de verbonden client een pagina die op het openbare internet staat en let op of die meteen faalt of halverwege blijft hangen. Open daarna een bron op het eigen privéadres van de VPN-server en vergelijk de twee resultaten.

Een tunneladres dat op pings antwoordt terwijl openbare sites een time-out krijgen, is het kenmerk van een doorstuur- of vertaalprobleem, niet van een kapotte handshake. Het statuspaneel van de client zelf kan die twee niet onderscheiden, omdat het alleen weet dat het controlekanaal omhoog is. Controleer op de server de tunnelinterface met ip -br addr show tun0 en bevestig dat het adres dat de client kreeg binnen de pool valt die u hebt geconfigureerd. Als de pool en het clientadres niet overeenkomen, los dat dan eerst op, want elke regel hieronder matcht op de pool.

Vraag de server vervolgens welke interface hij zou gebruiken om een openbaar adres te bereiken. ip route get 203.0.113.9 drukt het gekozen apparaat en de bron af op de eerste regel. Noteer die apparaatnaam, want dat is de waarde die de NAT-regel moet bevatten.

Lees de regel die bepaalt of pakketten naar buiten gaan

MASQUERADE herschrijft een pakket alleen wanneer het pakket vertrekt via de interface die in de regel wordt genoemd. Een regel die aan een bekabeld apparaat is gebonden, doet niets voor verkeer dat via Wi-Fi naar buiten gaat, en het pakket houdt zijn privébronadres tot aan de bovenliggende router. Die router heeft geen route terug naar uw tunnelpool, dus hij laat het antwoord vallen, en de client ziet een verbinding die opent en dan sterft. Het symptoom schaalt met hoeveel van de pagina aankomt voordat het eerste antwoord nodig is.

Toon de live-tabel en lees de kolom van de uitgaande interface in plaats van alleen naar het woord MASQUERADE te zoeken. De uitvoer van de toevoegvorm is makkelijker te vergelijken dan een opgemaakte lijst:

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

Op een Raspberry Pi die ooit Ethernet gebruikte en nu Wi-Fi gebruikt, is de verouderde naam bijna altijd het hele verhaal. De installer legde vast welk apparaat bij de installatie aanwezig was, en de opgeslagen regelset speelt dat bij elke boot opnieuw af. Vergelijk het apparaat uit de route-opzoeking met dat in de regel voordat u iets anders wijzigt. Als ze overeenkomen, is de interface niet uw probleem en moet u naar de tellers in de laatste sectie gaan. Als ze verschillen, is de oplossing een wijziging van één woord in het persistentiebestand.

Corrigeer de opgeslagen regelset, niet alleen de actieve

Alleen de live-tabel aanpassen houdt stand tot de volgende herstart, en dat is precies lang genoeg om u ervan te overtuigen dat het probleem is opgelost. De regels die bij het opstarten terugkomen, staan in een bestand dat een firewall-persistentiepakket opnieuw laadt. Op Debian-gebaseerde Pi-images is dat bestand meestal /etc/iptables/rules.v4.

Maak een kopie voordat u het aanraakt, en vervang dan de uitgaande interface op de MASQUERADE-regel door het apparaat dat u hebt genoteerd, bijvoorbeeld -o wlan0 in plaats van -o eth0. Laat het bronbereik zoals het is, tenzij uw clientpool is gewijzigd. Laad opnieuw en bevestig dat de regel nu het juiste apparaat noemt:

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

Twee aangrenzende instellingen vergeet je makkelijk. sysctl net.ipv4.ip_forward moet 1 rapporteren, en de bovenliggende router mag privébronadressen niet zelf filteren.

Bewijs dat de regel vuurt en isoleer daarna wat nog traag is

Tellers zijn het enige eerlijke bewijs dat een regel heeft gematcht. Voer de uitgebreide lijst uit, start een download op de client en voer die opnieuw uit. De pakket- en bytekolommen naast uw regel zouden moeten stijgen, en een regel die op nul blijft, matcht nog steeds niet. Als de tellers bewegen maar de pagina’s falen nog, vergelijk dan het bronbereik met de werkelijke pool met grep -n "^server " /etc/openvpn/server.conf. Als ze bewegen en de pagina’s laden maar de doorvoer is slecht, is de vertaling klaar en zit het resterende probleem elders.

Vergelijk twee overdrachten vanaf dezelfde client, één naar een host op het lokale netwerk en één via de tunnel naar diezelfde host. Traag in beide gevallen wijst op de uplink of de Wi-Fi-verbinding van de Pi, niet op de VPN. Traag alleen via de tunnel wijst op MTU en hertransmissies, die u kunt inspecteren met ip -s link show tun0 voordat u welke crypto-instelling dan ook wijzigt.

Om het experiment terug te draaien, herstelt u de kopie en laadt u die opnieuw, en bevestigt u daarna dat de oorspronkelijke regel en de tellers terug zijn. Schrijf het uitgaande apparaat en het herlaadcommando in de servernotities, want de volgende uplinkwijziging ontdekt dezelfde mismatch opnieuw. Een regel die het verkeerde apparaat noemt, blijft onzichtbaar tot het verkeer hem nodig heeft.