Ali proxy po ponovni povezavi VPN ostaja na starem naslovu tunela?

Ponovni zagon odjemalca VPN dokaže le, da se je tunel vrnil. O proxyju, ki mu je bilo naročeno, da gre ven skozenj, ne pove ničesar. Squid, tinyproxy in večina drugih posredovalnikov drži lokalni izvorni naslov, ki so ga določili ob zagonu, dokler jih nekaj ne prisili v ponovno nalaganje. Ko ponovna povezava dodeli nov naslov tunela, posredovalnik bodisi odpove pri vsaki odhodni povezavi bodisi začne izhajati po vaši običajni poti.

Druga napaka je nevarna: tunel deluje, strani se nalagajo, napačen je le izhodni naslov.

Začnite s poslušalcem, ne s tunelom

V igri so trije naslovi, ponovna povezava pa premakne le nekatere. Poslušalec je mesto, kamor kaže vaš brskalnik, običajno 127.0.0.1 ali naslov LAN, in ne zanima ga, da se je tunel spremenil. Odhodni lokalni vir je tisto, kar posredovalnik prosi jedro, naj uporabi pri izbiri naslednjega skoka, in je vezan na napravo tunela. Javni izhod je tisto, kar zabeleži spletni strežnik, in je lahko preveden naslov nekaj skokov stran.

Iskanje javnega IP odgovori le na zadnje vprašanje. Ne more vam povedati, na kateri lokalni naslov naj se posredovalnik veže, ker lahko en javni izhod skriva več notranjih virov. Naslov preberite pri tistem, ki ima povezavo: v izhodu stanja odjemalca, v samem vmesniku ali v imenskem prostoru, kjer živi tunel. Če zgrabite prvi vmesnik, katerega ime je podobno tunelu, dobite napačen odgovor takoj, ko obstaja drug profil.

Postavitve zabojnikov in imenskih prostorov tiho zlomijo to predpostavko. Posredovalnik v enem omrežnem imenskem prostoru se ne more vezati na tunel, ki obstaja v drugem, in nobeno urejanje konfiguracije tega ne popravi.

Štiri preveritve, preden karkoli uredite

Pojdite skoznje po vrsti. Prva preveritev, ki spodleti, je mesto, kjer se ustavite, ker naslednje predpostavljajo, da prejšnje veljajo.

1. Potrdite, da je uporabljeni tunel profil, okoli katerega je bil zgrajen proxy, in ne drug profil, ki se je povezal sam.
2. Izpišite naslov, ki je zdaj na tej napravi, in ga primerjajte z naslovom v tekoči konfiguraciji.
3. Vprašajte posredovalnika, kateri vir je določil, namesto kaj trdi datoteka na disku.
4. Potrdite, da promet iz posredovalnika resnično podlega politiki usmerjanja in požarnega zidu, ki jo pričakujete.

Naslov naprave je preprost: ip -4 addr show dev tun0 izpiše trenutnega, ip -4 route get 1.1.1.1 pa pokaže, kateri vmesnik bi jedro izbralo za ta cilj. Posredovalnik, ki veže točen naslov, glasno odpove, ko naslov izgine. Posredovalnik, ki veže napravo ali se vrne na privzeti vir, deluje naprej in pušča, in to je tihi izid.

Uskladite dokumentacijo z izdajo, ki jo izvajate, ne s prvim rezultatom iskanja. Direktiva izhodnega naslova Squid je dokumentirana za v7 in starejše, dokumentacija v8 pa jasno pravi, da direktiva tam ni na voljo, zato scenarij, zgrajen okoli nje, te meje ne preživi (glejte referenco Squid tcp_outgoing_address). Preverite z lastnim razčlenjevalnikom izdelka, preden se karkoli znova naloži: squid -k parse sporoči napake in se konča, ne da bi se dotaknil tekočega procesa.

Oštevilčite vsak tunel in zavrzite zastarele zamenjave

Ponovna povezava je predaja, predaje pa potrebujejo vrstni red. Vsako opaženo povezavo označite s števcem ali časovnim žigom, ki se poveča ob vsaki uspešni vzpostavitvi, nato to oznako nosite v kandidatni konfiguraciji. Ko je oznaka na kandidatu starejša od trenutne, kandidata zavrzite, namesto da ga uporabite, ker bi počasna posodobitev, napisana za prejšnji tunel, sicer prepisala nastavitve trenutnega. Združite sunke dogodkov, da utripajoča povezava ustvari en prehod namesto petnajstih.

Razporedite delo v štiri poteze: razveljavite staro stanje izhoda, počakajte, da lastnik povezave sporoči dokončanje, zgradite le upravljani fragment, nato preverite in aktivirajte prek upravitelja storitev. Ponovno ustvarjanje celotne datoteke iz dveh vrednosti naslova je način, kako tiho izginejo omejitve poslušalca, overjanje in politika cilja. Spoštujte tudi namerno ustavitev. Pomočnik, ki še naprej kliče tunel, ki ga je uporabnik izklopil, je napaka, ne odpornost.

Odprti vtiči ne bodo sledili novemu naslovu

Ponovna konfiguracija posredovalnika ne pove ničesar o že vzpostavljenih povezavah. Ali se izpraznijo ali umrejo, je odvisno od izdelka, zato opazujte vedenje, namesto da bi ga predpostavljali.

Zahteva, postrežena prek vtiča, odprtega pred zamenjavo, še vedno odide po stari poti, tudi ko je nova konfiguracija pravilna. Če je to pomembno, odločite izrecno: dovolite kratko okno praznjenja in prenehajte sprejemati novo delo, ali zaprite stare vtiče in sprejmite napake. Nato preskusite s svežo povezavo in ta rezultat držite ločeno od preveritve praznjenja. Vezava na vir tudi ni varnostna meja. Ko se promet ne sme nikoli dotakniti običajne poti, to uveljavite z oznakami in pravili požarnega zidu, vključno z DNS in IPv6, da neuspešno nalaganje pusti proxy izrecno ugasnjen, ne odprt.

Dokažite novi izhod s svežo zahtevo

Pomembna je zahteva, odprta po aktivaciji, ne ping in ne že predpomnjena stran. Prosíte proxy za pravi URL in preberite izhodni naslov, ki ga sporoči oddaljeni konec, nato ga primerjajte z odjemalčevim lastnim pogledom na tunel, ko ponudnik enega pokaže.

Držite razčlenjevanje, ponovno nalaganje in zahtevo kot ločene ukaze, da napaka pokaže na en korak. Prva dva ne spremenita ničesar, ko spodletita, in prav zato tečeta pred ponovnim zagonom.

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

Če ponovno nalaganje spodleti, ustavite storitev in popravite fragment; proxy, ki streže z zastarelim izhodom, je slabši od kratke prekinitve. Če nalaganje uspe, a sveža zahteva še vedno odide nekam nepričakovano, se vrnite k preveritvi usmerjanja, namesto da bi znova urejali naslove. Zapišite generacijo tunela, glede na katero ste preverjali, da bo imela naslednja ponovna povezava kaj konkretnega za primerjavo.