PiVPN-håndtryk virker, siderne hænger: tjek MASQUERADE

Din telefon viser tunnelen som forbundet, klienten rapporterer en privat adresse, og den første side hænger stadig midt i indlæsningen. Den kombination sender de fleste ud i cifferindstillinger og CPU-temperaturer, hvor der faktisk ikke er noget i vejen. Tunnelen kom op, så forhandlingen er færdig; det, der fejlede, er trinnet efter, når serveren forsøger at aflevere klientens pakker til internettet. Gå samme vej som de pakker, og uoverensstemmelsen er normalt synlig i én linje i NAT-tabellen.

Start med hvad klienten kan og ikke kan nå

Fra den forbundne klient, indlæs en side der ligger på det offentlige internet, og bemærk om den fejler med det samme eller hænger halvvejs. Åbn derefter en ressource på VPN-serverens egen private adresse, og sammenlign de to resultater.

En tunneladresse, der svarer på ping, mens offentlige websteder løber tør for tid, er kendetegnet på et videresendelses- eller oversættelsesproblem, ikke et brudt håndtryk. Klientens eget statuspanel kan ikke skelne dem, fordi det kun ved, at kontrolkanalen er oppe. Tjek tunnelgrænsefladen på serveren med ip -br addr show tun0 og bekræft, at den adresse klienten har fået, ligger inden for den pulje, du konfigurerede. Hvis puljen og klientadressen ikke stemmer overens, skal du rette det først, fordi hver regel nedenfor matcher på puljen.

Spørg derefter serveren, hvilken grænseflade den ville bruge til at nå en offentlig adresse. ip route get 203.0.113.9 udskriver den valgte enhed og kilde på sin første linje. Skriv enhedsnavnet ned, fordi det er den værdi, NAT-reglen skal indeholde.

Læs den regel, der afgør, om pakker forlader

MASQUERADE omskriver kun en pakke, når pakken forlader gennem den grænseflade, der er nævnt i reglen. En regel, der er bundet til en kablet enhed, gør intet for trafik, der går ud over Wi-Fi, og pakken beholder sin private kildeadresse hele vejen til den øvre router. Den router har ingen rute tilbage til din tunnelpulje, så den dropper svaret, og klienten ser en forbindelse, der åbner og derefter dør. Symptomet skalerer med, hvor meget af siden der ankommer, før det første svar er nødvendigt.

List den levende tabel, og læs ud-grænsefladekolonnen i stedet for at skimme efter ordet MASQUERADE. Tilføj-formens output er lettere at sammenligne end en formateret liste:

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

På en Raspberry Pi, der engang brugte Ethernet og nu bruger Wi-Fi, er det forældede navn næsten altid hele historien. Installationsprogrammet registrerede, hvilken enhed der var til stede under opsætningen, og det gemte regelsæt gentager det ved hver opstart. Sammenlign enheden fra ruteopslaget med den i reglen, før du ændrer noget andet. Hvis de matcher, er grænsefladen ikke dit problem, og du bør gå videre til tællerne i sidste afsnit. Hvis de afviger, er rettelsen en ændring af et ord i persistensfilen.

Ret det gemte regelsæt, ikke bare det kørende

Kun at redigere den levende tabel holder indtil næste genstart, hvilket er præcis længe nok til at overbevise dig om, at problemet er løst. De regler, der vender tilbage ved opstart, bor i en fil, som en firewall-persistenspakke genindlæser. På Debian-baserede Pi-images er den fil normalt /etc/iptables/rules.v4.

Tag en kopi, før du rører den, og erstat så ud-grænsefladen på MASQUERADE-linjen med den enhed, du noterede, for eksempel -o wlan0 i stedet for -o eth0. Behold kildeområdet som det er, medmindre din klientpulje er ændret. Genindlæs og bekræft, at reglen nu nævner den rigtige enhed:

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

To tilstødende indstillinger er nemme at glemme. sysctl net.ipv4.ip_forward skal rapportere 1, og den øvre router må ikke selv filtrere private kildeadresser.

Bevis, at reglen fyrer, og isoler derefter, hvad der stadig er langsomt

Tællere er det eneste ærlige bevis på, at en regel har matchet. Kør den detaljerede liste, start en download på klienten, og kør den igen. Pakke- og byte-kolonnerne ved siden af din regel bør stige, og en regel, der bliver på nul, matcher stadig ikke. Hvis tællerne bevæger sig, men siderne stadig fejler, skal du sammenligne kildeområdet med den faktiske pulje med grep -n "^server " /etc/openvpn/server.conf. Hvis de bevæger sig, og siderne indlæses, men gennemstrømningen er dårlig, er oversættelsen færdig, og det resterende problem er et andet sted.

Sammenlign to overførsler fra samme klient, en til en vært på det lokale netværk og en gennem tunnelen til samme vært. Langsomt i begge tilfælde peger på Pi'ens opkobling eller Wi-Fi-forbindelse, ikke VPN'en. Langsomt kun gennem tunnelen peger på MTU og retransmissioner, som du kan inspicere med ip -s link show tun0 før du ændrer nogen kryptoindstilling.

For at fortryde eksperimentet skal du gendanne kopien og genindlæse den igen og derefter bekræfte, at den oprindelige regel og dens tællere er tilbage. Skriv ud-enheden og genindlæsningskommandoen i servernoterne, fordi den næste opkoblingsændring genopdager den samme uoverensstemmelse. En regel, der nævner den forkerte enhed, forbliver usynlig, indtil trafikken har brug for den.