VPN na ruteru radi, ali LAN klijenti nemaju internet

Ruter dolazi do interneta kroz svoj tunel, dok uređaji iza njega ne dolaze. Prosljeđivanje, prevođenje i povratne rute su odvojene dozvole.

Status kaže da je tunel podignut, preglednik na samom ruteru učitava stranice, a svaki uređaj iza njega još uvijek dobija istek vremena. Ta kombinacija sužava problem na sloj koji većina VPN vodiča nikad ne spominje: ruter nije jedini host čiji paketi moraju preživjeti tunel. Lokalno generisan saobraćaj i proslijeđeni saobraćaj idu različitim putevima kroz istu kutiju. Testirajte s klijenta i razlika prestaje biti teorijska.

Pročitajte kvar s LAN hosta

Počnite od uređaja koji ne radi, jer dijagnostika na ruteru odgovara na drugo pitanje. Potvrdite da je klijentov podrazumijevani gateway ovaj ruter, zabilježite njegovu izvornu adresu i podmrežu, a zatim pogledajte šta izlazi iz ruterovog tunelskog interfejsa.

Ako se klijentova adresa prevodi, udaljena strana vidi adresu tunela i odatle sve izgleda zdravo dok klijent još uvijek ne radi. Ako se ne prevodi, udaljena strana mora znati rutu natrag do klijentove podmreže, a mnogi gatewayi nemaju takvu rutu po defaultu. U oba slučaja ruterov vlastiti uspjeh je nebitan, jer su njegovi paketi generisani lokalno i nikad nisu prošli put prosljeđivanja.

Lokalni i proslijeđeni saobraćaj su različiti

Linux i većina ruter firmwarea tretiraju pakete koje stvori sama kutija drugačije od paketa koji kroz nju prolaze. Output lanac vidi prvu vrstu, forward lanac vidi drugu, a politika podešena za ruterov vlastiti saobraćaj može ostaviti prosljeđ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'

Provjerite je li prosljeđivanje uopšte omogućeno, pa čitajte forward lanac umjesto output lanca. Pravilo koje dozvoljava šifrovanu vanjsku vezu nije pravilo koje dozvoljava prosljeđivanje dešifrovanih paketa, a miješanje to dvoje proizvodi upravo ovaj simptom. Podignut tunel dokazuje samo prvo.

Povratni put takođe mora postojati

Prevođenje izvora odlučuje je li povratni put potreban. Uz maskiranje na tunelskom interfejsu, odgovori se vraćaju na adresu tunela i ruter ih poništava. Bez njega udaljeni gateway treba eksplicitnu rutu do klijentove podmreže, a njegova vlastita politika mora dozvoliti taj smjer.

Zabilježite koji od dva dizajna implementacija koristi prije nego što bilo šta promijenite, jer popravke vode u suprotnim smjerovima. Dodavanje prevođenja skriva nedostajuću povratnu rutu i kvari aplikacije kojima treba originalna izvorna adresa. Dodavanje povratne rute bez prevođenja tiho pada kad udaljeni firewall odbaci nepoznat izvor. Odaberite jedno, dokumentujte to i uskladite drugu stranu.

Klijentski DNS pripada istom pregledu. Ruterov resolver može odgovoriti dok klijent usmjeren na drugi server ne dobija ništa.

Provjerite jedan dozvoljeni i jedan odbijeni tok

Nakon ispravke testirajte novu vezu s klijenta, a ne postojeću ruterovu sesiju. Zatim potvrdite da segment koji ne bi trebao koristiti tunel to i dalje ne čini.

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

Provjerite zabilježenu izvornu adresu na udaljenoj strani, jer ona govori koji dizajn zaista radi. Provjerite i pretragu imena kao i adresu, jer je ponašanje resolvera odvojen put kroz istu kutiju.

Držite pravila ograničena na klijentske mreže kojima tunel treba, i oduprite se iskušenju da onemogućite filter prosljeđivanja kako bi jedan test prošao. Ta promjena popravlja test i uklanja granicu koju je tunel trebao pružiti. Upišite izvornu adresu, odluku o prevođenju i povratnu rutu u jednu bilješku, s datumom.

Povezani članci