PiVPN-handtrykk fungerer, sidene heng: sjekk MASQUERADE

Telefonen viser tunnelen som tilkopla, klienten rapporterer ei privat adresse, og den første sida heng framleis midt i lastinga. Den kombinasjonen sender dei fleste ut i chifferinnstillingar og CPU-temperaturar, der faktisk ingenting er gale. Tunnelen kom opp, så forhandlinga er ferdig; det som feila er trinnet etterpå, når tenaren prøver å overlevere pakkane til klienten til internett. Gå same vegen som desse pakkane, og avviket er vanlegvis synleg på éi line i NAT-tabellen.

Start med kva klienten kan og ikkje kan nå

Frå den tilkopla klienten, last ei side som ligg på det offentlege internettet, og legg merke til om ho feilar med ein gong eller heng halvvegs. Opne deretter ein ressurs på den private adressa til VPN-tenaren sjølv og samanlikn dei to resultata.

Ei tunneladresse som svarar på ping medan offentlege nettstader går ut på tid, er kjenneteiknet på eit videresendings- eller omsetjingsproblem, ikkje eit øydelagt handtrykk. Statuspanelet til klienten sjølv kan ikkje skilje dei, fordi det berre veit at kontrollkanalen er oppe. Sjekk tunellgrensesnittet på tenaren med ip -br addr show tun0 og stadfest at adressa klienten fekk ligg innanfor utvalet du konfigurerte. Viss utvalet og klientadressa ikkje stemmer, rett det først, fordi kvar regel nedanfor matchar på utvalet.

Spør deretter tenaren kva grensesnitt han ville bruke for å nå ei offentleg adresse. ip route get 203.0.113.9 skriv ut den valde eininga og kjelda på den første lina si. Skriv ned einingnamnet, fordi det er verdien NAT-regelen må innehalde.

Les regelen som avgjer om pakkane forlèt

MASQUERADE skriv berre om ein pakke når pakken forlèt gjennom grensesnittet som er nemnt i regelen. Ein regel avgrensa til ei kablet eining gjer ingenting for trafikk som går ut over Wi-Fi, og pakken held på den private kjeldeadressa si heilt til den øvre rutaren. Den rutaren har ingen rute tilbake til tunnelutvalet ditt, så han forkastar svaret, og klienten ser ei tilkopling som opnar og deretter døyr. Symptomet skalerer med kor mykje av sida som kjem inn før det første svaret trengst.

List den levande tabellen og les ut-grensesnittkolonnen i staden for å berre leite etter ordet MASQUERADE. Utdataa i tilleggsforma er lettare å samanlikne enn ei formatert liste:

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

På ein Raspberry Pi som ein gong brukte Ethernet og no brukar Wi-Fi, er det utdaterte namnet nesten alltid heile historia. Installatøren registrerte kva eining som var til stades under oppsettet, og regelsettet som er lagra spelar det av ved kvar oppstart. Samanlikn eininga frå ruteoppslaget med den i regelen før du endrar noko anna. Viss dei stemmer, er ikkje grensesnittet problemet ditt, og du bør gå vidare til teljarane i siste avsnitt. Viss dei avvik, er rettinga ei endring av eitt ord i persistensfila.

Rett det lagra regelsettet, ikkje berre det som køyrer

Berre å redigere den levande tabellen held til neste omstart, som er akkurat lenge nok til å overtyde deg om at problemet er løyst. Reglane som kjem tilbake ved oppstart, bur i ei fil som ein brannmur-persistenspakke lastar inn på nytt. På Debian-baserte Pi-avbilete er den fila vanlegvis /etc/iptables/rules.v4.

Ta ein kopi før du rører han, og erstatt deretter ut-grensesnittet på MASQUERADE-lina med eininga du noterte, til dømes -o wlan0 i staden for -o eth0. La kjeldeområdet vere som det er, med mindre klientutvalet ditt er endra. Last inn på nytt og stadfest at regelen no nemner rett eining:

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øytande innstillingar er lette å gløyme. sysctl net.ipv4.ip_forward må rapportere 1, og den øvre rutaren må ikkje filtrere private kjeldeadresser sjølv.

Prov at regelen fyrt, og isoler deretter kva som framleis er treigt

Teljarar er det einaste ærlege provet på at ein regel har matcha. Køyr den detaljerte lista, start ei nedlasting på klienten og køyr ho igjen. Pakke- og bytekolonnane ved sida av regelen din bør stige, og ein regel som blir ståande på null matchar framleis ikkje. Viss teljarane flyttar seg men sidene framleis feilar, samanlikn kjeldeområdet med det faktiske utvalet med grep -n "^server " /etc/openvpn/server.conf. Viss dei flyttar seg og sidene lastar men gjennomstrøyminga er dårleg, er omsetjinga ferdig og det gjenverande problemet er ein annan stad.

Samanlikn to overføringar frå same klient, éi til ein vert på det lokale nettet og éi gjennom tunnelen til same vert. Treigt i begge tilfelle peikar på oppstraumslenkja til Pi-en eller Wi-Fi-sambandet, ikkje VPN-en. Treigt berre gjennom tunnelen peikar på MTU og retransmisjonar, som du kan inspisere med ip -s link show tun0 før du endrar noka kryptinnstilling.

For å angre eksperimentet, gjenopprett kopien og last han inn igjen, og stadfest deretter at den opphavlege regelen og teljarane er tilbake. Skriv ut-eininga og innlastingskommandoen i tenarnotata, fordi den neste endringa av oppstraumslenkja gjenoppdagar det same avviket. Ein regel som nemner feil eining blir usynleg til trafikken treng han.