Jääkö välityspalvelin vanhaan tunneliosoitteeseen VPN:n uudelleenyhdistämisen jälkeen?

VPN-asiakkaan uudelleenkäynnistys todistaa vain, että tunneli palasi. Se ei kerro mitään välityspalvelimesta, jota käskettiin poistumaan sen kautta. Squid, tinyproxy ja useimmat muut edelleenlähettimet pitävät käynnistyksessä ratkaisemansa paikallisen lähdeosoitteen, kunnes jokin pakottaa ne lataamaan uudelleen. Kun uudelleenyhdistäminen antaa uuden tunneliosoitteen, edelleenlähetin joko epäonnistuu jokaisessa lähtevässä yhteydessä tai alkaa poistua tavallista reittiäsi pitkin.

Toinen epäonnistuminen on se vaarallinen: tunneli on pystyssä, sivut latautuvat ja vain lähtöosoite on väärä.

Aloita kuuntelijasta, älä tunnelista

Pelissä on kolme osoitetta, ja uudelleenyhdistäminen siirtää vain joitakin niistä. Kuuntelija on paikka, johon selain osoittaa, yleensä 127.0.0.1 tai LAN-osoite, eikä sitä kiinnosta, että tunneli vaihtui. Lähtevä paikallinen lähde on se, mitä edelleenlähetin pyytää ytimen käyttää valitessaan seuraavaa hyppyä, ja se on sidottu tunnelilaitteeseen. Julkinen lähtö on se, mitä verkkopalvelin kirjaa, ja se voi olla useiden hyppyjen päässä oleva käännetty osoite.

Julkisen IP:n haku vastaa vain viimeiseen kysymykseen. Se ei voi kertoa, mihin paikalliseen osoitteeseen edelleenlähettimen pitäisi sitoa, koska yksi julkinen lähtö voi piilottaa useita sisäisiä lähteitä. Lue osoite siltä, joka omistaa yhteyden: asiakkaan tilatulosteesta, itse rajapinnasta tai nimiavaruudesta, jossa tunneli elää. Ensimmäisen tunnelilta näyttävän rajapinnan nappaaminen antaa väärän vastauksen heti, kun toinen profiili on olemassa.

Säiliö- ja nimiavaruusasettelut rikkovat tämän oletuksen hiljaa. Yhdessä verkkonimiavaruudessa oleva edelleenlähetin ei voi sitoa tunnelia, joka on toisessa, eikä mikään määrä asetusten muokkausta korjaa sitä.

Neljä tarkistusta ennen kuin muokkaat mitään

Käy ne läpi järjestyksessä. Ensimmäinen epäonnistuva tarkistus on kohta, johon pysähdyt, koska myöhemmät olettavat aiempien pitävän.

1. Varmista, että käytössä oleva tunneli on profiili, jonka ympärille välityspalvelin rakennettiin, ei toinen profiili, joka yhdisti itsensä.
2. Tulosta osoite, joka on nyt kyseisellä laitteella, ja vertaa sitä käynnissä olevan kokoonpanon osoitteeseen.
3. Kysy edelleenlähettimeltä, minkä lähteen se ratkaisi, sen sijaan mitä levyllä oleva tiedosto väittää.
4. Varmista, että edelleenlähettimen liikenne todella alistuu odottamallesi reititys- ja palomuurikäytännölle.

Laitteen osoite on helppo: ip -4 addr show dev tun0 tulostaa nykyisen ja ip -4 route get 1.1.1.1 näyttää, minkä rajapinnan ydin valitsisi kyseiselle kohteelle. Tarkkaan osoitteeseen sitova edelleenlähetin epäonnistuu äänekkäästi, kun osoite katoaa. Laitteeseen sitova tai oletuslähteeseen palaava edelleenlähetin jatkaa toimintaa ja vuotaa, ja se on hiljainen lopputulos.

Sovita dokumentaatio siihen julkaisuun, jota ajat, ei hakutuloksen kärkeen. Squidin lähtevän osoitteen direktiivi on dokumentoitu versiolle v7 ja sitä vanhemmille, ja v8:n dokumentaatio sanoo suoraan, ettei direktiivi ole siellä saatavilla, joten sen ympärille rakennettu skripti ei selviä tästä rajasta (katso Squidin tcp_outgoing_address-viite). Vahvista tuotteen omalla jäsentimellä ennen kuin mitään ladataan uudelleen: squid -k parse ilmoittaa virheistä ja poistuu koskematta käynnissä olevaan prosessiin.

