Vaheta teenusepakkujat ilma saidi VPN-aadresse ümber nummerdamata

Üks haru vahetab internetiteenuse pakkujat ja failiserver jätab oma aadressi alles. See tulemus on marsruuditud saidi VPN-i puhul tavaline ja üllatav igaühele, kes eeldab, et tunneli lõpp-punkti aadress on rakenduse aadress. Need kaks elavad disaini erinevates kihtides ja liikus ainult üks. Nende käsitlemine ühena on viis, kuidas teenusepakkuja migratsioon muutub ümbernummerdamise projektiks.

Kaks aadressiplaani, mis liiguvad sõltumatult

Sisemine plaan kirjeldab privaataadresse, mida rakendused kasutavad: haru server aadressil 10.55.8.20, peakontori prefiks, mis sinna marsruudib, ja tagasitee. Välimine plaan kirjeldab, kuidas kaks lüüsi teineteiseni jõuavad: partneri aadressid, kuulamisportid ja tee üle interneti.

Teenusepakkuja vahetus puudutab välimist plaani. See iseenesest ei nõua sisemise plaani muutmist.

Kahe inventari lahus hoidmine on praktiline põhjus käitada ülekattet ka siis, kui rakendus juba krüpteerib oma liiklust. Ülekate annab teile stabiilse sisemise topoloogia, mis peab vastu välistele muutustele. Rakendus jätab alles oma aadressi, tulemüürireeglid ja DNS-kirjed. Muutuvad ainult transpordikirjed ja see on palju väiksem ülevaatus.

Välimine tunnel kannab sisemist vestlust

Lüüsist lüüsi tunnelis adresseerib välimine IP-päis mõlemat lüüsi. Sisemine päis nimetab endiselt rakenduse tegelikke lõpp-punkte. RFC 7296 lüüsist lüüsi kirjeldus käsitleb seda tavalise marsruutimisena, mis toimetab liiklust tunnelilõpp-punktide kaudu.

Seetõttu saab haru server säilitada 10.55.8.20, samal ajal kui lüüsi avalik aadress muutub. Sisemine pakett ei sisalda teenusepakkuja aadressi üldse.

Eraldus on disaini omadus, mitte automaatne garantii. Kui asendusühendus ei suuda toetatud tunnelit luua või sisemisi marsruute uuesti ei paigaldada, kaotab rakendus oma tee, kuigi selle aadress ei ole muutunud.

Teenusepakkuja kolimisel on endiselt kontrollnimekiri

Välimises kontrollnimekirjas on viis kirjet: partneri aadress või hooldatav nimi, kuulaja ja mis tahes filtreerimine ülesvoolu, tõlkimine teel, oodatav partneri identiteet ja teise lüüsi lubatud seaded. Igaüks võib iseseisvalt ebaõnnestuda. Hoidke eraldi taastetee, kui muudate linki, mis kannab haldust. Kaugjuurdepääsu katkestamine ülemineku ajal on katkestus, mille te ise põhjustasite.

Pärast seda kontrollige haru prefiksit, marsruuti mõlemas suunas, kaitsepoliitikat ja ühte tõelist rakendusevoogu. Värskelt autenditud tunnel ei paranda marsruuti, mis osutab vanale privaatalavõrgule.

Aadresside kattumine teise ühendatud saidiga on eraldi planeerimisprobleem. Teenusepakkuja vahetus ei tekita seda, kuid migratsioon on tavaliselt hetk, mil see pinnale tõuseb.

Mis ei jää püsima: avalik allikas ja sessioonid

Stabiilne privaatne serveriaadress ei ole stabiilne avalik allikas. Kui sirvimine väljub otse uue teenusepakkuja kaudu, näevad veebisaidid uut teenusepakkuja poole suunatud aadressi.

Selle aadressi stabiilsena hoidmine nõuab teadlikku väljunddisaini, millel on oma kättesaadavus ja poliitika. See ei tule tunneliga tasuta kaasa.

Ka loodud sessioonid ei jää tee muutumisel püsima. Tunnel võib sekunditega taastuda ja ikkagi katkestada vana tee külge kinnitatud pikaajalised ühendused. Planeerige üleminek aknale, kus taasühendused on vastuvõetavad. Ärge väitke, et migratsioon jääb nähtamatuks, kui konkreetseid kliente ja nende ajalimiite pole testitud.

Kontrollige kolimist nelja kontrolliga

Pärast muudatust kontrollige järjekorras nelja asja: tunnel on loodud kavandatud partneriga, sisemine marsruut haru prefiksini on olemas, poliitika lubab rakendusevoogu ja rakendus vastab. Igaühel on oma käsk.

Linuxi lüüsil katavad need kolm selle nimekirja keskosa:

ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/health

Hoidke transpordiaadressid ühes inventaris ja rakenduse aadressid teises. Värskendage ainult neid kirjeid, mis tegelikult liikusid. Sisemiste sõltuvuste ümbernummerdamine seetõttu, et tunneli välimine aadress muutus, on välditav töö.