Transloki VPN-servilon al nova publika IP: kion unue kontroli

Reasigni adreson daŭras unu minuton. La sekva semajno estas kie la translokiĝo rompiĝas, kaj malofte kie la konzolo de la provizanto sugestas. Nova publika IP estas referencata en kvar lokoj: la ingo sur kiu la demono aŭskultas, la fida ankro kiun klientoj kontrolas, ĉiu regulo kiu nomas la malnovan adreson, kaj la DNS-rikordo kiu ligas ilin. Du translokiĝoj aspektas identaj el regpanelo sed kondutas tute malsame: reasigni la adreson sur la maŝino kiun vi funkciigas, aŭ starigi duan finpunkton kaj movi klientojn al ĝi. La kontroloj sube metas la malmultekostajn fiaskojn unue, kaj ĉiu sekcio nomas por kiu translokiĝo ĝi validas.

Loka anstataŭigo kaj paralela transiro estas malsamaj taskoj

Loka anstataŭigo konservas la gastigan maŝinon, la ŝlosilojn, la enkursigan tabelon kaj la uzantliston; nur la adreso ŝanĝiĝas. Tion faras reasigno de flosanta IP, kaj ĉe pluraj provizantoj la gasto tute ne rimarkas, ĉar la traduko okazas antaŭ la instanco. Rekonstruo aŭ reasigno fare de la provizanto estas pli kruda: la gasto vidas la ŝanĝon, kaj ĉio kio kaŝmemorigis la malnovan valoron ekscias ĝin en la sama momento.

Paralela finpunkto estas dua gastiga maŝino faranta la saman taskon. Konstruu ĝin, testu ĝin per unu profilo, kaj lasu la malnovan respondi ĝis la nova pruvos sin sur reala vojo. La prezo estas stato. Sen komunaj peer-rikordoj, revokoj kaj protokolado, vi havas du retojn kiuj hazarde kunhavas nomon.

Trovu ĉiun lokon kie la malnova adreso estas skribita

Komencu per teksta traserĉo, ĉar agordaj dosieroj estas la facila duono. Serĉu en la demona agordo, fajroŝirmilaj fragmentoj, monitoringaj celoj kaj ajna generita klienta pakaĵo sur la disko. Inkluzivu la IPv6-adreson se vi publikigas unu; translokiĝo kiu sekvas nur la A-rikordon lasas dul-stakajn klientojn sur la malnova vojo.

OLD=203.0.113.10
grep -RIn -- "$OLD" /etc /root
ss -lunpt | grep -F "$OLD"
nft list ruleset | grep -F "$OLD"
iptables-save | grep -F "$OLD"
wg show all endpoints

Poste traserĉu la kernon, ĉar funkcianta sistemo tenas la adreson en lokoj kiujn neniu dosiero mencias. Statika fonta NAT-regulo, ipset-rikordo, liga adreso kaj conntrack-rikordo postvivas la agordan redakton kiu forigis ilin, kaj kelkaj postvivas restartigon ĉar ili revenis el konservita regulkompleto. Unu tavolon pli alte, la sekurecaj grupoj de la provizanto, la celoj de la ŝarĝbalancilo kaj la monitoringaj kontroloj tute ne estas sur via dosiersistemo.

Skribu la inventaron antaŭ ol ŝanĝi ion; ĝi servas ankaŭ kiel retroigskripto.

Gastignomaj klientoj resaniĝas; literal-IP-klientoj silentas

Se klientoj atingas la servilon per gastignomo, la transiro estas plejparte DNS-problemo, kaj la TTL kiun vi agordis hieraŭ decidas kiom malbone ĝi estos. Solviloj kaŝmemorigas, stub-solviloj kaŝmemorigas denove, kaj multaj klientoj serĉas la nomon nur ĉe nova konekto, do establita tunelo tenas sian komencan adreson.

Se la finpunkto estas literala adreso, nenio resolviĝas denove kaj nenio protokolas plendon. WireGuard konservas solvitan ingoadreson: Endpoint = vpn.example.net:51820 fariĝas IP en la momento kiam wg-quick up funkcias kaj restas tiu IP ĝis vi ŝanĝos ĝin. OpenVPN estas pli indulgema: ĝi solvas la gastignomon remote ĉe konekto kaj, kun resolv-retry infinite, provas DNS denove ĉe rekonekto. Kun literala IP, ambaŭ daŭre vokas maŝinon kiu ne plu ekzistas.

