Aplikaĵo ligita al la VPN-adreso ankoraŭ uzas la malĝustan itineron

Aplikaĵo ligiĝas al la adreso de la VPN, kaj la konekto tamen eliras per la ordinara implica itinero. Nenio en la ligo malsukcesis; ĝi faris ĝuste tion, kion ligo faras. Ligi ingon al loka adreso elektas la fontan adreson, kiun la kerno metas en la kaplinion. Ĝi ne instalas itineron kaj ne kreas regulon de politiko, kiu sendus pakaĵojn portantajn tiun fonton en apartan tunelon.

La resto de ĉi tiu gvidilo estas la kontrola ordo, kiun mi uzas, kune kun la komando, kiu donas ĉiun observon.

Kion ligo efektive decidas

Ligo atribuas lokan adreson al la ingo. Poste la kerno plenumas la saman itinerserĉon, kiun ĝi plenumus alie, krom se regulo de politiko ŝanĝas, kiun tabelon tiu serĉo legas.

Tial pakaĵo povas eliri kun VPN-fonta adreso sur fizika interfaco. Ĉe la alia flanko ĝi alvenas el privata gamo, kiun la reto neniam atendis sur tiu vojo, la revena trafiko havas neniun itineron reen, kaj la konekto pendas aŭ restartiĝas.

La Linux-referenco pri IP-ingoj dokumentas la semantikon de ligo. La itinerparto loĝas en ip-rule kaj ip-route, kaj tiuj estas apartaj manlibroj pro kialo.

Konfirmu, ke la adreso apartenas al ĉi tiu nomspaco

Adreso, al kiu vi povas ligi, devas ekzisti sur interfaco ene de la reta nomspaco, en kiu la aplikaĵo funkcias. Adreso de partnero, adreso de enirejo aŭ adreso, kiu ekzistas nur en alia nomspaco, ne estas ligeble, kaj la voko malsukcesas per EADDRNOTAVAIL.

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

Rulu tiujn tri en la sama kunteksto kiel la aplikaĵo: sama nomspaco, kaj sama uzanto se vi povas akiri ĝin. Malnova net30-diagramo ne estas pruvo pri tio, kiun adreson via nuna topologio atribuis al la kliento. Legu la interfacon, kiu efektive estas aktiva.

Legu la serĉon por tiu fonto kaj celo

Unu komando respondas la demandon, kiun la ligo ne respondis:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

La unua linio presas la itineron, kiun pakaĵo de tiu fonto al tiu celo prenus, inkluzive de la elira interfaco kaj la preferata fonto. Se ĝi nomas la fizikan interfacon, la ligo kaj la itinero malkonsentas, kaj la pakaĵo eliros kun fonto, al kiu la vojo ne povas reveni.

Poste ip rule show diras al vi, ĉu iu regulo elektus alian tabelon. Prioritatoj gravas ĉi tie, ĉar la unua kongrua regulo venkas, kaj regulo kaptanta ĉion super via regulo faras vian regulon nevidebla.

Instalu regulon de politiko nur se tio estas la dezajno

Font-bazita enkursigado estas intenca dezajno, ne riparo por unu aplikaĵo. Se la posedanto de la politiko volas, ke trafiko el la tunela subreto uzu la tunelon, la regulo apartenas al ties agordo kaj ne al unufoja komando sur via tekkomputilo.

Funkciebla formo estas dediĉita tabelo kun implica itinero tra la tunelo, plus regulo, kiu sendas la VPN-fongan gamon en tiun tabelon. Aldonu la esceptojn, kiujn la dezajno bezonas, ĉar tabelo enhavanta nur tunelan implicitan itineron kaptos celojn, kiuj devas resti lokaj aŭ atingeblaj per la fizika vojo.

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

Malfaru per ip rule del kaj ip route flush table 100. Ĉio aldonita tiel malaperas ĉe restarto, krom se administrilo skribas ĝin, kio estas samtempe sekureca eco kaj kialo ne teni la solan kopion en la historio de via ŝelo.

Kontrolu per tri observoj

Notu la fonton, kiun la aplikaĵo petis, la itineron, kiun la serĉo elektis, kaj la fonton, kiun la servilo efektive vidis.

Tiuj tri povas malkongrui, kaj ĉiu malkongruo montras aliloken. Kaptaĵo sur la tunela interfaco pruvas, ke la pakaĵo eliris kun la ĝusta fonto. Kaptaĵo sur la fizika interfaco pruvas, ke ĝi eliris la malĝustan vojon. La vidpunkto de la servilo estas la sola, kiu pruvas la vojon de fino al fino.

Se la aplikaĵo proponas opcion ligi al aparato aŭ enkursigadan reĝimon por ĉiu aplikaĵo, traktu ĝin kiel alian mekanismon kun aliaj limoj. Similaj agordoj ne ĉiuj kondukas al la sama decido de la kerno.