VPN-beinir virkar en LAN-tæki fá ekkert internet

Staðan segir að göngin séu uppi, vafri á beininum sjálfum hleður síðum og hvert tæki fyrir aftan hann fær samt tímann úr sér. Þessi samsetning þrengir vandamálið að lagi sem flestar VPN-leiðbeiningar nefna aldrei: beinirinn er ekki eina vélin sem þarf að koma pakkunum sínum í gegnum göngin. Umferð sem verður til á staðnum og umferð sem er framsend fara mismunandi leiðir í gegnum sömu vélina. Prófaðu frá biðlara og munurinn hættir að vera fræðilegur.

Lestu bilunina frá LAN-vél

Byrjaðu á tækinu sem bregst, því greiningarferð á beininum svarar annarri spurningu. Staðfestu að sjálfgefna gátt biðlarans sé þessi beinir, skráðu upprunafang og undirnet hans og skoðaðu svo hvað fer út um gönguviðmót beinisins.

Ef fang biðlarans er þýtt sér fjarlæga hliðin fang ganganna og allt virðist heilbrigt þaðan á meðan biðlarinn bregst enn. Ef það er ekki þýtt verður fjarlæga hliðin að þekkja leið til baka að undirneti biðlarans, og mörg gáttir hafa enga slíka leið sjálfgefið. Hvort sem er er árangur beinisins sjálfs óviðkomandi, því pakkar hans urðu til á staðnum og fóru aldrei um framsendingarleiðina.

Staðbundin umferð og framsend umferð eru mismunandi

Linux og flestir beinirstýrikerfi meðhöndla pakka sem verða til í vélinni öðruvísi en pakka sem fara í gegnum hana. Úttakskeðjan sér fyrri tegundina, framsendingarkeðjan sér þá seinni, og stefna sem er sniðin að umferð beinisins sjálfs getur látið framsendingu ósnerta.

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'

Athugaðu hvort framsending sé yfirhöfuð virk, lestu svo framsendingarkeðjuna frekar en úttakskeðjuna. Regla sem leyfir dulkóðuðu ytri tenginguna er ekki regla sem leyfir að afkóðaðir pakkar séu framsendir, og að rugla þessu tvennu framkallar nákvæmlega þessi einkenni. Að göngin séu uppi sannar aðeins hið fyrra.

Afturleiðin verður líka að vera til

Þýðing upprunans ákvarðar hvort afturleið sé nauðsynleg. Með fölsun á gönguviðmótinu koma svörin til baka á fang ganganna og beinirinn afþýðir þau. Án hennar þarf fjarlæga gáttin skýra leið að undirneti biðlarans, og eigin stefna hennar verður að leyfa þá átt.

Skráðu hvora hönnunina uppsetningin notar áður en nokkru er breytt, því viðgerðirnar stefna í gagnstæðar áttir. Að bæta þýðingu við felur afturleið sem vantar og brýtur forrit sem þurfa upprunalega upprunafangið. Að bæta afturleið við án þýðingar bregst hljóðlaust þegar eldveggurinn á hinum endanum hendir ókunnugum uppruna. Veldu aðra, skjalfestu hana og láttu hina hliðina passa.

DNS biðlarans tilheyrir sömu skoðun. Þjónn beinisins getur svarað á meðan biðlari sem bendir á annan þjón fær ekkert.

Staðfestu eitt leyft flæði og eitt neitað flæði

Eftir leiðréttinguna skaltu prófa nýja tengingu frá biðlara frekar en núverandi lotu beinisins. Staðfestu svo að hluti sem á ekki að nota göngin noti þau enn ekki.

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

Athugaðu það upprunafang sem sést í fjarlæga endanum, því það segir þér hver hönnunin er í raun í gangi. Staðfestu bæði nafnauppflettingu og fang, því hegðun þjónsins er aðskilin leið í gegnum sömu vélina.

Haltu reglum bundnum við biðlaranetin sem þurfa göngin og forðastu að slökkva á framsendingarsíunni til að láta eitt próf standast. Sú breyting lagar prófið og fjarlægir mörkin sem göngunum átti að veita. Skrifaðu upprunafangið, ákvörðunina um þýðingu og afturleiðina í eina athugasemd, með dagsetningu.