Er proxyið enn á gamla túnel-slóðinni eftir endurtengingu VPN?

Endurræsing VPN-biðlarans sannar aðeins að túnelinn er kominn aftur. Hún segir ekkert um proxyið sem var sagt að fara út í gegnum hann. Squid, tinyproxy og flestir aðrir framsendingarþjónar halda staðbundnu upprunaslóðinni sem þeir leystu við ræsingu þar til eitthvað þvingar þá til að hlaða aftur. Þegar endurtenging úthlutar nýrri túnel-slóð, mistekst framsendingarþjónnum á hverri útleið eða hann fer að fara út um venjulegu leiðina þína.

Seinna mistakið er hættulega: túnelinn er uppi, síður hlaðast og aðeins útgangssljóðin er röng.

Byrjaðu á hlustaranum, ekki túnelnum

Þrjár slóðir eru í spilinu og endurtenging færir aðeins sumar þeirra. Hlustarinn er þar sem vafrinn þinn bendir, venjulega 127.0.0.1 eða LAN-slóð, og honum er sama þótt túnelinn hafi breyst. Útleiðarstaðbundna uppruninn er það sem framsendingarþjónninn biður kjarnann um að nota þegar hann hringir næsta hopp, og hann er bundinn við túnel-tækið. Opinberi útgangurinn er það sem vefþjónn skráir, og gæti verið þýdd slóð nokkrum hoppum í burtu.

Leit að opinberri IP svarar aðeins síðustu spurningunni. Hún getur ekki sagt þér við hvaða staðbundnu slóð framsendingarþjónn ætti að binda sig, því einn opinber útgangur getur falið nokkrar innri uppsprettur. Lestu slóðina hjá þeim sem á tenginguna: stöðuúttaki biðlarans, viðmótinu sjálfu eða nafnrýminu þar sem túnelinn lifir. Að grípa fyrsta viðmótið sem heitir eins og túnel gefur ranga svörun um leið og önnur prófíla er til.

Uppsetning gáma og nafnrýma brýtur þessa forsendu hljóðlega. Framsendingarþjónn í einu netnafnrými getur ekki bundist túnel sem er í öðru, og engin uppsetningarbreyting læknar það.

Fjórar athuganir áður en þú breytir nokkru

Farðu í gegnum þær í röð. Fyrsta athugunin sem mistekst er þar sem þú stansar, því næstu gera ráð fyrir að fyrri gildi.

1. Staðfestu að túnelinn í notkun sé prófílan sem proxyið var byggt í kringum, ekki önnur prófíla sem tengdist af sjálfu sér.
2. Prentaðu slóðina sem er nú á því tæki og berðu hana saman við slóðina í stillingunni sem er í gangi.
3. Spyrðu framsendingarþjóninn hvaða uppsprettu hann leysti, frekar en hvað skráin á diskinum fullyrðir.
4. Staðfestu að umferð frá framsendingarþjóninum sé í raun undir þeirri leiðar- og eldveggsstefnu sem þú býst við.

Tækjaslóðin er auðveld: ip -4 addr show dev tun0 prentar þá núverandi og ip -4 route get 1.1.1.1 sýnir hvaða viðmót kjarninn myndi velja fyrir þann áfangastað. Framsendingarþjónn sem bindur nákvæma slóð mistekst hávært þegar slóðin hverfur. Framsendingarþjónn sem bindur tæki, eða fellur aftur á sjálfgefna uppsprettu, heldur áfram að virka og lekur, og það er hljóðláta útkoman.

Passaðu skjölunina við útgáfuna sem þú keyrir, ekki við efstu leitar niðurstöðuna. Tilskipun Squid um útleiðarsljóð er skjöluð fyrir v7 og eldri, og skjöl v8 segja skýrt að tilskipunin sé ekki fáanleg þar, svo skriftu sem byggð er í kringum hana lifir ekki þessi mörk (sjá Squid tcp_outgoing_address tilvísun). Staðfestu með þáttaranum sem varan sjálf hefur áður en eitthvað er hlaðið aftur: squid -k parse tilkynnir villur og hættir án þess að snerta ferlið sem er í gangi.

