Forrit sem er bundið við VPN-viðfangið notar samt ranga leið

Forrit bindur sig við viðfang VPN-sins, og tengingin fer samt út um venjulegu sjálfgefnu leiðina. Ekkert í bindinu mistókst; það gerði nákvæmlega það sem bind gerir. Að binda sötu við staðbundið viðfang velur upprunaviðfangið sem kjarninn setur í hausinn. Það setur ekki upp leið og býr ekki til stefnureglu sem sendir pakka með þann uppruna í ákveðið göng.

Restin af þessari handbók er athugunaröðin sem ég nota, ásamt skipuninni sem gefur hverja athugun.

Hvað bind ákveður í raun

Bind úthlutar staðbundnu viðfangi til sötunnar. Kjarninn keyrir síðan sömu leiðaruppflettingu og hann hefði keyrt annars, nema stefnuregla breyti því hvaða töflu sú uppfletting les.

Þess vegna getur pakki farið út með VPN-upprunaviðfang á líkamlegu tengi. Hinum megin kemur hann frá einkaneti sem netkerfið bjóst aldrei við á þeirri leið, afturumferðin hefur enga leið til baka og tengingin hangir eða endurstillist.

Linux IP-sataviðmiðun skjalfestir merkingu binds. Leiðarhlutinn býr í ip-rule og ip-route, og það eru aðskildar handbækur af ástæðu.

Staðfestu að viðfangið tilheyri þessu nafnrými

Viðfang sem þú getur bundið við verður að vera til á tengi innan netnafnrýmisins sem forritið keyrir í. Viðfang jafningja, viðfang gáttar eða viðfang sem er aðeins til í öðru nafnrými er ekki hægt að binda, og kallið mistekst með EADDRNOTAVAIL.

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

Keyrðu þessar þrjár í sama samhengi og forritið: sama nafnrými og sami notandi ef þú færð hann. Gamalt net30-skema er ekki sönnun um hvaða viðfang núverandi topología þín úthlutaði skjáborðinu. Lestu tengið sem er í raun virkt.

Lestu uppflettinguna fyrir þann uppruna og áfangastað

Ein skipun svarar spurningunni sem bind svaraði ekki:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

Fyrsta línan prentar leiðina sem pakki frá þeim uppruna að þeim áfangastað myndi fara, þar á meðal útgangstengið og valda upprunann. Ef hún nefnir líkamlega tengið er bindinu og leiðinni ósammála, og pakkinn fer út með uppruna sem leiðin kemst ekki aftur að.

Síðan segir ip rule show þér hvort einhver regla hefði valið aðra töflu. Forgangsröðun skiptir máli hér, því fyrsta reglan sem passar vinnur, og regla sem grípur allt fyrir ofan þína gerir regluna þína ósýnilega.

Settu aðeins upp stefnureglu ef það er hönnunin

Leiðarstýring byggð á uppruna er viljandi hönnun, ekki viðgerð fyrir eitt forrit. Ef eigandi stefnunnar vill að umferð frá gönguundirnetinu noti göngin, á reglan heima í stillingum hans en ekki í einnota skipun á fartölvunni þinni.

Virkjanleg mynd er sérstök tafla með sjálfgefinni leið í gegnum göngin, auk reglu sem sendir upprunasvið VPN-sins í þá töflu. Bættu við undantekningunum sem hönnunin þarf, því tafla sem inniheldur aðeins sjálfgefið göng mun grípa áfangastaði sem eiga að vera staðbundnir eða aðgengilegir um líkamlegu leiðina.

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

Afturkallaðu með ip rule del og ip route flush table 100. Allt sem bætt er við á þennan hátt hverfur við endurræsingu nema stjórnandi skrifi það, sem er bæði öryggiseiginleiki og ástæða til að geyma ekki eina eintakið í skeljarferlinum þínum.

Staðfestu með þremur athugunum

Skráðu upprunann sem forritið bað um, leiðina sem uppflettingin valdi og upprunann sem þjónninn sá í raun.

Þessi þrjú geta stangast á, og hver ágreiningur bendir á annan stað. Upptaka á göngutenginu sannar að pakkinn fór út með rétta upprunann. Upptaka á líkamlega tenginu sannar að hann fór ranga leið. Sýn þjónsins er eina sýnin sem sannar leiðina frá enda til enda.

Ef forritið býður upp á val að binda við tæki eða leiðarstýringarham fyrir hvert forrit, meðhöndlaðu það sem aðra aðferð með öðrum takmörkunum. Svipuð stillingar enda ekki allar í sömu ákvörðun kjarnans.