Rokovanje PiVPN deluje, strani se ustavljajo: preverite MASQUERADE

Telefon prikazuje tunel kot povezan, odjemalec poroča zasebni naslov, prva stran pa vseeno obvisi na polovici nalaganja. Ta kombinacija večino ljudi pošlje v nastavitve šifriranja in k temperaturi procesorja, kjer v resnici ni nič pokvarjeno. Tunel se je dvignil, torej je pogajanje končano; spodletel je naslednji korak, ko poskus poskuša predati pakete odjemalca v internet. Prehodite isto pot, ki jo opravijo ti paketi, in neskladje je običajno vidno v eni vrstici tabele NAT.

Začnite s tem, do česa odjemalec pride in do česa ne

S povezanega odjemalca naložite stran, ki živi na javnem internetu, in opazite, ali odpove takoj ali se ustavi na pol poti. Nato odprite vir na lastnem zasebnem naslovu strežnika VPN in primerjajte oba rezultata.

Naslov tunela, ki odgovarja na ping, medtem ko javna mesta potečejo, je znak težave s posredovanjem ali prevajanjem, ne zlomljenega rokovanja. Odjemalčev lastni statusni panel ju ne more ločiti, ker ve le, da je krmilni kanal dvignjen. Na strežniku preverite vmesnik tunela s ip -br addr show tun0 in potrdite, da naslov, dodeljen odjemalcu, pade v nabor, ki ste ga nastavili. Če se nabor in naslov odjemalca ne ujemata, to najprej popravite, ker se vsako pravilo spodaj ujema z naborom.

Nato vprašajte strežnik, kateri vmesnik bi uporabil za dosego javnega naslova. ip route get 203.0.113.9 v prvi vrstici izpiše izbrano napravo in vir. Zapišite ime te naprave, ker mora biti v pravilu NAT natanko ta vrednost.

Preberite pravilo, ki odloči, ali paketi odidejo

MASQUERADE prepiše paket le, ko paket zapusti vmesnik, naveden v pravilu. Pravilo, vezano na žično napravo, ne naredi ničesar za promet, ki odide prek Wi-Fi, in paket obdrži zasebni izvorni naslov vse do nadrejenega usmerjevalnika. Ta usmerjevalnik nima poti nazaj v vaš nabor tunela, zato odgovor zavrže, in odjemalec vidi povezavo, ki se odpre in nato umre. Simptom narašča s tem, koliko strani prispe, preden je potreben prvi odgovor.

Izpišite živo tabelo in berite stolpec izhodnega vmesnika, namesto da bi le iskali besedo MASQUERADE. Izhod v obliki dodajanja je lažje primerjati kot oblikovan seznam:

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

Na Raspberry Pi, ki je nekoč uporabljal Ethernet, zdaj pa Wi-Fi, je zastarelo ime skoraj vedno cela zgodba. Namestitveni program je zabeležil, katera naprava je bila prisotna ob nastavitvi, in shranjeni nabor pravil jo ob vsakem zagonu znova predvaja. Preden karkoli drugega spremenite, primerjajte napravo iz iskanja poti s tisto v pravilu. Če se ujemata, vmesnik ni vaša težava in pojdite na števce v zadnjem razdelku. Če se razlikujeta, je popravek sprememba ene besede v datoteki obstojnosti.

Popravite shranjeni nabor pravil, ne le tistega, ki teče

Urejanje samo žive tabele zdrži do naslednjega ponovnega zagona, kar je natanko dovolj dolgo, da vas prepriča, da je težava rešena. Pravila, ki se vrnejo ob zagonu, živijo v datoteki, ki jo ponovno naloži paket obstojnosti požarnega zidu. Na podobah Pi, ki temeljijo na Debianu, je ta datoteka običajno /etc/iptables/rules.v4.

Preden se je dotaknete, naredite kopijo, nato zamenjajte izhodni vmesnik v vrstici MASQUERADE z napravo, ki ste si jo zabeležili, na primer -o wlan0 namesto -o eth0. Območje vira pustite tako, kot je, razen če se je vaš nabor odjemalcev spremenil. Znova naložite in potrdite, da pravilo zdaj navaja pravo napravo:

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

Dve sosednji nastavitvi se zlahka pozabita. sysctl net.ipv4.ip_forward mora poročati 1, nadrejeni usmerjevalnik pa ne sme sam filtrirati zasebnih izvornih naslovov.

Dokažite, da pravilo sproži, nato izolirajte, kaj je še počasno

Števci so edini pošten dokaz, da se je pravilo ujemalo. Zaženite podroben seznam, začnite prenos na odjemalcu in ga zaženite znova. Stolpca paketov in bajtov ob vašem pravilu bi morala rasti, pravilo, ki ostane na ničli, pa se še vedno ne ujema. Če se števci premikajo, strani pa še vedno odpovedo, primerjajte območje vira z dejanskim naborom s grep -n "^server " /etc/openvpn/server.conf. Če se premikajo in se strani naložijo, prepustnost pa je slaba, je prevajanje končano in preostala težava je drugje.

Primerjajte dva prenosa z istega odjemalca, enega na gostitelja v lokalnem omrežju in enega skozi tunel na istega gostitelja. Počasno v obeh primerih kaže na izhodno povezavo Pi ali povezavo Wi-Fi, ne na VPN. Počasno samo skozi tunel kaže na MTU in ponovna pošiljanja, ki jih lahko pregledate s ip -s link show tun0 preden spremenite katerokoli nastavitev šifriranja.

Če želite poskus razveljaviti, obnovite kopijo in jo znova naložite, nato potrdite, da sta prvotno pravilo in njegovi števci nazaj. Zapišite izhodno napravo in ukaz za ponovno nalaganje v opombe strežnika, ker bo naslednja sprememba povezave znova odkrila isto neskladje. Pravilo, ki navaja napačno napravo, ostane nevidno, dokler ga promet ne potrebuje.