PiVPN-handskakningen fungerar, sidor hänger sig: kontrollera MASQUERADE

Telefonen visar tunneln som ansluten, klienten rapporterar en privat adress, och första sidan hänger ändå kvar halvvägs genom laddningen. Den kombinationen skickar de flesta in i chifferinställningar och CPU-temperaturer, där inget egentligen är fel. Tunneln kom upp, så förhandlingen är klar; det som misslyckades är steget efter, när servern försöker lämna över klientens paket till internet. Gå samma väg som de paketen tar, och avvikelsen syns oftast på en rad i NAT-tabellen.

Börja med vad klienten kan och inte kan nå

Ladda från den anslutna klienten en sida som ligger på det publika internet och notera om den misslyckas direkt eller fastnar halvvägs. Öppna sedan en resurs på VPN-serverns egen privata adress och jämför de två resultaten.

En tunneladress som svarar på ping medan publika webbplatser tidsutvisas är tecknet på ett vidarebefordrings- eller översättningsproblem, inte på en trasig handskakning. Klientens eget statusfönster kan inte skilja dem, eftersom det bara vet att kontrollkanalen är uppe. Kontrollera på servern tunnelns gränssnitt med ip -br addr show tun0 och bekräfta att adressen klienten fick ligger inom den pool du konfigurerade. Om poolen och klientadressen inte stämmer överens, åtgärda det först, eftersom varje regel nedan matchar mot poolen.

Fråga sedan servern vilket gränssnitt den skulle använda för att nå en publik adress. ip route get 203.0.113.9 skriver ut den valda enheten och källan på sin första rad. Skriv ned enhetsnamnet, eftersom det är värdet NAT-regeln måste innehålla.

Läs regeln som avgör om paketen lämnar

MASQUERADE skriver bara om ett paket när paketet lämnar genom gränssnittet som nämns i regeln. En regel som är knuten till en trådbunden enhet gör ingenting för trafik som går ut över Wi-Fi, och paketet behåller sin privata källadress hela vägen till den övre routern. Den routern har ingen väg tillbaka till din tunnelpool, så den kastar svaret, och klienten ser en anslutning som öppnas och sedan dör. Symtomet skalar med hur mycket av sidan som kommer fram innan det första svaret behövs.

Lista den levande tabellen och läs kolumnen för utgående gränssnitt i stället för att bara leta efter ordet MASQUERADE. Utdata i tilläggsformen är lättare att jämföra än en formaterad lista:

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

På en Raspberry Pi som en gång använde Ethernet och nu använder Wi-Fi är det föråldrade namnet nästan alltid hela historien. Installationsprogrammet registrerade vilken enhet som fanns vid installationen, och den sparade regeluppsättningen spelar upp det vid varje start. Jämför enheten från ruttuppslaget med den i regeln innan du ändrar något annat. Om de stämmer överens är gränssnittet inte ditt problem och du bör gå vidare till räknarna i sista avsnittet. Om de skiljer sig är rättelsen en ändring av ett enda ord i persistensfilen.

Rätta den sparade regeluppsättningen, inte bara den som körs

Att bara redigera den levande tabellen håller till nästa omstart, vilket är precis tillräckligt länge för att övertyga dig om att problemet är löst. Reglerna som kommer tillbaka vid start bor i en fil som ett brandväggspersistenspaket läser in på nytt. På Debian-baserade Pi-avbildningar är den filen vanligtvis /etc/iptables/rules.v4.

Ta en kopia innan du rör den, byt sedan ut utgående gränssnitt på MASQUERADE-raden mot enheten du noterade, till exempel -o wlan0 i stället för -o eth0. Låt källområdet vara som det är, om inte din klientpool har ändrats. Läs in på nytt och bekräfta att regeln nu anger rätt enhet:

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

Två intilliggande inställningar är lätta att glömma. sysctl net.ipv4.ip_forward måste rapportera 1, och den övre routern får inte filtrera privata källadresser själv.

Bevisa att regeln slår till och isolera sedan vad som fortfarande är långsamt

Räknarna är det enda ärliga beviset på att en regel har matchat. Kör den utförliga listan, starta en nedladdning på klienten och kör den igen. Paket- och bytekolumnerna intill din regel bör stiga, och en regel som stannar på noll matchar fortfarande inte. Om räknarna rör sig men sidorna fortfarande misslyckas, jämför källområdet med den faktiska poolen med grep -n "^server " /etc/openvpn/server.conf. Om de rör sig och sidorna laddas men genomströmningen är dålig är översättningen klar och det återstående problemet finns någon annanstans.

Jämför två överföringar från samma klient, en till en värd på det lokala nätet och en genom tunneln till samma värd. Långsamt i båda fallen pekar på Pi:ns upplänk eller Wi-Fi-anslutningen, inte på VPN:en. Långsamt bara genom tunneln pekar på MTU och omsändningar, som du kan granska med ip -s link show tun0 innan du ändrar någon kryptoinställning.

För att ångra experimentet, återställ kopian och läs in den igen, bekräfta sedan att den ursprungliga regeln och dess räknare är tillbaka. Skriv ned utgående enhet och omläsningskommandot i servernoteringarna, eftersom nästa upplänksändring återupptäcker samma avvikelse. En regel som anger fel enhet förblir osynlig tills trafiken behöver den.