Ruuteri VPN töötab, kuid LAN-kliendid ei pääse internetti

Ruuter jõuab internetti oma tunnelit mööda, selle taga olevad seadmed aga mitte. Edasisaatmine, tõlkimine ja tagasiteed on eraldi load.

Olek näitab, et tunnel on üleval, ruuteri enda brauser laadib lehti ja iga selle taga olev seade saab ikkagi ajalõpu. See kombinatsioon kitsendab probleemi kihile, mida enamik VPN-i juhendeid kunagi ei maini: ruuter ei ole ainus host, mille paketid peavad tunnelist läbi pääsema. Kohapeal loodud liiklus ja edasisaadetav liiklus läbivad sama kasti mööda eri teid. Katsetage kliendist ja erinevus lakkab olemast teoreetiline.

Lugege viga LAN-hostist

Alustage seadmest, mis ei tööta, sest ruuteril tehtud diagnostika vastab teisele küsimusele. Kinnitage, et kliendi vaikevärav on see ruuter, märkige üles selle lähteaadress ja alavõrk, ja seejärel vaadake, mis väljub ruuteri tunneli liidesest.

Kui kliendi aadress tõlgitakse, näeb kaugpool tunneliaadressi ja sealt vaadatuna tundub kõik terve, samal ajal kui klient ikka ei tööta. Kui seda ei tõlgita, peab kaugpool teadma tagasiteed kliendi alavõrku, ja paljudel väravatel seda vaikimisi ei ole. Mõlemal juhul on ruuteri enda edu tähtsusetu, sest selle paketid loodi kohapeal ega läbinud kunagi edasisaatmise teed.

Kohalik ja edasisaadetav liiklus on erinevad

Linux ja enamik ruuteri püsivara kohtlevad kasti enda loodud pakette teisiti kui sealt läbivaid pakette. Output-ahel näeb esimest liiki, forward-ahel teist, ja ruuteri enda liiklusele kohandatud poliitika võib jätta edasisaatmise puutumata.

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'

Kontrollige, kas edasisaatmine on üldse lubatud, ja seejärel lugege pigem forward-ahelat kui output-ahelat. Reegel, mis lubab krüpteeritud välisühendust, ei ole reegel, mis lubab dekrüpteeritud pakette edasi saata, ja nende kahe segamine tekitab täpselt selle sümptomi. Tunnel on üleval ainult esimest tõestab.

Ka tagasitee peab olemas olema

Lähteaadressi tõlkimine otsustab, kas tagasiteed on vaja. Kui tunneli liidesel on masquerading, tulevad vastused tagasi tunneliaadressile ja ruuter tühistab tõlkimise. Ilma selleta vajab kaugvärav selget marsruuti kliendi alavõrku ja selle enda poliitika peab seda suunda lubama.

Märkige enne muudatuste tegemist üles, millist kahest lahendusest juurutus kasutab, sest parandused osutavad vastassuundadesse. Tõlkimise lisamine peidab puuduva tagasitee ja rikub rakendusi, mis vajavad algset lähteaadressi. Ilma tõlkimiseta tagasitee lisamine ebaõnnestub vaikselt, kui kaugtulemüür viskab tundmatu lähteallika kõrvale. Valige üks, dokumenteerige see ja viige teine pool sellega kooskõlla.

Kliendi DNS kuulub samasse ülevaatesse. Ruuteri resolver võib vastata, samal ajal kui teisele serverile suunatud klient ei saa üldse mitte midagi.

Kontrollige üht lubatud ja üht keelatud voogu

Pärast parandust katsetage uut ühendust kliendist, mitte olemasolevat ruuteri seanssi. Seejärel kinnitage, et segment, mis ei peaks tunnelit kasutama, ei kasuta seda endiselt.

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

Kontrollige vaadeldud lähteaadressi kaugemas otsas, sest see ütleb, milline lahendus tegelikult töötab. Kontrollige lisaks aadressile ka nimepäringut, sest resolveri käitumine on sama kasti läbiv eraldi tee.

Hoidke reeglid ainult nende kliendivõrkude piires, mis tunnelit vajavad, ja vastustage kiusatusele lülitada edasisaatmise filter välja, et üks test läbi läheks. See muudatus parandab testi ja eemaldab piiri, mille tunnel pidi pakkuma. Kirjutage lähteaadress, tõlkimisotsus ja tagasitee ühte märkmesse, koos kuupäevaga.

Seotud artiklid