Numeroi jokainen tunneli ja hylkää vanhentuneet vaihdot

Uudelleenyhdistäminen on luovutus, ja luovutukset tarvitsevat järjestyksen. Merkitse jokainen havaittu yhteys laskurilla tai aikaleimalla, joka kasvaa jokaisessa onnistuneessa muodostuksessa, ja kanna merkki ehdokaskokoonpanon sisällä. Kun ehdokkaan merkki on nykyistä vanhempi, hylkää ehdokas sen sijaan että sovellat sen, koska edelliselle tunnelille kirjoitettu hidas päivitys muuten kirjoittaisi nykyisen asetukset yli. Yhdistä tapahtumaryöpyt niin, että lepattava linkki tuottaa yhden siirtymän viidentoista sijaan.

Järjestä työ neljään vaiheeseen: mitätöi vanha lähtötila, odota että yhteyden omistaja ilmoittaa valmistumisesta, rakenna vain hallittu osa ja validoi ja aktivoi sitten palvelunhallinnan kautta. Koko tiedoston uudelleenluonti kahdesta osoitearvosta on se tapa, jolla kuuntelijan rajoitukset, todennus ja kohdekäytäntö katoavat hiljaa. Kunnioita myös tahallista pysäytystä. Apuri, joka jatkaa soittamista tunnelille, jonka käyttäjä sammutti, on bugi, ei resilienssi.

Avoimet pistokkeet eivät seuraa uutta osoitetta

Edelleenlähettimen uudelleenkonfigurointi ei kerro mitään jo muodostetuista yhteyksistä. Tyhjentyvätkö ne vai kuolevat, riippuu tuotteesta, joten tarkkaile käyttäytymistä sen sijaan että olettaisit sen.

Ennen vaihtoa avatun pistokkeen kautta palveltava pyyntö poistuu yhä vanhaa polkua, vaikka uusi kokoonpano olisi oikein. Jos sillä on merkitystä, päätä nimenomaisesti: salli lyhyt tyhjenemisikkuna ja lopeta uuden työn vastaanottaminen, tai sulje vanhat pistokkeet ja hyväksy virheet. Testaa sitten tuoreella yhteydellä ja pidä tulos erillään tyhjenemistarkistuksesta. Myöskään lähteeseen sitominen ei ole turvaraja. Kun liikenne ei saa koskaan koskea tavallista reittiä, pakota se merkeillä ja palomuurisäännöillä, DNS ja IPv6 mukaan lukien, jotta epäonnistunut uudelleenlataus jättää välityspalvelimen nimenomaisesti alas eikä avoimeksi.

Todista uusi lähtö tuoreella pyynnöllä

Ratkaisevaa on aktivoinnin jälkeen avattu pyyntö, ei ping eikä jo välimuistissa ollut sivu. Pyydä välityspalvelimelta todellinen URL ja lue lähtöosoite, jonka kaukopää ilmoittaa, ja vertaa sitä asiakkaan omaan näkemykseen tunnelista, kun palveluntarjoaja näyttää sellaisen.

Pidä jäsennys, uudelleenlataus ja pyyntö erillisinä komentoina, jotta epäonnistuminen osoittaa yhteen vaiheeseen. Kaksi ensimmäistä eivät muuta mitään epäonnistuessaan, ja juuri siksi ne ajetaan ennen uudelleenkäynnistystä.

squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com

Jos uudelleenlataus epäonnistuu, pysäytä palvelu ja korjaa osa; vanhentuneella lähdöllä palveleva välityspalvelin on pahempi kuin lyhyt katkos. Jos uudelleenlataus onnistuu mutta tuore pyyntö poistuu silti jonnekin odottamattomaan, palaa reititystarkistukseen sen sijaan että muokkaisit osoitteita uudelleen. Kirjaa tunnelisukupolvi, jota vasten validoit, jotta seuraavalla uudelleenyhdistämisellä on jotain konkreettista verrattavaa.