Du vælger et land, opretter forbindelse, og et websted byder dig velkommen i et andet. Mærket på listen har aldrig lovet noget om den adresse, du ville gå ud fra: det er et felt, som nogen har offentliggjort, udledt af en metode, du ikke har set. At behandle det felt som en adresse er der, hvor forvirringen begynder.

Tre forskellige ting bærer en landeværdi, og de kan være uenige, uden at nogen lyver. Når du skelner dem, bliver uoverensstemmelsen diagnosticerbar i stedet for mystisk.

Tre forskellige ting bærer et landemærke

Den første er katalogets eget felt, som kan være selvrapporteret af operatøren, udledt af en adressedatabase eller blot kopieret, da posten blev oprettet. Den anden er selve adressen, som tilhører det netværk, der annoncerer den, og det er, hvad et geolokationsopslag svarer på ved at bruge offentliggjorte kortdata i den form, der er beskrevet i RFC 8805. Den tredje er det, en applikation beslutter at vise, og det kan komme fra en anden database, en kontoindstilling eller en tilladelse, du gav på enheden. Kun den anden er et netværksfaktum, og selv det er et opslag frem for en iagttagelse.

Sammenhæng mellem de tre ville være behagelig og kræves ingen steder. En uoverensstemmelse er bevis på, at de blev udledt forskelligt, ikke andet.

Tjek adressen, ikke flaget

Det nyttige spørgsmål er, hvilken offentlig adresse din trafik faktisk forlader. Det kan besvares fra klienten, og det afhænger ikke af noget listefelt. Sammenlign svaret med det præfiks, du forventede, og med hvad et geolokationsopslag siger om det, og hold de to resultater adskilt i dine noter. Et gab mellem det forventede land og opslaget er et routing- eller database-spørgsmål, mens et gab mellem opslaget og applikationens mening igen er et database-spørgsmål.

Udfør tjekket to gange, hvis tjenesten har flere udgange i regionen. En pulje kan udlevere forskellige adresser ved på hinanden følgende forbindelser, og én prøve beskriver kun én af dem.

Nærhed på et kort er ikke nærhed på netværket

Et nærliggende land kan være en længere vej end et fjernt, fordi fiberruten ikke følger grænsen. At vælge en node efter latens betyder at måle den destination, du bekymrer dig om, i stedet for at vælge det nærmeste flag. Samme logik gælder for kapacitet, fordi en let belastet udgang to lande væk kan slå en mættet nabo. Mål først, beslut derefter, og noter timen, fordi begge tal flytter sig.

Placering siger heller intet om opbevaring eller om, hvem der driver endepunktet. Det kræver sine egne beviser, som en landekolonne ikke kan rumme.

Bekræft udgangsadressen selv

Spørg klienten og en ekstern tjeneste, hvordan din adresse ser ud, og spørg derefter den lokale routingtabel, hvordan den rute blev valgt. Kommandoerne nedenfor gør alle tre, og den tredje er den, folk springer over. Erstat grænsefladenavnet med din egen tunnel-enhed.

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 to første linjer bør stemme overens, og når de ikke gør, er den rute, du tror, du har, ikke den rute, der bærer din trafik. Ruteopslaget angiver den grænseflade og kildeadresse, som kernen ville bruge til en destination, og det er mekanismen bag udgangsadressen. IPv6-linjen betyder noget, fordi en maskine kan holde en tunnel til den ene familie og en direkte vej til den anden. Et landemærke dækker ingen af disse tilfælde i sig selv.

Skriv den observerede adresse, databasens mening og applikationens visning som tre separate noter. Så bliver den næste uoverensstemmelse, du møder, let at henføre.

Relaterede artikler