Aplikaĵo ligita al interfaco? Ĝia VPN-vojo ne estas la implicita

Unu aplikaĵo sur la maŝino eliras tra la VPN kaj alia ne, kaj ambaŭ uzantoj ĵuras, ke ili ŝanĝis nenion. La diferenco ofte estas ligeja decido de la aplikaĵo mem: ingo ligita al aparato, fonta adreso elektita antaŭ la konekto aŭ nomspaco kun propra enkursiga tabelo. Ĉiu el ili ŝanĝas, kiu vojo validas, kaj neniu aperas en ĝenerala IP-kontrolo en retumilo.

Tri malsamaj ligoj, tri malsamaj efikoj

Ligo al aparato kaj ligo al fonta adreso estas rilataj operacioj kun malsamaj sekvoj. Liga al aparato povas devigi trafikon eliri tra unu interfaco kaj preterpasi la normalan vojserĉon por tiu ingo. Ligo de fonta adreso ankoraŭ trapasas voj-elekton, sed la elektita fonto povas kongrui kun politika regulo kaj sendi la paketon aliloken. La distingo sonas akademia ĝis regulo enkursigas laŭ fonto. Tiam ĝi decidas ĉion.

Retnoma spaco estas la tria kazo. Ĝi havas proprajn interfacojn kaj propran enkursigan tabelon, do aplikaĵo interne tute ne estas trafata de la implicita agordo de la gastiganto. Trakti ĉiujn tri kiel la saman aferon produktas memfidajn klarigojn, kiuj ne travivas la unuan teston.

Determini, kion la aplikaĵo efektive agordas

Legi la retan agordon de la aplikaĵo aŭ ĝian dokumentitan konduton antaŭ ol tuŝi vojojn. Se ĝi proponas interfacan elekton, kampon por fonta adreso aŭ opcion pri nomspaco, tiu agordo estas la unua afero inspektenda. Se ne, la ligo povas esti interna kaj videbla nur per spurado aŭ per ĝia propra diagnozo.

En Linux, ingaj opcioj kiel SO_BINDTODEVICE havas dokumentitan amplekson kaj permespostulojn, kaj neprivilegia procezo eble tute ne povas agordi ilin. Tiu limigo estas utila indico: se la opcio ne aplikeblas, la aplikaĵo probable ne estas la fonto de la diferenco.

Politika enkursigo legas la fonton

Kiam politika enkursigo estas agordita, regulo povas elekti tabelon laŭ la fonto de la paketo. Ingo, kiu ligas fontan adreson, do povas sekvi regulon, kiun la implicita vojo neniam tuŝas, eĉ se neniu interfaco estas eksplicite nomita.

Ripetu la serĉon kun la sama adresfamilio, fonto kaj nomspaco, kiujn uzas la aplikaĵo. Ĝenerala vojserĉo el ŝelo en la gastiganta nomspaco respondas al alia demando, kaj tiu miskongruo estas la plej ofta kialo, ke funkcianta vojo ŝajnas rompita.

Dividita tunelo kaj helpaj procezoj

Dividita tunelo laŭ aplikaĵo aldonas plian tavolon. La kliento povas kongruigi la pakaĵon aŭ procezon de la aplikaĵo, kaj helpanto, kiu malfermas sian propran ingon, estas aparta subjekto. Lanĉilo kaj ĝia fona servo povas produkti malsamajn konektojn sub la sama videbla nomo.

Kontrolu, ĉu la regulo de dividita tunelo kovras la procezon, kiu efektive konektiĝas. Se la aplikaĵo ligas sin al specifa interfaco kaj la VPN-kliento kongruigas laŭ pakaĵo, la du decidoj povas malkonsenti, sen ke iu el ili estu malĝusta.

Testu la propran vojon de la aplikaĵo

Lanĉu novan peton el la aplikaĵo post ĉiu ŝanĝo. Retumilo montranta la eliron, kiun vi volis, ne estas ekvivalenta pruvo por alia programo ligita al alia interfaco, kaj kaŝmemoraj konektoj povas daŭre uzi la malnovan vojon longe post ŝanĝo de agordo. Fermu la malnovan sesion antaŭ ol juĝi la novan regulon. Alie la testo mezuras la pasintecon.

La Linux-inga referenco dokumentas SO_BINDTODEVICE kaj ĝiajn postulojn. Legu unue la propran agordon de la aplikaĵo, ripetu la serĉon en la sama kunteksto kaj nur poste decidu, ĉu la vojo aŭ la ligo devas ŝanĝiĝi.