Kas puhverserver on pärast VPN-i taasühendamist ikka veel vana tunneliaadressi peal?

VPN-kliendi taaskäivitamine tõestab ainult seda, et tunnel tuli tagasi. See ei ütle midagi puhverserveri kohta, kellele anti käsk selle kaudu välja minna. Squid, tinyproxy ja enamik teisi edastajaid hoiavad kohalikku lähteaadressi, mille nad käivitamisel leidsid, kuni miski sunnib neid uuesti laadima. Kui taasühendamine annab uue tunneliaadressi, siis edastaja kas ebaõnnestub igal väljuval ühendusel või hakkab väljuma teie tavalisel marsruudil.

See teine tõrge on ohtlik: tunnel töötab, lehed laadivad ja ainult väljundiaadress on vale.

Alustage kuulajast, mitte tunnelist

Mängus on kolm aadressi ja taasühendamine liigutab ainult mõnda neist. Kuulaja on see, kuhu teie brauser osutab, tavaliselt 127.0.0.1 või LAN-i aadress, ja teda ei huvita, et tunnel muutus. Väljuv kohalik lähtekoht on see, mida edastaja palub tuumal kasutada järgmise hüppe valimisel, ja see on seotud tunnelseadmega. Avalik väljund on see, mida veebiserver logib, ja see võib olla mitme hüppe kaugusel tõlgitud aadress.

Avaliku IP otsing vastab ainult viimasele küsimusele. See ei saa teile öelda, millise kohaliku aadressiga edastaja peaks liituma, sest üks avalik väljund võib peita mitut sisemist allikat. Lugege aadressi sellelt, kes ühendust omab: kliendi olekuväljundist, liidesest endast või nimeruumist, kus tunnel elab. Esimese tunnelilaadse nimega liidese haaramine annab vale vastuse niipea, kui on olemas teine profiil.

Konteineri- ja nimeruumipaigutused rikuvad seda eeldust vaikselt. Ühes võrgu nimeruumis olev edastaja ei saa liituda tunneliga, mis on teises, ja ükski konfiguratsiooni muudatus ei paranda seda.

Neli kontrolli enne, kui midagi muudate

Käige need järjekorras läbi. Esimene kontroll, mis ebaõnnestub, on koht, kus peatute, sest hilisemad eeldavad, et varasemad kehtivad.

1. Kinnitage, et kasutatav tunnel on profiil, mille ümber puhverserver ehitati, mitte teine profiil, mis ühendus ise.
2. Printige aadress, mis on praegu sellel seadmel, ja võrrelge seda jooksva konfiguratsiooni aadressiga.
3. Küsige edastajalt, millise lähtekoha see leidis, mitte mida ketas olev fail väidab.
4. Kinnitage, et edastaja liiklus allub tõesti marsruutimis- ja tulemüüripoliitikale, mida ootate.

Seadme aadress on lihtne: ip -4 addr show dev tun0 prindib praeguse ja ip -4 route get 1.1.1.1 näitab, millise liidese tuum selle sihtkoha jaoks valiks. Täpse aadressi külge liituv edastaja ebaõnnestub valjult, kui aadress kaob. Seadme külge liituv või vaikimisi lähtekohale tagasi langev edastaja töötab edasi ja lekib, ja see on vaikne tulemus.

Sobitage dokumentatsioon teie jooksutatava väljaandega, mitte otsingu esimese tulemusega. Squidi väljuva aadressi direktiiv on dokumenteeritud v7 ja varasemate jaoks ning v8 dokumentatsioon ütleb selgesõnaliselt, et direktiiv pole seal saadaval, nii et selle ümber ehitatud skript ei läbi seda piiri (vt Squidi tcp_outgoing_address viidet). Valideerige toote enda parseriga enne, kui midagi uuesti laaditakse: squid -k parse teatab vigadest ja väljub jooksvat protsessi puutumata.

Nummerdage iga tunnel ja hüljake aegunud vahetused

Taasühendamine on üleandmine ja üleandmine vajab järjekorda. Märgistage iga vaadeldud ühendus loenduri või ajatempliga, mis suureneb iga õnnestunud loomise järel, ja kandke see märgis kandidaatkonfiguratsiooni sees. Kui kandidaadi märgis on praegusest vanem, hüljake kandidaat selle rakendamise asemel, sest eelmisele tunnelile kirjutatud aeglane uuendus kirjutaks muidu üle praeguse seaded. Ühendage sündmuste pursked nii, et vilkuv link annab ühe ülemineku viieteistkümne asemel.

Järjestage töö neljaks sammuks: muutke vana väljumisolek kehtetuks, oodake, kuni ühenduse omanik teatab lõpetamisest, ehitage ainult hallatav fragment, seejärel valideerige ja aktiveerige teenusehalduri kaudu. Kogu faili kahest aadressiväärtusest uuesti genereerimine on viis, kuidas kuulaja piirangud, autentimine ja sihtkoha poliitika vaikselt kaovad. Austage ka tahtlikku peatamist. Abiline, mis jätkab tunnelile helistamist, mille kasutaja välja lülitas, on viga, mitte vastupidavus.

Avatud soklid ei järgi uut aadressi

Edastaja ümberseadistamine ei ütle midagi juba loodud ühenduste kohta. Kas need tühjenevad või surevad, sõltub tootest, seega jälgige käitumist selle asemel, et seda eeldada.

Enne vahetust avatud sokli kaudu teenindatav päring väljub endiselt vana teed, isegi kui uus konfiguratsioon on õige. Kui see loeb, otsustage selgelt: lubage lühike tühjenemisaken ja lõpetage uue töö vastuvõtmine, või sulgege vanad soklid ja leppige vigadega. Seejärel testige värske ühendusega ja hoidke seda tulemust tühjenemiskontrollist eraldi. Ka lähtekohaga sidumine ei ole turvapiir. Kui liiklus ei tohi kunagi tavapärast marsruuti puudutada, rakendage seda märkide ja tulemüürireeglitega, sealhulgas DNS ja IPv6, et ebaõnnestunud uuestilaadimine jätaks puhverserveri selgelt välja lülitatuks, mitte avatuks.

Tõestage uus väljund värske päringuga

Tähtis on päring, mis avati pärast aktiveerimist, mitte ping ja mitte juba vahemällu salvestatud leht. Paluge puhverserveril anda tõeline URL ja lugege väljundiaadressi, millest kaugem ots teatab, seejärel võrrelge seda kliendi enda vaatega tunnelile, kui teenusepakkuja seda näitab.

Hoidke parsimine, uuestilaadimine ja päring eraldi käskudena, et tõrge osutaks ühele sammule. Kaks esimest ei muuda midagi, kui need ebaõnnestuvad, ja just seetõttu jooksevad need enne taaskäivitust.

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

Kui uuestilaadimine ebaõnnestub, peatage teenus ja parandage fragment; aegunud väljundiga teenindav puhverserver on hullem kui lühike katkestus. Kui uuestilaadimine õnnestub, aga värske päring väljub ikka kuskil ootamatult, pöörduge tagasi marsruutimiskontrolli juurde, mitte ärge muutke aadresse uuesti. Märkige üles tunnelipõlvkond, mille vastu valideerisite, et järgmisel taasühendamisel oleks midagi konkreetset võrrelda.