Númeraðu hvern túnel og hendaðu úr sér úrelsum skiptum

Endurtenging er afhending, og afhendingar þurfa röð. Merktu hverja athuguðu tengingu með teljara eða tímastimpli sem hækkar við hverja árangursríka stofnun, og berðu það merki svo inn í frambjóðandastillingunni. Þegar merkið á frambjóðanda er eldra en það núverandi, hendaðu frambjóðandanum í stað þess að beita honum, því hæg uppfærsla skrifuð fyrir fyrri túnelinn myndi annars skrifa yfir stillingar þess núverandi. Sameinaðu sprengjur atburða svo flöktandi tenging framleiði eina umskipti í stað fimmtán.

Raðaðu vinnunni í fjórar hreyfingar: ógiltu gamla útgangsstöðu, bíddu eftir að eigandi tengingarinnar tilkynni lokningu, byggðu aðeins stýrða brotið og staðfestu og virkjaðu svo í gegnum þjónustustjórann. Að endurnýja alla skrána út frá tveimur slóðargildum er leiðin sem hlustaratakmarkanir, auðkenning og áfangastaðastefna hverfa hljóðlega. Virtu líka viljandi stöðvun. Hjálpari sem heldur áfram að hringja í túnel sem notandinn slökkti á er galli, ekki seigla.

Opnar sambönd munu ekki fylgja nýju slóðinni

Endurstilling framsendingarþjónsins segir ekkert um tengingar sem þegar eru stofnaðar. Hvort þær tæmast eða deyja fer eftir vörunni, svo fylgstu með hegðuninni í stað þess að gera ráð fyrir henni.

Beiðni sem þjónað er um samband sem opnað var fyrir skiptin fer enn út um gömlu leiðina, jafnvel þótt nýja stillingin sé rétt. Ef það skiptir máli skaltu ákveða skýrt: leyfðu stuttan tæmingarglugga og hættu að taka við nýrri vinnu, eða lokaðu gömlu samböndunum og samþykktu villurnar. Prófaðu svo með nýrri tengingu og haltu þeirri niðurstöðu aðskildri frá tæmingarathuguninni. Upprunabinding er heldur ekki öryggismörk. Þegar umferð má aldrei snerta venjulegu leiðina skaltu þvinga það með merkjum og eldveggsreglum, þar á meðal DNS og IPv6, svo misheppnuð endurhleðsla skilji proxyið skýrt niðri í stað þess að vera opið.

Sannaðu nýja útganginn með nýrri beiðni

Það sem skiptir máli er beiðni sem opnuð er eftir virkjun, ekki ping og ekki síða sem þegar var í skyndiminni. Biddu proxyið um raunverulega slóð og lestu útgangssljóðina sem fjarlægi endinn tilkynnir, og berðu hana svo saman við sýn biðlarans á túnelinn þegar veitandinn sýnir eina.

Haltu þáttuninni, endurhleðslunni og beiðninni sem aðskildum skipunum svo mistök bendi á eitt skref. Fyrstu tvö breyta engu þegar þau mistekst, og einmitt þess vegna keyra þau fyrir endurræsinguna.

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

Ef endurhleðslan mistekst skaltu stöðva þjónustuna og laga brotið; proxy sem þjónar með úreltum útgangi er verra en stutt truflun. Ef endurhleðslan heppnast en nýja beiðnin fer samt út einhvers staðar óvænt, farðu aftur í leiðarathugunina í stað þess að breyta slóðum aftur. Skráðu túnel-kynslóðina sem þú staðfestir gegn, svo næsta endurtenging hafi eitthvað áþreifanlegt til að bera saman.