Handshake i PiVPN funksionon, faqet ngecin: kontrolloni MASQUERADE

Telefoni e shfaq tunelin si të lidhur, klienti raporton një adresë private, dhe faqja e parë vazhdon të varet në mes të ngarkimit. Ky kombinim i dërgon shumicën e njerëzve te cilësimet e kriptimit dhe te temperatura e CPU-së, ku në të vërtetë asgjë nuk është prishur. Tuneli u ngrit, pra negociimi përfundoi; ajo që dështoi është hapi pas tij, kur serveri përpiqet t'i dorëzojë pakot e klientit internetit. Ndiqni të njëjtën rrugë që marrin ato pako, dhe mospërputhja zakonisht duket në një rresht të tabelës NAT.

Filloni me atë që klienti arrin dhe nuk arrin

Nga klienti i lidhur, ngarkoni një faqe që jeton në internetin publik dhe vini re nëse dështon menjëherë apo ngec në gjysmë. Më pas hapni një burim në adresën private të vetë serverit VPN dhe krahasoni dy rezultatet.

Një adresë tuneli që përgjigjet ndaj ping ndërsa faqet publike mbarojnë kohën është shenjë e një problemi përcjelljeje ose përkthimi, jo e një handshake të thyer. Paneli i statusit i vetë klientit nuk mund t'i dallojë, sepse di vetëm që kanali i kontrollit është lart. Kontrolloni në server ndërfaqen e tunelit me ip -br addr show tun0 dhe konfirmoni që adresa e caktuar klientit bie brenda grupit që keni konfiguruar. Nëse grupi dhe adresa e klientit nuk përputhen, rregullojeni atë së pari, sepse çdo rregull më poshtë përputhet me grupin.

Më pas pyesni serverin se cilën ndërfaqe do të përdorte për të arritur një adresë publike. ip route get 203.0.113.9 printon pajisjen dhe burimin e zgjedhur në rreshtin e parë. Shkruani emrin e asaj pajisjeje, sepse është vlera që rregulli NAT duhet të përmbajë.

Lexoni rregullin që vendos nëse pakot dalin

MASQUERADE e rishkruan një pako vetëm kur pakoja del përmes ndërfaqes së emërtuar në rregull. Një rregull i kufizuar te një pajisje me kabllo nuk bën asgjë për trafikun që del përmes Wi-Fi, dhe pakoja e mban adresën private të burimit deri te routeri i sipërm. Ai router nuk ka rrugë kthimi drejt grupit të tunelit tuaj, prandaj e hedh përgjigjen, dhe klienti sheh një lidhje që hapet dhe pastaj vdes. Simptoma rritet me atë se sa e faqes arrin para se të nevojitet përgjigja e parë.

Listoni tabelën e gjallë dhe lexoni kolonën e ndërfaqes së daljes në vend që të kërkoni vetëm fjalën MASQUERADE. Dalja në formën e shtimit është më e lehtë për t'u krahasuar sesa një listë e formatuar:

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

Në një Raspberry Pi që dikur përdorte Ethernet dhe tani përdor Wi-Fi, emri i vjetruar është pothuajse gjithmonë e gjithë historia. Instaluesi regjistroi cila pajisje ishte e pranishme gjatë konfigurimit, dhe grupi i rregullave i ruajtur e riprodhon atë në çdo nisje. Krahasoni pajisjen nga kërkimi i rrugës me atë në rregull përpara se të ndryshoni diçka tjetër. Nëse përputhen, ndërfaqja nuk është problemi juaj dhe duhet të kaloni te numëruesit në seksionin e fundit. Nëse ndryshojnë, rregullimi është një ndryshim i një fjale në skedarin e këmbënguljes.

Rregulloni grupin e rregullave të ruajtur, jo vetëm atë që po ekzekutohet

Redaktimi vetëm i tabelës së gjallë zgjat deri në rinisjen tjetër, që është pikërisht aq sa duhet për t'ju bindur se problemi është zgjidhur. Rregullat që kthehen gjatë nisjes jetojnë në një skedar që një paketë këmbënguljeje e murit të zjarrit ringarkon. Në imazhet Pi të bazuara në Debian ai skedar është zakonisht /etc/iptables/rules.v4.

Bëni një kopje përpara se ta prekni, pastaj zëvendësoni ndërfaqen e daljes në rreshtin MASQUERADE me pajisjen që regjistruat, për shembull -o wlan0 në vend të -o eth0. Lëreni diapazonin e burimit siç është, përveç nëse grupi i klientëve ka ndryshuar. Ringarkoni dhe konfirmoni që rregulli tani emërton pajisjen e saktë:

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

Dy cilësime fqinje harrohen lehtë. sysctl net.ipv4.ip_forward duhet të raportojë 1, dhe routeri i sipërm nuk duhet t'i filtrojë vetë adresat private të burimit.

Provoni që rregulli aktivizohet, pastaj izoloni çfarë është ende e ngadaltë

Numëruesit janë prova e vetme e ndershme që një rregull përputhej. Ekzekutoni listën e detajuar, filloni një shkarkim në klient dhe ekzekutojeni përsëri. Kolonat e pakove dhe bajtëve pranë rregullit tuaj duhet të rriten, dhe një rregull që mbetet në zero ende nuk përputhet. Nëse numëruesit lëvizin por faqet ende dështojnë, krahasoni diapazonin e burimit me grupin aktual me grep -n "^server " /etc/openvpn/server.conf. Nëse lëvizin dhe faqet ngarkohen por xhiroja është e dobët, përkthimi ka përfunduar dhe problemi i mbetur është diku tjetër.

Krahasoni dy transferime nga i njëjti klient, një drejt një hosti në rrjetin lokal dhe një përmes tunelit drejt të njëjtit host. E ngadaltë në të dyja rastet tregon lidhjen e sipërme të Pi ose lidhjen Wi-Fi, jo VPN-në. E ngadaltë vetëm përmes tunelit tregon MTU-në dhe ritransmetimet, të cilat mund t'i inspektoni me ip -s link show tun0 përpara se të ndryshoni çfarëdo cilësimi kriptimi.

Për të anuluar eksperimentin, rikthejeni kopjen dhe ringarkojeni, pastaj konfirmoni që rregulli origjinal dhe numëruesit e tij janë kthyer. Shkruani pajisjen e daljes dhe komandën e ringarkimit në shënimet e serverit, sepse ndryshimi i ardhshëm i lidhjes së sipërme do të rizbulojë të njëjtën mospërputhje. Një rregull që emërton pajisjen e gabuar mbetet i padukshëm derisa trafiku të ketë nevojë për të.