Står proxyen framleis på den gamle tunneladressa etter ein VPN-gjenoppkopling?

Ei gjenoppkopling kan la videresendaren din vera bunden til ei adresse som tunnelen ikkje lenger eig. Fire ordna kontrollar, ei nummerert overlevering og ein ekte testførespurnad.

Å starte VPN-klienten på nytt provar berre at tunnelen er tilbake. Det seier ingenting om proxyen som fekk beskjed om å gå ut gjennom han. Squid, tinyproxy og dei fleste andre videresendarar held på den lokale kjeldeadressa dei fann ved oppstart, heilt til noko tvingar dei til å laste på nytt. Når ei gjenoppkopling deler ut ei ny tunneladresse, feilar videresendaren på kvar utgåande tilkopling, eller han byrjar å gå ut gjennom den vanlege ruta di.

Den andre feilen er den farlege: tunnelen er oppe, sider lastar, og berre utgangsadressa er feil.

Start med lyttaren, ikkje tunnelen

Tre adresser er i spel, og ei gjenoppkopling flyttar berre nokre av dei. Lyttaren er der nettlesaren din peikar, vanlegvis 127.0.0.1 eller ei LAN-adresse, og han bryr seg ikkje om at tunnelen er endra. Den utgåande lokale kjelda er det videresendaren ber kjernen bruke når han ringjer neste hopp, og ho er bunden til tunneleininga. Den offentlege utgangen er det ein webserver loggar, og han kan vera ei omsett adresse fleire hopp unna.

Eit oppslag på offentleg IP svarar berre på det siste spørsmålet. Det kan ikkje fortelje deg kva lokal adresse ein videresendar skal binde til, fordi éin offentleg utgang kan skjule fleire interne kjelder. Les adressa hos den som eig tilkoplinga: statusutdata frå klienten, sjølve grensesnittet eller namnerommet der tunnelen bur. Å gripe det første grensesnittet som ser ut som ein tunnel, gjev feil svar så snart ein annan profil finst.

Container- og namneromsoppsett bryt denne føresetnaden stille. Ein videresendar i eitt nettverksnamnerom kan ikkje binde ein tunnel som finst i eit anna, og inga mengd konfigurasjonsredigering reparerer det.

Fire kontrollar før du redigerer noko

Gå gjennom dei i rekkjefølgje. Den første kontrollen som feilar, er der du stoppar, fordi dei seinare føreset at dei tidlegare held.

  1. Stadfest at tunnelen som vert brukt, er profilen proxyen vart bygd rundt, ikkje ein annan profil som kopla til av seg sjølv.
  2. Skriv ut adressa som for tida står på den eininga, og samanlikn ho med adressa i konfigurasjonen som køyrer.
  3. Spør videresendaren kva kjelde han fann, i staden for kva fila på disken påstår.
  4. Stadfest at trafikken frå videresendaren faktisk er underlagd den ruting- og brannmurpolitikken du ventar.

Einingsadressa er enkel: ip -4 addr show dev tun0 skriv ut den gjeldande, og ip -4 route get 1.1.1.1 viser kva grensesnitt kjernen ville velje for destinasjonen. Ein videresendar som bind ei nøyaktig adresse, feilar høgt når adressa forsvinn. Ein videresendar som bind ei eining, eller fell tilbake til standardkjelda, held fram med å verke og lekk, og det er det stille resultatet.

Tilpass dokumentasjonen til utgåva du køyrer, ikkje til det øvste søkjeresultatet. Squid sin direktiv for utgåande adresse er dokumentert for v7 og tidlegare, og v8-dokumentasjonen seier rett ut at direktivet ikkje er tilgjengeleg der, så eit skript bygd rundt det overlever ikkje den grensa (sjå Squid tcp_outgoing_address-referansen). Valider med produktet sin eigen parser før noko vert lasta på nytt: squid -k parse rapporterer feil og avsluttar utan å røre den køyrande prosessen.

Nummerer kvar tunnel og kast utdaterte bytte

Ei gjenoppkopling er ei overlevering, og overleveringar treng ei rekkjefølgje. Merk kvar observerte tilkopling med ein teljar eller eit tidsstempel som aukar ved kvar vellykka etablering, og ber deretter merket med inn i kandidatkonfigurasjonen. Når merket på ein kandidat er eldre enn det gjeldande, kast kandidaten i staden for å bruke han, fordi ei sein oppdatering skriven for den førre tunnelen elles vil skrive over innstillingane for den gjeldande. Slå saman byer av hendingar slik at ei flagrande lenkje gjev éin overgang i staden for femten.

Set arbeidet i fire trekk: gjere den gamle utgangstilstanden ugyldig, vent på at eigaren av tilkoplinga rapporterer fullføring, bygg berre fragmentet som vert styrt, og valider og aktiver deretter gjennom tenestebehandsamaren. Å generere heile fila på nytt frå to adresseverdiar er måten lyttarbegrensingar, autentisering og destinasjonspolitikk stille forsvinn på. Respekter òg ein medviten stopp. Ein hjelpar som held fram med å ringje ein tunnel brukaren har slått av, er ein feil, ikkje robustheit.

Opne sockets følgjer ikkje den nye adressa

Å konfigurere videresendaren på nytt seier ingenting om tilkoplingar som alt er etablerte. Om dei tømmest eller døyr, avheng av produktet, så observer åtferda i staden for å anta ho.

Ein førespurnad som vert betent over ein socket som vart opna før bytet, går framleis ut den gamle vegen, sjølv når den nye konfigurasjonen er riktig. Om det tyder noko, må du avgjere eksplisitt: tillat eit kort tømmingsvindauge og slutt å ta imot nytt arbeid, eller avslutt dei gamle socketane og godta feila. Test deretter med ei frisk tilkopling og hald resultatet skilt frå tømmingskontrollen. Kjeldebinding er heller ikkje ei sikkerheitsgrense. Når trafikk aldri skal røre den vanlege ruta, handhev det med merke og brannmurreglar, DNS og IPv6 medrekna, slik at ein mislukka omlasting lèt proxyen uttrykkeleg nede i staden for open.

Prov den nye utgangen med ein frisk førespurnad

Det som tyder noko, er ein førespurnad som vert opna etter aktivering, ikkje ein ping og ikkje ei side som alt var i bufferen. Be proxyen om ein ekte URL og les utgangsadressa den andre enden rapporterer, og samanlikn ho deretter med klienten sitt eige syn på tunnelen når leverandøren viser ein.

Hald parsings, omlastinga og førespurnaden som separate kommandoar, slik at ein feil peikar på eitt trinn. Dei to første endrar ingenting når dei feilar, og det er nettopp difor dei køyrer før omstarten.

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

Om omlastinga feilar, stopp tenesta og reparer fragmentet; ein proxy som tener med utdatert utgang, er verre enn eit kort avbrot. Om omlastinga lukkast, men den friske førespurnaden framleis går ut ein stad uventa, gå tilbake til rutingkontrollen i staden for å redigere adresser igjen. Noter tunnelgenerasjonen du validerte mot, slik at den neste gjenoppkoplinga har noko konkret å samanlikne med.

Relaterte artiklar