PiVPN rankos paspaudimas veikia, puslapiai stringa: patikrinkite MASQUERADE

Telefonas rodo tunelį kaip prijungtą, klientas praneša privatų adresą, o pirmas puslapis vis tiek pakimba įpusėjęs įkėlimą. Toks derinys daugumą žmonių nukreipia prie šifravimo nustatymų ir procesoriaus temperatūros, nors iš tikrųjų ten nieko blogo nėra. Tunelis pakilo, vadinasi, derybos baigėsi; nepavyko kitas žingsnis, kai serveris bando perduoti kliento paketus internetui. Eikite tuo pačiu keliu, kuriuo eina tie paketai, ir neatitikimas dažniausiai matomas vienoje NAT lentelės eilutėje.

Pradėkite nuo to, ką klientas pasiekia ir ko nepasiekia

Iš prijungto kliento įkelkite puslapį, kuris gyvena viešame internete, ir pažymėkite, ar jis nepavyksta iškart, ar užstringa įpusėjęs. Tada atidarykite išteklių pačiame VPN serverio privačiame adrese ir palyginkite abu rezultatus.

Tunelio adresas, kuris atsako į ping, o viešos svetainės baigia laukti, yra persiuntimo arba vertimo problemos požymis, o ne sugedusio rankos paspaudimo. Kliento būsenos skydelis to atskirti negali, nes žino tik tai, kad valdymo kanalas pakeltas. Serveryje patikrinkite tunelio sąsają su ip -br addr show tun0 ir patvirtinkite, kad klientui priskirtas adresas patenka į jūsų sukonfigūruotą baseiną. Jei baseinas ir kliento adresas nesutampa, pirmiausia tai ištaisykite, nes kiekviena žemiau esanti taisyklė derinama su baseinu.

Toliau paklauskite serverio, kurią sąsają jis naudotų pasiekdamas viešą adresą. ip route get 203.0.113.9 pirmoje eilutėje išspausdina pasirinktą įrenginį ir šaltinį. Užsirašykite to įrenginio pavadinimą, nes būtent ši reikšmė turi būti NAT taisyklėje.

Perskaitykite taisyklę, kuri nusprendžia, ar paketai išeis

MASQUERADE perrašo paketą tik tada, kai paketas išeina per taisyklėje nurodytą sąsają. Taisyklė, susieta su laidiniu įrenginiu, nieko nedaro srautui, išeinančiam per Wi-Fi, o paketas išlaiko savo privatų šaltinio adresą iki viršutinio maršrutizatoriaus. Tas maršrutizatorius neturi grįžimo maršruto į jūsų tunelio baseiną, todėl jis atmeta atsakymą, ir klientas mato ryšį, kuris atsidaro ir tada numiršta. Simptomas didėja priklausomai nuo to, kiek puslapio ateina prieš prireikiant pirmo atsakymo.

Išvardykite gyvą lentelę ir skaitykite išėjimo sąsajos stulpelį, o ne tik ieškokite žodžio MASQUERADE. Pridėjimo formos išvestį lengviau palyginti nei suformatuotą sąrašą:

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

Raspberry Pi, kuris kadaise naudojo Ethernet, o dabar naudoja Wi-Fi, pasenęs pavadinimas beveik visada yra visa istorija. Diegėjas užrašė, kuris įrenginys buvo nustatymo metu, o išsaugotas taisyklių rinkinys jį atkuria kiekvieno paleidimo metu. Prieš ką nors kita keisdami, palyginkite įrenginį iš maršruto paieškos su esančiu taisyklėje. Jei jie sutampa, sąsaja nėra jūsų problema ir turėtumėte pereiti prie paskutinio skyriaus skaitiklių. Jei jie skiriasi, pataisa yra vieno žodžio pakeitimas išsaugojimo faile.

Ištaisykite išsaugotą taisyklių rinkinį, o ne tik veikiantį

Tik gyvos lentelės redagavimas išsilaiko iki kito paleidimo, o to tiksliai pakanka įtikinti jus, kad problema išspręsta. Taisyklės, grįžtančios paleidimo metu, gyvena faile, kurį iš naujo įkelia ugniasienės išsaugojimo paketas. Debian pagrindu sukurtuose Pi atvaizduose tas failas paprastai yra /etc/iptables/rules.v4.

Padarykite kopiją prieš liesdami, tada pakeiskite MASQUERADE eilutės išėjimo sąsają įrenginiu, kurį užsirašėte, pavyzdžiui -o wlan0 vietoj -o eth0. Palikite šaltinio diapazoną tokį, koks jis yra, nebent pasikeitė jūsų klientų baseinas. Įkelkite iš naujo ir patvirtinkite, kad taisyklė dabar nurodo tinkamą įrenginį:

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

Du gretimus nustatymus lengva pamiršti. sysctl net.ipv4.ip_forward turi pranešti 1, o viršutinis maršrutizatorius neturi pats filtruoti privačių šaltinio adresų.

Įrodykite, kad taisyklė suveikia, tada išskirkite, kas dar lėta

Skaitikliai yra vienintelis sąžiningas įrodymas, kad taisyklė suveikė. Paleiskite išsamią lentelę, pradėkite atsisiuntimą kliente ir paleiskite ją dar kartą. Paketų ir baitų stulpeliai šalia jūsų taisyklės turėtų augti, o taisyklė, kuri lieka nulyje, vis dar nesutampa. Jei skaitikliai juda, bet puslapiai vis tiek nepavyksta, palyginkite šaltinio diapazoną su tikruoju baseinu su grep -n "^server " /etc/openvpn/server.conf. Jei jie juda ir puslapiai įkeliami, bet pralaidumas prastas, vertimas baigtas, o likusi problema yra kitur.

Palyginkite du perdavimus iš to paties kliento, vieną į vietinio tinklo mazgą, kitą per tunelį į tą patį mazgą. Lėtumas abiem atvejais rodo į Pi išėjimo kanalą arba Wi-Fi ryšį, o ne į VPN. Lėtumas tik per tunelį rodo į MTU ir pakartotinius siuntimus, kuriuos galite patikrinti su ip -s link show tun0 prieš keisdami bet kokius šifravimo nustatymus.

Norėdami atšaukti eksperimentą, atkurkite kopiją ir įkelkite ją iš naujo, tada patvirtinkite, kad pradinė taisyklė ir jos skaitikliai grįžo. Užrašykite išėjimo įrenginį ir įkėlimo komandą serverio pastabose, nes kitas išėjimo kanalo pakeitimas vėl atras tą patį neatitikimą. Taisyklė, nurodanti netinkamą įrenginį, lieka nematoma, kol srautas jos prireikia.