VPN na usmerjevalniku deluje, a odjemalci LAN nimajo interneta

Stanje pravi, da je tunel aktiven, brskalnik na samem usmerjevalniku nalaga strani, vsaka naprava za njim pa še vedno poteče. Ta kombinacija zoži težavo na plast, ki je večina vodnikov za VPN nikoli ne omeni: usmerjevalnik ni edini gostitelj, katerega paketi morajo preživeti tunel. Lokalno ustvarjen promet in posredovani promet gresta po različnih poteh skozi isto škatlo. Preizkusite z odjemalca in razlika ni več teoretična.

Napako preberite z gostitelja LAN

Začnite pri napravi, ki odpove, ker diagnostika, izvedena na usmerjevalniku, odgovarja na drugo vprašanje. Potrdite, da je privzeti prehod odjemalca ta usmerjevalnik, zapišite njegov izvorni naslov in podomrežje, nato poglejte, kaj zapusti tunelski vmesnik usmerjevalnika.

Če je naslov odjemalca preveden, oddaljena stran vidi naslov tunela in od tam je vse videti zdravo, medtem ko odjemalec še vedno odpove. Če ni preveden, mora oddaljena stran poznati pot nazaj v podomrežje odjemalca, mnogi prehodi pa takšne poti privzeto nimajo. Kakorkoli, uspeh samega usmerjevalnika ni pomemben, ker so bili njegovi paketi ustvarjeni lokalno in nikoli niso šli po poti posredovanja.

Lokalni in posredovani promet se razlikujeta

Linux in večina vdelane programske opreme usmerjevalnikov obravnavata pakete, ki nastanejo v škatli, drugače kot pakete, ki gredo skoznjo. Izhodna veriga vidi prvo vrsto, veriga forward vidi drugo, in politika, prilagojena prometu samega usmerjevalnika, lahko posredovanje pusti nedotaknjeno.

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'

Preverite, ali je posredovanje sploh omogočeno, nato berite verigo forward namesto izhodne verige. Pravilo, ki dovoljuje šifrirano zunanjo povezavo, ni pravilo, ki dovoljuje posredovanje dešifriranih paketov, in zamenjava teh dveh ustvari natanko ta simptom. Aktiven tunel dokazuje le prvo.

Tudi povratna pot mora obstajati

Prevajanje izvora odloči, ali je povratna pot potrebna. Z maskiranjem na tunelskem vmesniku se odgovori vrnejo na naslov tunela in usmerjevalnik jih prevede nazaj. Brez tega oddaljeni prehod potrebuje izrecno pot v podomrežje odjemalca, njegova lastna politika pa mora to smer dovoliti.

Preden karkoli spremenite, zapišite, katero od dveh zasnov uporablja namestitev, ker popravki kažejo v nasprotni smeri. Dodajanje prevajanja skrije manjkajočo povratno pot in pokvari aplikacije, ki potrebujejo prvotni izvorni naslov. Dodajanje povratne poti brez prevajanja tiho spodleti, ko oddaljeni požarni zid zavrže neznani vir. Izberite eno, dokumentirajte jo in uskladite drugo stran.

DNS odjemalca sodi v isti pregled. Usmerjevalnikov razreševalnik lahko odgovori, medtem ko odjemalec, usmerjen na drug strežnik, ne dobi ničesar.

Preverite en dovoljen in en zavrnjen tok

Po popravku preizkusite novo povezavo z odjemalca, ne obstoječe seje usmerjevalnika. Nato potrdite, da segment, ki ne bi smel uporabljati tunela, tega še vedno ne uporablja.

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

Preverite opaženi izvorni naslov na oddaljenem koncu, ker ta pove, katera zasnova dejansko teče. Preverite tudi iskanje imena in naslov, ker je vedenje razreševalnika ločena pot skozi isto škatlo.

Držite pravila omejena na odjemalska omrežja, ki potrebujejo tunel, in se uprite skušnjavi, da bi izklopili filter posredovanja, da bi en test uspel. Ta sprememba popravi test in odstrani mejo, ki naj bi jo tunel zagotavljal. Zapišite izvorni naslov, odločitev o prevajanju in povratno pot v eno opombo, z datumom.