Ĉu vi startigas VPN-klienton tra SSH? Unue fiksu vian propran itineron
Kliento kun plena tunelo reverkas la tabelon, kiu portas vian SSH-respondon. Fiksu unu gastigan itineron tra la malnova kluzo, aŭ rulu la klienton en sia propra nomspaco.
Vi SSH-eniras konstruan gastiganton, startigas sur ĝi la VPN-klienton, kaj la seanco ĉesas respondi. Nenio kolapsis, kaj nenio aspektas mise agordita laŭ la evidenta senco. La kliento instalinstruis defaŭltan itineron, do respondoj al via laborejo nun eliras tra la tunelo, kie la adreso de via laborejo ne estas enkursigebla. La interesa parto estas, ke tiu rezulto estis antaŭvidebla, kaj la korekto estas unu itinero skribita antaŭ ol la kliento ekfunkcias. Supozu servilon kun unu retkarteto, kluzo 192.0.2.254, kaj administranto konektanta el 203.0.113.9.
Notu la vojon antaŭ ol ekfunkcii
ip route show default nomas la nunan kluzon kaj interfacon, dum ip route get 203.0.113.9 montras, kiun interfacon kaj fontadreson la kerno uzus por via seanco. Konservu ambaŭ eligojn. Post kiam la tunelo leviĝos, tiuj du komandoj plu priskribu la fizikan vojon, kaj se ili priskribas la tunelon anstataŭe, la seanco jam vivas sur prunteprenita tempo.
La jam establita konekto estas tiu, kiu gravas, do ne validigu nur per nova ensaluto. Nova seanco povas mallonge sukcesi per stato, kiun la malnova jam ne havas.
Fiksu la adreson en la propra agordo de la kliento
Itinero aldonita permane malaperas ĉe restartigo kaj konkurso kun la propraj tabelaj ĝisdatigoj de la kliento, do metu la escepton tie, kie la tabelo estas administrata. Ĉe OpenVPN la ŝlosilvorto net_gateway solviĝas al la kluzo, kiu ekzistis antaŭ la tunelo, do route 203.0.113.9 255.255.255.255 net_gateway tenas ekzakte unu adreson ekster ĝi. WireGuard bezonas alian aliron, ĉar wg-quick mem administras itinerojn: agordu Table = off kaj aldonu la escepton en PostUp, kun kongrua PostDown, kiu forigas ĝin. Ambaŭ formoj esprimas la saman intencon, kaj ambaŭ limigas la escepton al unu adreso anstataŭ malfortigi la tunelon por ĉio.
Por IPv6 la sama ideo prenas unugastigan prefikson, kaj la kazo de envolvita transporto indas memori: se la propra ekstera konekto de la tunelo vivas ĉe fiksa adreso, tiu adreso devas resti ekster la tunelo, kiun ĝi portas, alie la kliento enkursigas sian propran transporton en sin mem.
Aŭ eltiru la ĉefan tabelon el la diskuto
Kiam pluraj servoj sur la gastiganto devas konservi sian normalan vojon, ĉesu redakti la ĉefan tabelon kaj donu al la kliento sian propran. Reta nomspaco kun veth-paro faras tion pure: la defaŭlta itinero de la kliento vivas en alia stako kaj nur procezoj startigitaj interne uzas la tunelon. Politika enkursigado atingas similan lokon por unu celo, sendante kongruan trafikon al dediĉita tabelo, kies defaŭlto ankoraŭ montras al la fizika kluzo. Ĉiu el la aliroj lasas la ĉefan tabelon de la gastiganto sen nova defaŭlta itinero, kaj tiu estas la eco, kiu tenas SSH respondanta.
Ambaŭ estas pli da maŝinaro ol unu gastiga itinero, kaj ambaŭ indas, kiam pli ol unu afero sur la maŝino devas postvivi la tunelon.
Supozu, ke la fikso povas malsukcesi
Itinero ligita al via nuna publika adreso rompiĝas en la momento, kiam via provizanto realigas ĝin. Fora servilo tiam bezonas vojon, kiu ne dependas de tiu adreso: konzolon, duan administran interfacon, aŭ saltgastiganton, kiu restas ekster la tunelo.
Du sekurecaj rimedoj kostas dek minutojn. Gardanto, kiu haltigas la klienton, se konfirma ensaluto ne aperas ene de kelkaj minutoj, transformas elŝloson en prokraston, kaj dua SSH-seanco tenata malfermita dum la ŝanĝo pruvas, ke la escepto funkcias dum la tunelo estas supre. Keepalive-mesaĝoj solaj ne helpas ĉi tie, ĉar la vojo malaperis anstataŭ esti senokupa; ili nur faciligas rimarki la morton.
Kontrolu en la ordo, kiu gravas
Konektu la tunelon, konfirmu, ke la itinero al via adreso ankoraŭ eliras tra la fizika kluzo, poste malfermu novan seancon. Se la nova seanco funkcias kaj la malnova tamen mortas, la kaŭzo estas konekta spurado aŭ ŝtata fajroŝirmilo, ne enkursigado, kio estas malsama korekto.
Skribu la fiksitan adreson kaj la komandon, kiu pruvis ĝin, en la ŝanĝregistron. La sekva persono, kiu startigos klienton sur tiu gastiganto, bezonos ambaŭ, kaj la adreso eble jam ŝanĝiĝis ĝis tiam.