Ĉu la prokura servilo ankoraŭ estas ĉe la malnova tunela adreso post rekonekto de VPN?

Restartigi la VPN-klienton pruvas nur, ke la tunelo revenis. Ĝi diras nenion pri la prokura servilo, al kiu estis ordonite eliri tra ĝi. Squid, tinyproxy kaj plej multaj aliaj plusendiloj tenas la lokan fontadreson, kiun ili solvis ĉe starto, ĝis io devigas ilin reŝargi. Kiam rekonekto donas novan tunelan adreson, la plusendilo aŭ fiaskas ĉe ĉiu elira konekto, aŭ komencas eliri tra via ordinara vojo.

Tiu dua fiasko estas la danĝera: la tunelo funkcias, paĝoj ŝargas, kaj nur la elira adreso estas malĝusta.

Komencu ĉe la aŭskultanto, ne ĉe la tunelo

Tri adresoj ludas, kaj rekonekto movas nur iujn el ili. La aŭskultanto estas la loko, kiun montras via retumilo, kutime 127.0.0.1 aŭ LAN-adreso, kaj ĝi ne zorgas, ke la tunelo ŝanĝiĝis. La elira loka fonto estas tio, kion la plusendilo petas la kernon uzi, kiam ĝi vokas la sekvan hopon, kaj ĝi estas ligita al la tunela aparato. La publika eliro estas tio, kion registras retservilo, kaj ĝi povas esti tradukita adreso kelkajn hopojn for.

Serĉo de publika IP respondas nur la lastan demandon. Ĝi ne povas diri al vi, al kiu loka adreso plusendilo devus ligiĝi, ĉar unu publika eliro povas kaŝi plurajn internajn fontojn. Legu la adreson ĉe tiu, kiu posedas la konekton: la statusa eligo de la kliento, la interfaco mem, aŭ la nomspaco, kie loĝas la tunelo. Kapti la unuan interfacon, kies nomo aspektas kiel tunelo, donas la malĝustan respondon tuj kiam ekzistas dua profilo.

Konteneraj kaj nomspacaj aranĝoj kviete rompas tiun supozon. Plusendilo en unu reta nomspaco ne povas ligiĝi al tunelo, kiu ekzistas en alia, kaj neniu kvanto da redaktado de agordoj riparas tion.

Kvar kontroloj antaŭ ol vi redaktos ion ajn

Trairu ilin en ordo. La unua kontrolo, kiu fiaskas, estas kie vi haltas, ĉar la postaj supozas, ke la antaŭaj validas.

1. Konfirmu, ke la uzata tunelo estas la profilo, ĉirkaŭ kiu la prokura servilo estis konstruita, ne dua profilo, kiu konektiĝis mem.
2. Presu la adreson, kiu nun estas sur tiu aparato, kaj komparu ĝin kun la adreso en la kuranta agordo.
3. Demandu la plusendilon, kiun fonton ĝi solvis, anstataŭ kion asertas la dosiero sur la disko.
4. Konfirmu, ke trafiko de la plusendilo efektive subiĝas al la enkursiga kaj fajroŝirma politiko, kiun vi atendas.

La aparata adreso estas facila: ip -4 addr show dev tun0 presas la nunan, kaj ip -4 route get 1.1.1.1 montras, kiun interfacon la kerno elektus por tiu celo. Plusendilo, kiu ligas precizan adreson, fiaskas laŭte, kiam la adreso malaperas. Plusendilo, kiu ligas aparaton aŭ falas reen al la apriora fonto, daŭre funkcias kaj likas, kaj tio estas la kvieta rezulto.

Agordigu la dokumentaron al la eldono, kiun vi rulas, ne al la plej supra serĉrezulto. La direktivo de Squid pri elira adreso estas dokumentita por v7 kaj pli frue, kaj la dokumentaro de v8 diras klare, ke la direktivo tie ne haveblas, do skripto konstruita ĉirkaŭ ĝi ne postvivas tiun limon (vidu la Squid-referencon tcp_outgoing_address). Validigu per la propra analizilo de la produkto antaŭ ol io reŝargiĝos: squid -k parse raportas erarojn kaj finiĝas sen tuŝi la kurantan procezon.

