Staat de proxy na een VPN-herverbinding nog op het oude tunneladres?

Een herverbinding kan je forwarder gebonden laten aan een adres dat de tunnel niet meer bezit. Vier geordende controles, een genummerde overdracht en een echt testverzoek.

De VPN-client opnieuw starten bewijst alleen dat de tunnel terug is. Het zegt niets over de proxy die werd opgedragen erdoor naar buiten te gaan. Squid, tinyproxy en de meeste andere forwarders houden het lokale bronadres vast dat ze bij het starten hebben bepaald, tot iets hen dwingt opnieuw te laden. Wanneer een herverbinding een nieuw tunneladres uitdeelt, faalt de forwarder bij elke uitgaande verbinding, of hij begint via je gewone route naar buiten te gaan.

Die tweede fout is de gevaarlijke: de tunnel staat, pagina's laden, en alleen het uitgangsadres is verkeerd.

Begin bij de listener, niet bij de tunnel

Er spelen drie adressen, en een herverbinding verplaatst er slechts enkele. De listener is waar je browser naartoe wijst, meestal 127.0.0.1 of een LAN-adres, en het kan hem niet schelen dat de tunnel is veranderd. De uitgaande lokale bron is wat de forwarder de kernel vraagt te gebruiken bij het kiezen van de volgende hop, en die is aan het tunnelapparaat gebonden. De publieke uitgang is wat een webserver logt, en dat kan een vertaald adres zijn, een paar hops verderop.

Een zoekopdracht naar het publieke IP beantwoordt alleen de laatste vraag. Hij kan je niet vertellen aan welk lokaal adres een forwarder zich moet binden, omdat één publieke uitgang meerdere interne bronnen kan verbergen. Lees het adres bij wie de verbinding bezit: de statusuitvoer van de client, de interface zelf, of de naamruimte waarin de tunnel leeft. De eerste interface pakken waarvan de naam op een tunnel lijkt, geeft het verkeerde antwoord zodra er een tweede profiel bestaat.

Container- en naamruimte-indelingen breken die aanname stil. Een forwarder in de ene netwerknaamruimte kan zich niet binden aan een tunnel die in een andere bestaat, en geen enkele configuratiebewerking herstelt dat.

Vier controles voordat je iets bewerkt

Werk ze in volgorde af. De eerste controle die faalt is waar je stopt, omdat de latere veronderstellen dat de eerdere gelden.

  1. Bevestig dat de gebruikte tunnel het profiel is waarom de proxy is gebouwd, niet een tweede profiel dat zichzelf verbond.
  2. Druk het adres af dat nu op dat apparaat staat en vergelijk het met het adres in de draaiende configuratie.
  3. Vraag de forwarder welke bron hij heeft bepaald, in plaats van wat het bestand op schijf beweert.
  4. Bevestig dat het verkeer van de forwarder echt onder het routerings- en firewallbeleid valt dat je verwacht.

Het apparaatadres is eenvoudig: ip -4 addr show dev tun0 drukt het huidige af, en ip -4 route get 1.1.1.1 toont welke interface de kernel voor die bestemming zou kiezen. Een forwarder die een exact adres bindt, faalt luid wanneer het adres verdwijnt. Een forwarder die een apparaat bindt, of terugvalt op de standaardbron, blijft werken en lekt, en dat is de stille uitkomst.

Stem de documentatie af op de release die je draait, niet op het eerste zoekresultaat. De richtlijn voor het uitgaande adres van Squid is gedocumenteerd voor v7 en eerder, en de v8-documentatie zegt duidelijk dat de richtlijn daar niet beschikbaar is, dus een script eromheen overleeft die grens niet (zie de Squid tcp_outgoing_address-referentie). Valideer met de eigen parser van het product voordat er iets opnieuw wordt geladen: squid -k parse meldt fouten en stopt zonder het draaiende proces aan te raken.

Nummer elke tunnel en gooi verouderde wissels weg

Een herverbinding is een overdracht, en overdrachten hebben een volgorde nodig. Markeer elke waargenomen verbinding met een teller of tijdstempel die bij elke geslaagde totstandkoming stijgt, en draag die markering vervolgens in de kandidaatconfiguratie. Als de markering op een kandidaat ouder is dan de huidige, gooi de kandidaat dan weg in plaats van hem toe te passen, want een langzame update die voor de vorige tunnel is geschreven, zou anders de instellingen van de huidige overschrijven. Voeg reeksen gebeurtenissen samen zodat een flikkerende verbinding één overgang oplevert in plaats van vijftien.

Zet het werk in vier stappen: maak de oude uitgangstoestand ongeldig, wacht tot de eigenaar van de verbinding voltooiing meldt, bouw alleen het beheerde fragment, en valideer en activeer daarna via de servicemanager. Het hele bestand opnieuw genereren uit twee adreswaarden is hoe listenerbeperkingen, authenticatie en bestemmingsbeleid stil verdwijnen. Respecteer ook een bewuste stop. Een helper die blijft bellen naar een tunnel die de gebruiker heeft uitgeschakeld, is een fout, geen veerkracht.

Open sockets volgen het nieuwe adres niet

Het opnieuw configureren van de forwarder zegt niets over verbindingen die al tot stand zijn gebracht. Of ze leeglopen of sterven hangt van het product af, dus observeer het gedrag in plaats van het aan te nemen.

Een verzoek dat via een socket wordt bediend die vóór de wissel is geopend, gaat nog steeds via het oude pad naar buiten, zelfs wanneer de nieuwe configuratie correct is. Als dat ertoe doet, beslis dan expliciet: sta een kort leegloopvenster toe en stop met het aannemen van nieuw werk, of beëindig de oude sockets en accepteer de fouten. Test daarna met een nieuwe verbinding en houd dat resultaat gescheiden van de leegloopcontrole. Bronbinding is ook geen beveiligingsgrens. Wanneer verkeer nooit de gewone route mag raken, dwing dat dan af met markeringen en firewallregels, DNS en IPv6 inbegrepen, zodat een mislukte herlaad de proxy expliciet uit laat staan in plaats van open.

Bewijs de nieuwe uitgang met een nieuw verzoek

Wat telt is een verzoek dat na de activering wordt geopend, niet een ping en niet een pagina die al in de cache zat. Vraag de proxy om een echte URL en lees het uitgangsadres dat de andere kant meldt, en vergelijk het dan met de eigen kijk van de client op de tunnel wanneer de provider er een toont.

Houd het parsen, het herladen en het verzoek als aparte opdrachten, zodat een fout op één stap wijst. De eerste twee veranderen niets wanneer ze falen, en daarom draaien ze vóór de herstart.

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

Als het herladen mislukt, stop de dienst en repareer het fragment; een proxy die met een verouderde uitgang dient, is erger dan een korte onderbreking. Als het herladen lukt maar het nieuwe verzoek nog steeds ergens onverwacht naar buiten gaat, ga dan terug naar de routeringscontrole in plaats van opnieuw adressen te bewerken. Noteer de tunnelgeneratie waartegen je hebt gevalideerd, zodat de volgende herverbinding iets concreets heeft om mee te vergelijken.

Gerelateerde artikelen