PiVPN-håndtrykk fungerer, sider henger: sjekk MASQUERADE

Telefonen viser tunnelen som tilkoblet, klienten rapporterer en privat adresse, og den første siden henger fortsatt midt i lastingen. Den kombinasjonen sender de fleste ut i chifferinnstillinger og CPU-temperaturer, der faktisk ingenting er galt. Tunnelen kom opp, så forhandlingen er ferdig; det som feilet er trinnet etterpå, når serveren prøver å overlevere klientens pakker til internett. Gå samme vei som disse pakkene, og avviket er vanligvis synlig på én linje i NAT-tabellen.

Start med hva klienten kan og ikke kan nå

Fra den tilkoblede klienten, last en side som ligger på det offentlige internettet, og legg merke til om den feiler umiddelbart eller henger halvveis. Åpne deretter en ressurs på VPN-serverens egen private adresse og sammenlign de to resultatene.

En tunneladresse som svarer på ping mens offentlige nettsteder går ut på tid, er kjennetegnet på et videresendings- eller oversettelsesproblem, ikke et ødelagt håndtrykk. Klientens eget statuspanel kan ikke skille dem, fordi det bare vet at kontrollkanalen er oppe. Sjekk tunellgrensesnittet på serveren med ip -br addr show tun0 og bekreft at adressen klienten har fått ligger innenfor utvalget du konfigurerte. Hvis utvalget og klientadressen ikke stemmer, fiks det først, fordi hver regel nedenfor matcher på utvalget.

Spør deretter serveren hvilket grensesnitt den ville bruke for å nå en offentlig adresse. ip route get 203.0.113.9 skriver ut den valgte enheten og kilden på sin første linje. Skriv ned enhetsnavnet, fordi det er verdien NAT-regelen må inneholde.

Les regelen som avgjør om pakkene forlater

MASQUERADE skriver bare om en pakke når pakken forlater gjennom grensesnittet som er navngitt i regelen. En regel begrenset til en kablet enhet gjør ingenting for trafikk som går ut over Wi-Fi, og pakken beholder sin private kildeadresse helt til den øvre ruteren. Den ruteren har ingen rute tilbake til tunnelutvalget ditt, så den forkaster svaret, og klienten ser en tilkobling som åpnes og deretter dør. Symptomet skalerer med hvor mye av siden som ankommer før det første svaret trengs.

List den levende tabellen og les ut-grensesnittkolonnen i stedet for å bare lete etter ordet MASQUERADE. Utdataene i tilleggsformen er lettere å sammenligne enn en formatert liste:

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

På en Raspberry Pi som en gang brukte Ethernet og nå bruker Wi-Fi, er det utdaterte navnet nesten alltid hele historien. Installatøren registrerte hvilken enhet som var til stede under oppsettet, og regelsettet som er lagret spiller det av ved hver oppstart. Sammenlign enheten fra ruteoppslaget med den i regelen før du endrer noe annet. Hvis de stemmer, er ikke grensesnittet problemet ditt, og du bør gå videre til tellerne i siste avsnitt. Hvis de avviker, er rettelsen en endring av ett ord i persistensfilen.

Rett det lagrede regelsettet, ikke bare det som kjører

Bare å redigere den levende tabellen holder til neste omstart, som er akkurat lenge nok til å overbevise deg om at problemet er løst. Reglene som kommer tilbake ved oppstart, bor i en fil som en brannmur-persistenspakke laster inn på nytt. På Debian-baserte Pi-avbildninger er den filen vanligvis /etc/iptables/rules.v4.

Ta en kopi før du berører den, og erstatt deretter ut-grensesnittet på MASQUERADE-linjen med enheten du noterte, for eksempel -o wlan0 i stedet for -o eth0. La kildeområdet være som det er, med mindre klientutvalget ditt er endret. Last inn på nytt og bekreft at regelen nå navngir riktig 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

To tilstøtende innstillinger er lette å glemme. sysctl net.ipv4.ip_forward må rapportere 1, og den øvre ruteren må ikke filtrere private kildeadresser selv.

Bevis at regelen fyrer, og isoler deretter hva som fortsatt er tregt

Tellere er det eneste ærlige beviset på at en regel har matchet. Kjør den detaljerte listen, start en nedlasting på klienten og kjør den igjen. Pakke- og bytekolonnene ved siden av regelen din bør stige, og en regel som blir stående på null matcher fortsatt ikke. Hvis tellerne beveger seg men sidene fortsatt feiler, sammenlign kildeområdet med det faktiske utvalget med grep -n "^server " /etc/openvpn/server.conf. Hvis de beveger seg og sidene lastes men gjennomstrømningen er dårlig, er oversettelsen ferdig og det gjenværende problemet er et annet sted.

Sammenlign to overføringer fra samme klient, én til en vert på det lokale nettverket og én gjennom tunnelen til samme vert. Tregt i begge tilfeller peker på Pi-ens oppstrømskobling eller Wi-Fi-forbindelsen, ikke VPN-en. Tregt bare gjennom tunnelen peker på MTU og retransmisjoner, som du kan inspisere med ip -s link show tun0 før du endrer noen kryptinnstilling.

For å angre eksperimentet, gjenopprett kopien og last den inn igjen, og bekreft deretter at den opprinnelige regelen og tellerne er tilbake. Skriv ut-enheten og innlastingskommandoen i servernotatene, fordi den neste endringen av oppstrømskoblingen gjenoppdager det samme avviket. En regel som navngir feil enhet forblir usynlig til trafikken trenger den.