Verifiera att en delad tunnel fungerar: ett IP-resultat är inget test

En enda webbläsarsida som visar en IP-adress bevisar nästan ingenting om en delad tunnel. En synlig adress kan vara rätt av fel anledning, och ett uteslutet flöde prövas aldrig av den. Skriv ner det förväntade resultatet innan du testar: vilken applikation eller destination som ska använda tunneln, vilken som ska förbli direkt, och vad som ska stanna när tunneln fallerar. Utan den planen ser varje rimligt tal ut som framgång.

Myten: en adressökning bevisar täckning

IP-kontrollen svarar på en fråga: vad omvärlden ser från en applikation vid ett tillfälle. Den säger ingenting om ett internt prefix, en andra webbläsarprofil eller ett namn som ska lösas privat. Den säger inte heller något om fel, och det är den halva av en delad tunnel som går sönder i produktion.

En adressida kan inte heller visa rutten, resolvern eller felpolicyn. Behandla den som en observation, inte som en dom.

Pröva ett inkluderat flöde och ett uteslutet

Skicka en ofarlig begäran från applikationen som ska ingå, eller till det prefix du förväntar dig ska dirigeras genom tunneln, och logga källa, destination, adressfamilj och observerad väg. Gör samma sak för ett flöde som ska förbli direkt. Den uteslutna sidan är den folk hoppar över, och det är det enda beviset för att uppdelningen är avsiktlig och inte tillfällig. En hjälpprocess kan bära en separat policyidentitet, så testa i den process som äger socketen.

flow: Firefox to intranet.example:443, IPv4, source 10.8.0.6, tunneled
flow: Firefox to 1.1.1.1, IPv4, source 192.0.2.20, direct

Det är därför ett test i fel applikation kan visa motsatsen till vad designen avser. Skriv ner de fyra fälten för båda sidor innan du drar någon slutsats.

Lägg till DNS och felfallet

Fråga systemets resolver och den resolver appen använder, och jämför sedan de svaren med den utgångsadress som webbplatsen rapporterar. De två lagren kan vara oense med avsikt, och en webbläsaruppslagning prövar inte operativsystemets policy. Ett skal gör jämförelsen repeterbar: Bryt tunneln med avsikt, gör sedan en begäran som webbläsaren inte har cachat; en sida som serveras från cachen säger ingenting om vilket håll reservvägen tog. Registrera vad som faktiskt hände i stället för vad designen förutsade.

curl -s https://ifconfig.me
nslookup intranet.example

En delad tunnel som fallerar stängt och en som fallerar öppet ser identiska ut tills du bryter tunneln med avsikt. Registrera vilket beteende du observerade, inte vilket du förväntade dig.

Upprepa efter att tillståndet ändrats

Upprepa samma observationer efter en återanslutning, ett nätverksbyte och en relevant applikationsuppdatering. Ett sparat undantag kan fortsätta peka på en väg eller en applikationsidentitet som inte längre finns, och designen slutar tyst matcha sin dokumentation. De tre händelserna är där delade tunnlar driver, och var och en är billig att testa om. Ett test som bara körs en gång vid driftsättningen beskriver en konfiguration som inte längre finns.

Om ett resultat avviker, hitta regelägaren och bearbetningssteget innan du ändrar flera inställningar på en gång. Att ändra fem saker och observera ett resultat är inte en diagnos, det är en ny konfiguration.

Vad resultatet ska fastställa

Knyt observationerna till den policy och klientversion du faktiskt testade. Målet är att visa att den här driftsättningen matchar den täckning den hävdar, inte att varje framtida applikation kommer att vara privat. Det är ett snävare påstående, och det är det du faktiskt kan styrka med bevis. Skriv påståendet, versionen och fyrfältsresultaten i ändringsregistret.

Då kan nästa granskare se om designen ändrades eller testet gjorde det. En delad tunnel är verifierad när båda sidor, resolveruppdelningen och felbeteendet matchar det du skrev ner i början. Ett IP-resultat verifierar ingen av dem.