Að flytja VPN-þjón á nýtt opinbert IP: hvað á að athuga fyrst

Að endurúthluta veffangi tekur eina mínútu. Vikan á eftir er þar sem flutningurinn brotnar, og sjaldan þar sem stjórnborð veitandans bendir á. Nýtt opinbert IP er vísað til á fjórum stöðum: sambandið sem dæmoninn hlustar á, traustsakkerið sem biðlarar sannprófa, hver regla sem nefnir gamla veffangið og DNS-færslan sem bindur þau saman. Tveir flutningar líta eins út frá stjórnborði en hegða sér gjörólíkt: að endurúthluta vefanginu á vélinni sem þú rekur, eða reisa annað endpoint og flytja biðlara yfir á það. Athuganirnar hér fyrir neðan setja ódýru bilanimar fyrst, og hver kafli segir við hvaða flutning hann á.

Innskipting á staðnum og samhliða skipting eru ólík verk

Innskipting á staðnum heldur hýsilnum, lyklunum, leiðatöflunni og notendalistanum; aðeins veffangið breytist. Það gerir endurúthlutun fljótandi IP, og hjá nokkrum veitendum tekur gesturinn ekkert eftir, því þýðingin fer fram fyrir framan tilvikið. Endurbygging eða endurúthlutun frá veitanda er harkalegri: gesturinn sér breytinguna, og allt sem hafði gamla gildið í skyndiminni lærir það á sama augnabliki.

Samhliða endpoint er annar hýsill sem vinnur sama verk. Byggðu það, prófaðu með einni prófílu og láttu þann gamla svara þar til sá nýi sannar sig á raunverulegri leið. Verðið er staða. Án sameiginlegra peer-færslna, afturkallana og skráningar hefurðu tvö net sem deila tilviljunarkenndu nafni.

Finndu hvern þann stað þar sem gamla veffangið er skrifað

Byrjaðu á textaleit, því stillingaskrár eru auðveldi helmingurinn. Leitaðu í stillingu dæmonsins, brotum eldveggjarins, markmiðum eftirlitsins og hvaða biðlarapakka sem var búinn til á disknum. Hafðu IPv6-veffangið með ef þú birtir eitt; flutningur sem fylgir aðeins A-færslunni skilur tvíhliða biðlara eftir á gömlu leiðinni.

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

Farðu svo yfir kjarnann, því keyrandi kerfi heldur vefanginu á stöðum sem engin skrá nefnir. Statísk uppspretta-NAT-regla, ipset-færsla, bind-veffang og conntrack-færsla lifa lengur en stillingabreytingin sem fjarlægði þau, og sum lifa endurræsingu af því þau komu til baka úr vistuðu reglusettinu. Einu lagi ofar eru öryggishópar veitandans, markmið hleðslujafnarans og eftirlitsprófanir alls ekki á skráakerfinu þínu.

Skrifaðu skrána niður áður en þú breytir einhverju; hún þjónar einnig sem afturkallaskrift.

Biðlarar með hýsilnafni jafna sig; biðlarar með bókstaflegt IP þagna

Ef biðlarar ná í þjóninn með hýsilnafni er skiptingin að mestu DNS-vandamál, og TTL-ið sem þú settir í gær ræður því hversu illa fer. Leysarar skyndiminnka, stub-leysarar skyndiminnka aftur, og margir biðlarar fletta nafninu aðeins upp á nýrri tengingu, svo komið göng heldur upphafsveffanginu.

Ef endpointið er bókstaflegt veffang er ekkert leyst aftur og ekkert skráir kvörtun. WireGuard geymir leyst sambandsveffang: Endpoint = vpn.example.net:51820 verður IP á þeirri stundu sem wg-quick up keyrir og helst það IP þar til þú breytir því. OpenVPN er mildari: það leysir hýsilnafnið remote við tengingu og reynir, með resolv-retry infinite, DNS aftur við endurtengingu. Með bókstaflegt IP halda bæði áfram að hringja í vél sem er ekki lengur til.

