PiVPN-manpremado funkcias, paĝoj haltas: kontrolu MASQUERADE

Via telefono montras la tunelon kiel konektita, la kliento raportas privatan adreson, kaj la unua paĝo ankoraŭ pendas duonvoje tra la ŝargado. Tiu kombinaĵo sendas plej multajn homojn al ĉifraj agordoj kaj CPU-temperaturoj, kie efektive nenio misas. La tunelo ekfunkciis, do la intertraktado finiĝis; tio, kio malsukcesis, estas la sekva paŝo, kiam la servilo provas transdoni klientajn pakojn al la interreto. Sekvu la saman vojon, kiun prenas tiuj pakoj, kaj la malkongruo kutime videblas en unu linio de la NAT-tabelo.

Komencu per tio, kion la kliento povas kaj ne povas atingi

De la konektita kliento, ŝargu paĝon, kiu loĝas en la publika interreto, kaj notu, ĉu ĝi malsukcesas tuj aŭ haltas duonvoje. Poste malfermu rimedon sur la propra privata adreso de la VPN-servilo kaj komparu la du rezultojn.

Tunela adreso, kiu respondas al ping dum publikaj retejoj finiĝas pro tempolimo, estas la signo de plusenda aŭ traduka problemo, ne de rompita manpremado. La propra statpanelo de la kliento ne povas distingi ilin, ĉar ĝi scias nur, ke la rega kanalo estas supre. Kontrolu sur la servilo la tunelan interfacon per ip -br addr show tun0 kaj konfirmu, ke la adreso atribuita al la kliento falas ene de la adresaro, kiun vi agordis. Se la adresaro kaj la klienta adreso malkongruas, riparu tion unue, ĉar ĉiu regulo sube kongruas kun la adresaro.

Poste demandu la servilon, kiun interfacon ĝi uzus por atingi publikan adreson. ip route get 203.0.113.9 presas la elektitan aparaton kaj fonton en sia unua linio. Notu tiun aparatnomon, ĉar ĝi estas la valoro, kiun la NAT-regulo devas enhavi.

Legu la regulon, kiu decidas, ĉu pakoj eliras

MASQUERADE reskribas pakon nur tiam, kiam la pako eliras tra la interfaco nomita en la regulo. Regulo limigita al drata aparato faras nenion por trafiko, kiu eliras tra Wi-Fi, kaj la pako konservas sian privatan fontadreson ĝis la supra enkursigilo. Tiu enkursigilo havas neniun vojon reen al via tunela adresaro, do ĝi forĵetas la respondon, kaj la kliento vidas konekton, kiu malfermiĝas kaj poste mortas. La simptomo skalas kun kiom da la paĝo alvenas antaŭ ol necesas la unua respondo.

Listigu la vivan tabelon kaj legu la kolumnon de elira interfaco anstataŭ serĉi nur la vorton MASQUERADE. La eligo de la aldonformo estas pli facile komparebla ol formatita listo:

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

Sur Raspberry Pi, kiu iam uzis Ethernet kaj nun uzas Wi-Fi, la eksdata nomo preskaŭ ĉiam estas la tuta historio. La instalilo registris, kiu aparato estis ĉeestanta dum la agordo, kaj la konservita regulkompleto ripetas ĝin ĉe ĉiu lanĉo. Komparu la aparaton el la voja serĉo kun tiu en la regulo antaŭ ol ŝanĝi ion alian. Se ili kongruas, la interfaco ne estas via problemo kaj vi devus iri al la nombriloj en la lasta sekcio. Se ili diferencas, la ripariĝo estas ŝanĝo de unu vorto en la daŭra dosiero.

Riparu la konservitan regulkompleton, ne nur la kurantan

Redakti nur la vivan tabelon daŭras ĝis la sekva relanĉo, kio estas ĝuste sufiĉe longe por konvinki vin, ke la problemo solviĝis. La reguloj, kiuj revenas ĉe lanĉo, loĝas en dosiero, kiun fajroŝirma daŭra pakaĵo reŝargas. Sur Debian-bazitaj Pi-bildoj tiu dosiero kutime estas /etc/iptables/rules.v4.

Prenu kopion antaŭ ol tuŝi ĝin, poste anstataŭigu la eliran interfacon en la MASQUERADE-linio per la aparato, kiun vi notis, ekzemple -o wlan0 anstataŭ -o eth0. Lasu la fontan intervalon kiel ĝi estas, krom se via klienta adresaro ŝanĝiĝis. Reŝargu kaj konfirmu, ke la regulo nun nomas la ĝustan aparaton:

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 apudaj agordoj facile forgesiĝas. sysctl net.ipv4.ip_forward devas raporti 1, kaj la supra enkursigilo ne rajtas mem filtri privatajn fontadresojn.

Pruvu, ke la regulo ekagas, poste izolu, kio ankoraŭ malrapidas

Nombriloj estas la sola honesta pruvo, ke regulo kongruis. Rulu la detalan liston, komencu elŝuton sur la kliento kaj rulu ĝin denove. La kolumnoj de pakoj kaj bajtoj apud via regulo devus kreski, kaj regulo, kiu restas je nulo, ankoraŭ ne kongruas. Se la nombriloj moviĝas sed paĝoj ankoraŭ malsukcesas, komparu la fontan intervalon kun la fakta adresaro per grep -n "^server " /etc/openvpn/server.conf. Se ili moviĝas kaj paĝoj ŝargiĝas sed la trafiko estas malbona, la traduko finiĝis kaj la restanta problemo estas aliloke.

Komparu du transigojn de la sama kliento, unu al gastiganto en la loka reto kaj unu tra la tunelo al tiu sama gastiganto. Malrapide en ambaŭ kazoj montras al la supra kanalo de la Pi aŭ al la Wi-Fi-ligilo, ne al la VPN. Malrapide nur tra la tunelo montras al MTU kaj resendoj, kiujn vi povas ekzameni per ip -s link show tun0 antaŭ ol ŝanĝi ajnan ĉifran agordon.

Por malfari la eksperimenton, restarigu la kopion kaj reŝargu ĝin denove, poste konfirmu, ke la originala regulo kaj ĝiaj nombriloj revenis. Skribu la eliran aparaton kaj la reŝargan komandon en la servilajn notojn, ĉar la sekva supra kanala ŝanĝo retrovos la saman malkongruon. Regulo, kiu nomas la malĝustan aparaton, restas nevidebla ĝis trafiko bezonas ĝin.