Numeru ĉiun tunelon kaj forĵetu kadukiĝintajn anstataŭigojn

Rekonekto estas transdono, kaj transdonoj bezonas ordon. Marku ĉiun observatan konekton per nombrilo aŭ tempstampo, kiu kreskas ĉe ĉiu sukcesa establo, kaj poste portu tiun markon ene de la kandidata agordo. Kiam la marko ĉe kandidato estas pli malnova ol la nuna, forĵetu la kandidaton anstataŭ apliki ĝin, ĉar malrapida ĝisdatigo skribita por la antaŭa tunelo alie anstataŭigus la agordojn de la nuna. Kunfandu eksplodojn de eventoj tiel, ke flagranta ligo produktas unu transiron anstataŭ dek kvin.

Ordigu la laboron en kvar movojn: nuligu la malnovan eliran staton, atendu ke la posedanto de la konekto raportu plenumon, konstruu nur la administritan fragmenton, poste validigu kaj aktivigu tra la servoadministrilo. Regeneri la tutan dosieron el du adresaj valoroj estas la maniero, kiel limigoj de aŭskultanto, aŭtentigo kaj cella politiko kviete malaperas. Respektu ankaŭ intencan halton. Helpanto, kiu daŭre vokas tunelon, kiun la uzanto malŝaltis, estas cimo, ne rezistemo.

Malfermaj ingoj ne sekvos la novan adreson

Rekonfiguri la plusendilon diras nenion pri konektoj jam establitaj. Ĉu ili senakviĝos aŭ mortos dependas de la produkto, do observu la konduton anstataŭ supozi ĝin.

Peto servata tra ingo malfermita antaŭ la anstataŭigo ankoraŭ eliras la malnovan vojon, eĉ kiam la nova agordo estas ĝusta. Se tio gravas, decidu eksplicite: permesu mallongan senakvan fenestron kaj ĉesu akcepti novan laboron, aŭ fermu la malnovajn ingojn kaj akceptu la erarojn. Poste testu per freŝa konekto kaj tenu tiun rezulton aparte de la senakva kontrolo. Ankaŭ fonta ligado ne estas sekureca limo. Kiam trafiko neniam rajtas tuŝi la ordinaran vojon, devigu tion per markoj kaj fajroŝirmaj reguloj, DNS kaj IPv6 inkluzive, por ke malsukcesa reŝargo lasu la prokuran servilon eksplicite malŝaltita anstataŭ malfermita.

Pruvu la novan eliron per freŝa peto

Grava estas peto malfermita post aktivigo, ne ping kaj ne jam kaŝmemorigita paĝo. Petu la prokuran servilon pri reala URL kaj legu la eliran adreson, kiun raportas la malproksima flanko, poste komparu ĝin kun la propra vidpunkto de la kliento pri la tunelo, kiam la provizanto montras unu.

Tenu la analizon, la reŝargon kaj la peton kiel apartajn komandojn, por ke fiasko montru unu solan paŝon. La unuaj du ŝanĝas nenion, kiam ili fiaskas, kaj ĝuste tial ili rulas antaŭ la restartigo.

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

Se la reŝargo fiaskas, haltigu la servon kaj riparu la fragmenton; prokura servilo servanta kun kadukiĝinta eliro estas pli malbona ol mallonga interrompo. Se la reŝargo sukcesas sed la freŝa peto ankoraŭ eliras ie neatendite, revenu al la enkursiga kontrolo anstataŭ denove redakti adresojn. Notu la tunelan generacion, kontraŭ kiu vi validigis, por ke la sekva rekonekto havu ion konkretan por kompari.