Kio misgvidas homojn estas la spegula bildo. Kliento jam direktita al la nova adreso, dum la malnova aŭskultanto ankoraŭ respondas, trapasas ĉiun teston kiun vi faras de via propra skribotablo. Mi estis trompita de tio: la nova finpunkto ekfunkciis sur telefono per unu provo, kaj kliento kun kaduka profilo aperis nur kiam la malnova aŭskultanto estis malŝaltita multe pli poste.

Fido ne moviĝas kun la adreso

WireGuard apartigas identecon de atingeblo, kio faras adresomovon preskaŭ senkosta. Peer-oj identiĝas per publika ŝlosilo, kaj la finpunkto estas nur kien pakaĵoj nuntempe iras; gastiga maŝino ĝisdatigas la finpunkton de peer el la fonta adreso de la plej freŝa aŭtentikigita pakaĵo. Senaktiva peer tamen bezonas kialon paroli kun la nova loko, kaj ĝi ekscias la adreson nur kiam ĝia seanco maljuniĝas kaj la handshake-ripetoj malsukcesas en videbla loko. La rapida gvidilo de WireGuard kovras la kampon finpunkto.

TLS-bazitaj serviloj estas la mala kazo. La atestilo estas ligita al nomo, kaj kliento kiu vokas adreson komparas tion kion ĝi vokis kun la alternativaj nomoj de la subjekto. Konektu per IP al atestilo portanta nur DNS-SAN kaj la kontrolo malsukcesas: la nomo kiun la kliento uzis ne estas en la atestilo. Reeldonado kun IP-SAN riparas tiun unu konekton kaj igas la sekvan movon pli malbona. Teni gastignomon en la profilo kaj lasi verify-x509-name surloke tenas la kontrolon strikta dum la adreso sube ŝanĝiĝas.

Poste kontrolu al kio la demono estas ligita; ingo fiksita al la malnova adreso malsukcesas silente. OpenVPN-servilo startigita kun local 203.0.113.10 rifuzas ekfunkcii kiam tiu adreso malaperis, dum aŭskultanto sur 0.0.0.0 sekvas la ŝanĝon senpage. NAT disiĝas same: MASQUERADE sekvas kiun ajn adreson la maŝino nun havas, kaj statika SNAT --to-source 203.0.113.10 daŭre reskribas al adreso kiun vi ne plu posedas, do reira trafiko malaperas. Se la nova adreso venas kun alia upstream-kluzo, kontrolu rp_filter: malantaŭvoja filtrado forĵetas reiran trafikon alvenantan sur interfaco kiun la kerno ne atendis.

Ordo de la transiro kaj la pruvoj ke ĝi funkciis

Malaltigu la TTL unu tagon antaŭe, starigu la novan aŭskultanton, kaj pruvu ĝin per profilo kiun nur vi havas. Testo el la sama reto preskaŭ nenion pruvas, do uzu telefonon sur poŝreto kaj testu ion kion la tunelo devas porti anstataŭ ping al la finpunkto.

Observu ambaŭ adresojn tra la fenestro. wg show all latest-handshakes sur la nova gastiganto, aŭ la OpenVPN-statdosiero, diras kiom da peer-oj efektive moviĝis. Kiam la nova finpunkto havas la peer-ojn kiujn vi atendas kaj la malnova nur postrestantojn, emeritigu la malnovan aŭskultanton, forigu la kadukan NAT-regulon kaj forprenu la adreson el la fajroŝirmilo de la provizanto. Forigi la malnovan aŭskultanton estas la paŝo kiu estas preterlasata, kaj ĝi fermas la breĉon kie kaduka profilo ankoraŭ atingas la malnovan reton.

Fiksu la retroigan ellasan kondiĉon skribe antaŭ ol komenci: se la nova finpunkto ne havas handshake de eĉ unu reala kliento post la interkonsentita fenestro, restarigu la malnovan adreson kaj ĉesu disdoni profilojn. Rerunu la traserĉon poste kaj konfirmu ke neniu aŭskultanto ankoraŭ estas ligita al emerita adreso. Du aferoj portiĝas en la sekvan movon: gastignomo en la klienta profilo por ke la sekva ŝanĝo estu DNS-redakto, kaj la inventaro konservita apud la restaŭraj notoj de la servilo.