VPN na routeri funguje, ale klienti LAN nemajú internet

Router sa dostane na internet cez svoj tunel, zatiaľ čo zariadenia za ním nie. Presmerovanie, preklad a spätné trasy sú oddelené povolenia.

Stav hovorí, že tunel je aktívny, prehliadač priamo na routeri načítava stránky a každé zariadenie za ním stále končí časovým limitom. Táto kombinácia zúžuje problém na vrstvu, ktorú väčšina VPN príručiek nikdy nespomína: router nie je jediný host, ktorého pakety musia prežiť tunel. Lokálne generovaná prevádzka a presmerovaná prevádzka idú rôznymi cestami cez tú istú skrinku. Otestujte to z klienta a rozdiel prestane byť teoretický.

Prečítajte poruchu z hosta LAN

Začnite pri zariadení, ktoré zlyháva, pretože diagnostika spustená na routeri odpovedá na inú otázku. Overte, že predvolená brána klienta je tento router, poznačte si jeho zdrojovú adresu a podsiet, a potom sa pozrite, čo vychádza z tunelového rozhrania routera.

Ak je adresa klienta prekladaná, vzdialená strana vidí adresu tunela a odtiaľ všetko vyzerá zdravo, kým klient stále zlyháva. Ak prekladaná nie je, vzdialená strana musí poznať trasu späť do podsiete klienta a mnohé brány takú trasu štandardne nemajú. V každom prípade je úspech samotného routera irelevantný, pretože jeho pakety boli generované lokálne a nikdy neprešli cestou presmerovania.

Lokálna a presmerovaná prevádzka sa líšia

Linux a väčšina firmvéru routerov spracúvajú pakety vzniknuté v skrinke inak ako pakety, ktoré cez ňu prechádzajú. Výstupný reťazec vidí prvý druh, reťazec forward vidí druhý, a politika prispôsobená prevádzke samotného routera môže nechať presmerovanie nedotknuté.

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'

Skontrolujte, či je presmerovanie vôbec zapnuté, a potom čítajte reťazec forward namiesto výstupného reťazca. Pravidlo, ktoré povoľuje šifrované vonkajšie spojenie, nie je pravidlo, ktoré povoľuje presmerovanie dešifrovaných paketov, a zámena týchto dvoch vytvára presne tento príznak. Aktívny tunel dokazuje iba prvé.

Aj spätná trasa musí existovať

Preklad zdroja rozhoduje, či je potrebná spätná trasa. Pri maskovaní na tunelovom rozhraní sa odpovede vracajú na adresu tunela a router ich prekladá späť. Bez toho vzdialená brána potrebuje explicitnú trasu do podsiete klienta a jej vlastná politika musí tento smer povoliť.

Pred akoukoľvek zmenou si poznačte, ktorý z dvoch návrhov nasadenie používa, pretože opravy ukazujú opačnými smermi. Pridanie prekladu skryje chýbajúcu spätnú trasu a pokazí aplikácie, ktoré potrebujú pôvodnú zdrojovú adresu. Pridanie spätnej trasy bez prekladu ticho zlyhá, keď vzdialený firewall zahodí neznámy zdroj. Vyberte jeden, zdokumentujte ho a zosúlaďte druhú stranu.

DNS klienta patrí do rovnakej kontroly. Rozkladač routera môže odpovedať, kým klient nasmerovaný na iný server nedostane vôbec nič.

Overte jeden povolený a jeden zakázaný tok

Po oprave otestujte nové spojenie z klienta, nie existujúcu reláciu routera. Potom potvrďte, že segment, ktorý by nemal používať tunel, ho stále nepoužíva.

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

Skontrolujte pozorovanú zdrojovú adresu na vzdialenom konci, pretože to hovorí, ktorý návrh skutočne beží. Overte aj vyhľadávanie názvov a adresy, pretože správanie rozkladača je samostatná cesta cez tú istú skrinku.

Držte pravidlá obmedzené na klientske siete, ktoré tunel potrebujú, a nepodľahnite pokušeniu vypnúť filter presmerovania, aby jeden test prešiel. Táto zmena opraví test a odstráni hranicu, ktorú mal tunel poskytovať. Zapíšte zdrojovú adresu, rozhodnutie o preklade a spätnú trasu do jednej poznámky, s dátumom.

Súvisiace články