VPN na ruteru radi, ali LAN klijenti nemaju internet

Status kaže da je tunel aktivan, pregledač na samom ruteru učitava stranice, a svaki uređaj iza njega i dalje ističe. Ta kombinacija sužava problem na sloj koji većina VPN vodiča nikada ne spominje: ruter nije jedini host čiji paketi moraju da prežive tunel. Lokalno generisan saobraćaj i prosleđeni saobraćaj idu različitim putevima kroz istu kutiju. Testirajte sa klijenta i razlika prestaje da bude teorijska.

Pročitajte kvar sa LAN hosta

Počnite od uređaja koji ne uspeva, jer dijagnostika pokrenuta na ruteru odgovara na drugo pitanje. Potvrdite da je podrazumevani gejtvej klijenta ovaj ruter, zabeležite njegovu izvornu adresu i podmrežu, pa pogledajte šta izlazi iz tunelskog interfejsa rutera.

Ako je adresa klijenta prevedena, udaljena strana vidi adresu tunela, i odatle sve izgleda zdravo dok klijent i dalje ne uspeva. Ako nije prevedena, udaljena strana mora da zna rutu nazad ka podmreži klijenta, a mnogi gejtvejevi takvu rutu nemaju po defaultu. U svakom slučaju uspeh samog rutera je nebitan, jer su njegovi paketi generisani lokalno i nikada nisu prošli putem prosleđivanja.

Lokalni i prosleđeni saobraćaj se razlikuju

Linux i većina firmware-a rutera tretiraju pakete nastale u kutiji drugačije od paketa koji kroz nju prolaze. Output lanac vidi prvu vrstu, forward lanac vidi drugu, a politika prilagođena saobraćaju samog rutera može ostaviti prosleđivanje netaknutim.

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

Proverite da li je prosleđivanje uopšte omogućeno, pa čitajte forward lanac umesto output lanca. Pravilo koje dozvoljava šifrovanu spoljnu vezu nije pravilo koje dozvoljava prosleđivanje dešifrovanih paketa, a mešanje ta dva proizvodi tačno ovaj simptom. Aktivan tunel dokazuje samo prvo.

Povratni put takođe mora da postoji

Prevođenje izvora odlučuje da li je povratni put potreban. Uz maskaradiranje na tunelskom interfejsu, odgovori se vraćaju na adresu tunela i ruter ih vraća nazad. Bez toga, udaljeni gejtvej zahteva eksplicitnu rutu ka podmreži klijenta, a njegova sopstvena politika mora da dozvoli taj smer.

Zabeležite koji od dva nacrta primenjuje postavljanje pre nego što bilo šta promenite, jer popravke vode u suprotnim smerovima. Dodavanje prevođenja krije povratnu rutu koja nedostaje i kvari aplikacije kojima je potrebna originalna izvorna adresa. Dodavanje povratne rute bez prevođenja tiho ne uspeva kada udaljeni firewall odbaci nepoznat izvor. Izaberite jedan, dokumentujte ga i uskladite drugu stranu.

DNS klijenta pripada istom pregledu. Ruterov resolver može da odgovori dok klijent usmeren na drugi server ne dobija ništa.

Proverite jedan dozvoljen i jedan zabranjen tok

Posle ispravke, testirajte novu vezu sa klijenta, a ne postojeću sesiju rutera. Zatim potvrdite da segment koji ne bi trebalo da koristi tunel i dalje ne koristi.

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

Proverite posmatranu izvornu adresu na udaljenom kraju, jer ona govori koji nacrt zaista radi. Proverite i pretragu imena i adresu, jer ponašanje resolvera je odvojen put kroz istu kutiju.

Držite pravila ograničena na klijentske mreže kojima je potreban tunel i oduprite se iskušenju da isključite filter prosleđivanja da bi jedan test prošao. Ta promena popravlja test i uklanja granicu koju je tunel trebalo da obezbedi. Zapišite izvornu adresu, odluku o prevođenju i povratnu rutu u jednu belešku, sa datumom.