A router VPN-je működik, de a LAN-klienseknek nincs internetük

Az állapot szerint az alagút fut, a router saját böngészője oldalakat tölt be, és minden mögötte lévő eszköz továbbra is időtúllépést kap. Ez a kombináció arra a rétegre szűkíti a problémát, amelyet a legtöbb VPN-útmutató soha nem említ: a router nem az egyetlen gazdagép, amelynek csomagjainak túl kell élniük az alagutat. A helyben keletkező forgalom és a továbbított forgalom különböző útvonalakon halad át ugyanazon a dobozon. Tesztelje kliensről, és a különbség megszűnik elméleti lenni.

Olvassa ki a hibát egy LAN-gazdagépről

Kezdje azzal az eszközzel, amelyik meghibásodik, mert a routeren futtatott diagnosztika más kérdésre válaszol. Erősítse meg, hogy a kliens alapértelmezett átjárója ez a router, jegyezze fel a forrás-címét és az alhálózatát, majd nézze meg, mi lép ki a router alagút-interfészén.

Ha a kliens címe fordítódik, a távoli oldal az alagút címét látja, és onnan minden egészségesnek tűnik, miközben a kliens továbbra is meghibásodik. Ha nem fordítódik, a távoli oldalnak ismernie kell egy visszaútvonalat a kliens alhálózatához, és sok átjárónak alapértelmezésben nincs ilyen útvonala. Mindkét esetben a router saját sikere irreleváns, mert a csomagjai helyben keletkeztek, és soha nem járták be a továbbítási útvonalat.

A helyi és a továbbított forgalom különbözik

A Linux és a legtöbb router-firmware másként kezeli a doboz által létrehozott csomagokat, mint a rajta áthaladó csomagokat. Az output lánc látja az első fajtát, a forward lánc a másodikat, és a router saját forgalmára szabott szabályzat érintetlenül hagyhatja a továbbítást.

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'

Ellenőrizze, hogy egyáltalán engedélyezve van-e a továbbítás, majd a forward láncot olvassa, ne az output láncot. Az a szabály, amely engedélyezi a titkosított külső kapcsolatot, nem az a szabály, amely engedélyezi a visszafejtett csomagok továbbítását, és a kettő összekeverése pontosan ezt a tünetet eredményezi. Az, hogy az alagút fut, csak az elsőt bizonyítja.

A visszaútvonalnak is léteznie kell

A forrásfordítás dönti el, kell-e visszaútvonal. Ha az alagút-interfészen masquerading van, a válaszok az alagút címére térnek vissza, és a router visszavonja a fordítást. Nélküle a távoli átjárónak kifejezett útvonalra van szüksége a kliens alhálózatához, és a saját szabályzatának engedélyeznie kell ezt az irányt.

Jegyezze fel, hogy a telepítés melyik a két terv közül, mielőtt bármit módosít, mert a javítások ellentétes irányba mutatnak. A fordítás hozzáadása elrejti a hiányzó visszaútvonalat, és elrontja azokat az alkalmazásokat, amelyeknek az eredeti forráscímre van szükségük. A fordítás nélküli visszaútvonal hozzáadása csendben meghiúsul, amikor a távoli tűzfal eldobja az ismeretlen forrást. Válasszon egyet, dokumentálja, és igazítsa hozzá a másik oldalt.

A kliens DNS-e ugyanahhoz az átvizsgáláshoz tartozik. A router feloldója válaszolhat, miközben egy másik kiszolgálóra mutató kliens semmit sem kap.

Ellenőrizzen egy engedélyezett és egy tiltott folyamot

A javítás után kliensről teszteljen új kapcsolatot, ne a router meglévő munkamenetét. Ezután erősítse meg, hogy az a szegmens, amelynek nem szabadna használnia az alagutat, továbbra sem használja.

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

Ellenőrizze a távoli végén megfigyelt forráscímet, mert ez mondja meg, melyik terv fut valójában. Ellenőrizze a névkeresést is a cím mellett, mert a feloldó viselkedése külön útvonal ugyanazon a dobozon.

Tartsa a szabályokat azokra a klienshálózatokra korlátozva, amelyeknek szükségük van az alagútra, és álljon ellen a kísértésnek, hogy egy teszt kedvéért kikapcsolja a továbbítási szűrőt. Az a változtatás megjavítja a tesztet, és eltávolítja azt a határt, amelyet az alagútnak biztosítania kellett. Írja le a forráscímet, a fordítási döntést és a visszaútvonalat egyetlen jegyzetbe, dátummal.