VPN na routeru funguje, ale klienti v LAN nemají internet

Router se dostane na internet svým tunelem, zatímco zařízení za ním ne. Přesměrování, překlad adres a zpětné trasy jsou oddělená oprávnění.

Stav hlásí, že tunel je nahoře, prohlížeč přímo na routeru načítá stránky a každé zařízení za ním stále vyprší časový limit. Tahle kombinace zužuje problém na vrstvu, kterou většina VPN příruček vůbec nezmiňuje: router není jediný hostitel, jehož pakety musí tunelem projít. Lokálně vytvořený provoz a přesměrovaný provoz jdou stejnou krabicí různými cestami. Otestujte to z klienta a rozdíl přestane být teoretický.

Přečtěte poruchu z hostitele v LAN

Začněte u zařízení, které selhává, protože diagnostika na routeru odpovídá na jinou otázku. Ověřte, že výchozí brána klienta je tento router, poznamenejte si jeho zdrojovou adresu a podsíť a pak se podívejte, co vychází z tunelového rozhraní routeru.

Pokud se adresa klienta překládá, vzdálená strana vidí adresu tunelu a odtud vše vypadá zdravě, zatímco klient stále selhává. Pokud se nepřekládá, vzdálená strana musí znát trasu zpět do klientské podsítě a mnoho bran takovou trasu ve výchozím nastavení nemá. V obou případech je vlastní úspěch routeru nepodstatný, protože jeho pakety vznikly lokálně a nikdy neprošly cestou přesměrování.

Lokální a přesměrovaný provoz jsou různé

Linux a většina firmwaru routerů zachází s pakety vytvořenými samotnou krabicí jinak než s pakety, které jí procházejí. Řetěz output vidí první druh, řetěz forward vidí druhý, a zásada nastavená pro vlastní provoz routeru může přesměrování nechat nedotčené.

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'

Zkontrolujte, zda je přesměrování vůbec zapnuté, a pak čtěte řetěz forward, ne output. Pravidlo, které povoluje šifrované vnější spojení, není pravidlem, které povoluje přesměrovat dešifrované pakety, a záměna obojího vytváří přesně tento příznak. Nahoru postavený tunel dokazuje jen to první.

Zpětná cesta také musí existovat

Překlad zdroje rozhoduje, zda je zpětná cesta potřeba. S maskarádou na tunelovém rozhraní se odpovědi vracejí na adresu tunelu a router je zpětně překládá. Bez ní vzdálená brána potřebuje výslovnou trasu do klientské podsítě a její vlastní zásada musí tento směr povolit.

Poznamenejte, který ze dvou návrhů nasazení používá, než cokoli změníte, protože opravy míří opačnými směry. Přidání překladu skryje chybějící zpětnou trasu a rozbije aplikace, které potřebují původní zdrojovou adresu. Přidání zpětné trasy bez překladu tiše selže, když vzdálený firewall zahodí neznámý zdroj. Vyberte jedno, zdokumentujte to a přizpůsobte druhou stranu.

DNS klienta patří do stejné kontroly. Překladač routeru může odpovídat, zatímco klient nasměrovaný na jiný server nedostane vůbec nic.

Ověřte jeden povolený a jeden zamítnutý tok

Po opravě otestujte nové spojení z klienta, ne existující relaci routeru. Potom ověřte, že segment, který nemá používat tunel, ho stále nepoužívá.

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

Zkontrolujte pozorovanou zdrojovou adresu na vzdáleném konci, protože ta říká, který návrh skutečně běží. Ověřte i vyhledání názvu vedle adresy, protože chování překladače je samostatná cesta přes stejnou krabici.

Držte pravidla omezená na klientské sítě, které tunel potřebují, a odolejte pokušení vypnout filtr přesměrování, aby jeden test prošel. Taková změna opraví test a odstraní hranici, kterou měl tunel poskytovat. Zapište zdrojovou adresu, rozhodnutí o překladu a zpětnou trasu do jedné poznámky s datem.

Související články