La adreso de la kunulo ŝanĝiĝis mez-sesie: kion faras float en OpenVPN

La tekkomputilo transiras de la oficeja Wi-Fi al poŝtelefona konekta punkto, la tunelo restas aktiva ankoraŭ kelkajn sekundojn, kaj tiam la trafiko haltas dum la interfaco ankoraŭ asertas, ke ĝi estas konektita. Sur la servilo, la stata listo daŭre montras la malnovan publikan adreson. Ĝuste por tiu situacio ekzistas float, kaj ĝi estas ankaŭ la situacio en kiu homoj atendas de ĝi multe pli ol ĝi faras. Ĝuste difini la limon transformas konfuzan halton aŭ en unulinian agordan ŝanĝon aŭ en tute alian esploron.

Kion float malstreĉas, kaj kion ĝi neniam malstreĉas

Normale sesio daŭre parolas kun la ekstera adreso kaj haveno kun kiuj ĝi komenciĝis, kaj pakaĵoj alvenantaj de aliloke estas ignorataj. La opcio float forigas tiun striktan ligon post kiam la kunulo jam pruvis sin, tiel ke ŝanĝita fonta mapado povas daŭrigi la saman sesion anstataŭ esti forĵetita. Nenio en la kriptografiaj kontroloj ŝanĝiĝas: ŝlosiloj, atestiloj kaj ajna HMAC-protekto restas ĝuste kiel agordite.

Ĝi estas decido por ĉiu pakaĵo, ne politiko pri tio, kiu rajtas konektiĝi. Nekonata maŝino, kiu sendas pakaĵon el nova adreso, pruvis nenion, kaj ĝia pakaĵo estas forĵetata kiel ĉiu alia neaŭtentikigita trafiko. Nur trafiko, kiu trapasas la propran aŭtentikigon de la sesio, povas movi la registritan kunulan adreson, kaj tial estas sekure lasi float ŝaltita en medioj kie klientoj vagadas.

Ĝi ankaŭ diras nenion pri la interna tunelo. Movita ekstera adreso ne realokas tunelan adreson, ne ŝanĝas la naĝejon kaj ne donas al la kunulo aliron al io nova. En la tunelo validas la sama identeco kaj la samaj puŝitaj itineroj antaŭ kaj post la movo. Vagado ankaŭ ne renegocas la datuman kanalon, do la negocita ĉifro kaj ŝlosiloj daŭras.

La pakaĵo, kiu movas sesion, devas aŭtentikiĝi

Komencu sesion laŭ la kutima maniero kontraŭ la agordita fora punkto, kaj float traktas tion, kio okazas kiam la mapado ŝanĝiĝas. Poŝtelefona operatoro, kiu renumeras meze de la fluo, NAT-pordego, kiu reskribas sian havenan mapadon, aŭ tekkomputilo, kiu ŝanĝas sian suprenligon, ĉiuj produktas la saman formon: aŭtentikigitaj pakaĵoj el nova tuple, alvenantaj al sesio, kiu ankoraŭ kredas la malnovan.

Kiam oni demandas, ĉu float funkcias, la utila pruvo estas kompletigita manpremo sekvata de akceptita fonta ŝanĝo, ne protokola linio nur pri la adreso. Koreligu la malnovan kaj la novan eksterajn adresojn kun la sesio, kiu restis viva, kaj poste konfirmu, ke la trafiko vere daŭris tra la tunelo.

Se la sesio mortas anstataŭ moviĝi, la pakaĵo alveninta el la nova adreso probable malsukcesis aŭtentikiĝi aŭ tute ne alvenis. Ambaŭ kazoj aspektas idente de la klienta flanko. Sur la servilo, kaptaĵo sur la publika interfaco diras al vi, kiun vi havas, antaŭ ol vi tuŝos ajnan agordon.

Malkovro estas tute aparta mekanismo

float ne solvas nomojn laŭ tempigilo kaj ne spuras dinamikan DNS-rikordon. Se la gastiga nomo de la servilo komencas solviĝi al nova adreso, senokupa kliento havas neniun kialon rimarki tion kaj neniun pakaĵon de la nova finpunkto por aŭtentikigi. Tiu problemo apartenas al rekonekta logiko, al la propra re-provada konduto de la kliento kaj al DNS, ne al float.

Aldoni la opcion ankoraŭ unufoje ne povas kompensi mankon de itinero al la nova adreso. Ĝi ankaŭ ne helpas kiam la kunulo silentas, ĉar silenta kunulo neniam sendas la aŭtentikigitan pakaĵon, kiu movus ion.

La suba fajroŝirmilo ankaŭ havas voĉon. Regulo, kiu permesas nur la malnovan eksteran finpunkton, blokas la ŝanĝitan adreson antaŭ ol OpenVPN eĉ vidas ĝin, kaj neniu kvanto da klienta agordo tion riparias. Revizu la vivciklon de permesitaj adresoj kiel apartan taskon; larĝigi la regulon al ajna fonto interŝanĝas malgrandan problemon kontraŭ granda.

Kiam NetworkManager posedas la profilon

Komandlinia profilo kaj importita konekto estas apartaj agordoj, kaj redakti unu ne tuŝas la alian. Antaŭ ol supozi, ke la opcio ne estas subtenata, establu, kiun kromprograman tipon la konservita profilo efektive uzas kaj kie ĝiaj valoroj loĝas. La UUID de la profilo estas la identigilo, kiu gravas kiam vi inspektas aŭ modifas ion ajn.

Inspektu la konservitan konekton anstataŭ la originan importan dosieron. Linio, kiu postvivas en .ovpn-dosiero, pruvas nenion se la aktiva administranto neniam aplikis ĝin, kaj redaktilo sen markobutono por donita opcio ankaŭ pruvas nenion pri la kapabloj de la protokolo.

Ne fliku pakaĵigitan kromprogramon por aldoni la konduton, precipe ne per diff skribita por historia versio de nerilata komponanto. Se la instalita integriĝo vere ne povas esprimi la agordon, la ĝusta paŝo estas subtenata profilo aŭ alia klienta vojo aprobita de tiu, kiu posedas la deplojon.

Pruvu la transiron anstataŭ supozi ĝin

Rulu la teston tiel, kiel la fiasko okazas. Konektiĝu, kontrolu trafikon tra la tunelo, devigu la eksteran adreson ŝanĝiĝi, kaj poste kontrolu tri aferojn: la sesio ankoraŭ ekzistas, la registrita kunula adreso moviĝis, kaj reala peto ankoraŭ atingas sian celon. Io ajn malpli ol ĉiuj tri estas parta respondo.

Tenu restaŭran aliron disponebla dum vi testas, ĉar vagadaj eksperimentoj kutimas strandigi la maŝinon de kiu vi laboras. Seria konzolo aŭ ekstrabenda itinero transformas fiaskintan teston en kvinminutan restaŭron anstataŭ viziton al la ejo.

Fine, priskribu nur la kazon, kiun vi praktikis. Sukcesa adresa ŝanĝo dum sesio ne estas pruvo, ke DNS-migradoj, alia klienta efektivigo aŭ rekonstruita profilo kondutos same. La dokumentaro pri link-options deklaras la amplekson de la opcio precize; via testa protokolo devus deklari, kiun parton de tiu amplekso vi efektive kovris.