Það sem blekkir fólk er spegilmyndin. Biðlari sem þegar vísar á nýja veffangið, meðan gamli hlustandinn svarar enn, stenst hverja prófun sem þú gerir frá eigin skrifborði. Ég hef látið blekkja mig af þessu: nýja endpointið kom upp í síma í fyrstu tilraun, og biðlari með úrelta prófílu kom aðeins í ljós þegar gamli hlustandinn var slökktur miklu síðar.

Traust flyst ekki með veffanginu

WireGuard aðskilur auðkenni frá aðgengi, sem gerir flutning veffangs nánast ókeypis. Peerar eru auðkenndir með opinberum lykli, og endpointið er aðeins þangað sem pakkarnir fara núna; hýsill uppfærir endpoint peer úr uppsprettuverffangi síðasta sannvottaða pakkans. Aðgerðarlaus peer þarf samt ástæðu til að tala við nýja staðinn, og hann lærir veffangið aðeins þegar setan eldist og handshake-tilraunir mistakast á sýnilegum stað. Skjótar leiðbeiningar WireGuard fjalla um endpoint-reitinn.

TLS-þjónar eru hið gagnstæða tilfelli. Skírteinið er bundið nafni, og biðlari sem hringir í veffang ber saman það sem hann hringdi í við varanöfn viðfangsins. Tengstu með IP við skírteini sem ber aðeins DNS SAN og sannprófunin mistekst: nafnið sem biðlarinn notaði er ekki í skírteininu. Endurútgáfa með IP SAN lagar þá einu tengingu og gerir næsta flutning verri. Að halda hýsilnafni í prófílu og láta verify-x509-name vera á sínum stað heldur prófuninni strangri meðan veffangið undir breytist.

Athugaðu svo við hvað dæmoninn er bundinn; samband sem er fest við gamla veffangið mistekst hljóðlaust. OpenVPN-þjónn sem er ræstur með local 203.0.113.10 neitar að koma upp þegar það veffang er farið, meðan hlustandi á 0.0.0.0 fylgir breytingunni ókeypis. NAT skiptist á sama hátt: MASQUERADE fylgir hvaða veffangi vélinn hefur núna, og statískt SNAT --to-source 203.0.113.10 heldur áfram að endurskrifa á veffang sem þú átt ekki lengur, svo bakflæði hverfur. Ef nýja veffangið kemur með öðrum upstream-gáttum, athugaðu rp_filter: öfug leið sía hendir bakflæði sem kemur á tengi sem kjarninn bjóst ekki við.

Röð skiptingarinnar og sönnunin fyrir að hún virkaði

Lækkaðu TTL daginn áður, reistu nýja hlustandann og sannaðu hann með prófílu sem aðeins þú hefur. Prófun innan sama nets sannar nánast ekkert, svo notaðu síma á farsímaneti og prófaðu eitthvað sem göngin eiga að flytja í stað ping á endpointið.

Fylgstu með báðum vefföngum í gegnum gluggann. wg show all latest-handshakes á nýja hýsilnum, eða stöðuskrá OpenVPN, segir þér hve margir peerar hafa raunverulega flutt sig. Þegar nýja endpointið hefur peerana sem þú bjóst við og hið gamla hefur aðeins eftirbátana, settu gamla hlustandann úr notkun, fjarlægðu úreltu NAT-regluna og fjarlægðu veffangið úr eldvegg veitandans. Að fjarlægja gamla hlustandann er skrefið sem er sleppt, og það lokar bilinu þar sem úrelt prófíla nær enn í gamla netið.

Skrifaðu afturköllunarkveikjuna niður áður en þú byrjar: ef nýja endpointið fær engan handshake frá neinum raunverulegum biðlara eftir samþykktan glugga, endurheimtu gamla veffangið og hættu að dreifa prófílum. Keyrðu leitina aftur eftir það og staðfestu að enginn hlustandi sé enn bundinn við afþjónað veffang. Tveir hlutir berast í næsta flutning: hýsilnafn í biðlaraprófílu svo næsta breyting sé DNS-breyting, og skráin sem geymd er við endurheimtunótur þjónsins.