Varför en VPN-landsetikett inte är adressen du går ut från

Du väljer ett land, ansluter, och en webbplats hälsar dig välkommen i ett annat. Etiketten i listan har aldrig lovat något om adressen du skulle gå ut från: det är ett fält som någon har publicerat, härlett med en metod du inte har sett. Att behandla det fältet som en adress är där förvirringen börjar.

Tre separata saker bär ett landvärde, och de kan vara oense utan att någon ljuger. Att skilja dem åt gör avvikelsen diagnostiserbar i stället för mystisk.

Tre olika saker bär en landsetikett

Den första är katalogens eget fält, som kan vara självrapporterat av operatören, härlett från en adressdatabas eller helt enkelt kopierat när posten skapades. Den andra är adressen själv, som tillhör det nätverk som annonserar den, och det är detta ett geolokalisationsuppslag svarar på genom att använda publicerade kartdata i den form som beskrivs i RFC 8805. Den tredje är det en applikation bestämmer sig för att visa, vilket kan komma från en annan databas, en kontoinställning eller ett tillstånd du gav på enheten. Bara den andra är ett nätverksfaktum, och även det är ett uppslag snarare än en observation.

Konsekvens mellan de tre skulle vara trevligt och krävs ingenstans. En avvikelse är bevis på att de härleddes olika, inget mer.

Kontrollera adressen, inte flaggan

Den användbara frågan är vilken offentlig adress din trafik faktiskt lämnar. Det kan besvaras från klienten, och det beror inte på något listfält. Jämför svaret med det prefix du förväntade dig och med vad ett geolokalisationsuppslag säger om det, och håll de två resultaten åtskilda i dina anteckningar. En lucka mellan det förväntade landet och uppslaget är en routing- eller databasfråga, medan en lucka mellan uppslaget och applikationens åsikt återigen är en databasfråga.

Gör kontrollen två gånger om tjänsten har flera utgångar i regionen. En adresspool kan dela ut olika adresser vid på varandra följande anslutningar, och ett prov beskriver bara en av dem.

Närhet på en karta är inte närhet på nätverket

Ett närliggande land kan vara en längre väg än ett avlägset, eftersom fiberrutten inte följer gränsen. Att välja en nod efter latens betyder att mäta destinationen du bryr dig om i stället för att ta närmaste flagga. Samma logik gäller för kapacitet, eftersom en lätt belastad utgång två länder bort kan slå en mättad granne. Mät först, bestäm sedan, och notera timmen eftersom båda siffrorna rör sig.

Plats säger inte heller något om lagring eller om vem som driver slutpunkten. Det behöver egna bevis, vilket en landkolumn inte kan rymma.

Bekräfta utgångsadressen själv

Fråga klienten och en extern tjänst hur din adress ser ut, och fråga sedan den lokala routingtabellen hur den rutten valdes. Kommandona nedan gör alla tre, och den tredje är den folk hoppar över. Byt ut gränssnittsnamnet mot din egen tunnelenhet.

curl -sS https://api.ipify.org; echo
curl -sS --interface tun0 https://api.ipify.org; echo
ip route get 1.1.1.1
ip -6 addr show dev tun0

De två första raderna bör stämma, och när de inte gör det är rutten du tror du har inte den rutt som bär din trafik. Ruttuppslaget namnger gränssnittet och källadressen som kärnan skulle använda för en destination, och det är mekanismen bakom utgångsadressen. IPv6-raden spelar roll eftersom en maskin kan hålla en tunnel för den ena familjen och en direkt väg för den andra. En landsetikett täcker inget av dessa fall i sig själv.

Skriv den observerade adressen, databasens åsikt och applikationens visning som tre separata anteckningar. Då blir nästa avvikelse du möter lätt att tillskriva.