Waarom je split-tunnelregel niet meer overeenkwam met een dienst

Split tunneling mislukt meestal op een van twee manieren. Of verkeer dat in de tunnel hoort gaat eromheen, of verkeer dat buiten moet blijven wordt naar binnen getrokken. De fout met de verouderde regel is de eerste soort, en het is de verwarrendere, omdat de regel precies wordt toegepast zoals ze geschreven is. Wat veranderd is, is de bestemming: de dienst antwoordt nu op een adres dat de regel nooit heeft genoemd, en aan de tunnel is niets mis.

Wat de regel vastlegt en wat DNS teruggeeft

Een split-tunnelregel is een statische uitspraak over bestemmingen, meestal uitgedrukt als een prefix, een route of een adressenlijst. Hij wordt bij het verzenden tegen de bestemming van het pakket beoordeeld. Een hostnaam is een opzoeking die een set adressen met een levensduur en een cache teruggeeft, en het antwoord kan verschillen per resolver, per querytype en per minuut.

Die twee objecten onderhandelen nooit met elkaar. De regel blijft overeenkomen met het prefix dat hij kreeg, de dienst verandert steeds het adres dat hij uitgeeft, en de kloof tussen beide groeit stil. Daarom verschijnt het symptoom na een provider-migratie of een certificaatvernieuwing en niet na een configuratiewijziging. Niemand heeft de tunnel bewerkt, dus niemand kijkt naar de tunnel, en de diagnose drijft naar de applicatie in plaats van de policy.

Drie manieren waarop de overeenkomst breekt

Het duidelijke geval is een verhuisde dienst: de operator gaf hem een nieuw adres, DNS volgde, en de uitzondering niet. Het tweede is een adresfamilie die de regel nooit dekte, wat gebeurt wanneer een naam AAAA-records begint terug te geven die een uitzondering alleen voor IPv4 negeert. Het derde is een resolververschil: een interne en een openbare weergave kunnen voor dezelfde naam verschillende adressen teruggeven, dus het adres dat je app gebruikt is niet het adres waarmee je testte.

Een gecachte verbinding is een vierde variant en die is makkelijk te missen. De applicatie spreekt misschien nog met een adres dat ze een uur geleden heeft opgelost, wat betekent dat je verse opzoeking en haar open socket het niet eens zijn over waar de dienst woont.

Lees de bestemming die de app echt gebruikt

Vraag het besturingssysteem en de socket-tabel, niet een browsertab. De opzoeking antwoordt waarop de naam nu oplost, en de socket-tabel toont het adres waarmee het proces verbonden is, dat ouder kan zijn. Voer beide uit voordat je een theorie vormt, want het verschil tussen beide is in ongeveer de helft van de gevallen zelf het antwoord.

getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40

Vergelijk daarna met wat de regel dekt. Als het huidige adres buiten de uitzondering valt en de aanvraag nog steeds mislukt, heb je de oorzaak gevonden zonder de tunnelconfiguratie aan te raken. Als de app verbonden is met een adres dat bij de regel past en de aanvraag nog steeds mislukt, ligt het probleem achter de tunnel en is dit het verkeerde onderzoek.

Herstel het mechanisme, niet het symptoom

Als het product onderhouden domeingebaseerde sturing ondersteunt, gebruik die dan en volg het gedocumenteerde verversings- en bereikgedrag. Dat vervangt een statische gok door een onderhouden antwoord, tegen de prijs dat je afhangt van het feit dat de functie werkt zoals gedocumenteerd.

Als het ontwerp op een statische lijst berust, geef die dan een eigenaar en een updateplan. Het plan moet zeggen hoe het adres wordt ontdekt, wie de wijziging goedkeurt en hoe snel de lijst een provider-migratie wordt verwacht te volgen. Een lijst zonder eigenaar is een toekomstige storing met een bekende oorzaak.

Verbreed de uitzondering niet naar een groot naburig netwerk alleen om elk adres te vangen dat je tijdens een korte test zag. Dat is geen herstel; het is een permanente wijziging van de beveiligingsgrens, en het zal niet-verwante diensten stil de tunnel laten omzeilen zolang de regel bestaat.

Controleer beide helften van de bedoeling

Een split-tunnelontwerp heeft twee bedoelingen, en een herstel moet beide behouden. De beschermde dienst moet door de tunnel gaan, en de uitgesloten categorieën moeten eromheen blijven gaan. Test een verse verbinding met de herstelde bestemming, en test daarna iets dat buiten moet blijven.

curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'

Noteer het nieuwe adres, het gekozen mechanisme en de datum. Die notitie is wat de volgende persoon ervan weerhoudt te concluderen dat de VPN willekeurig zijn eigen configuratie negeerde.