Waarom een VPN-landlabel niet het adres is waar je uit vertrekt
Een veld in de lijst, een gerouteerd adres en de mening van een app kunnen allemaal van elkaar afwijken. Bepaal welke je leest voordat je de uitgang verkeerd gelabeld noemt.
Je kiest een land, maakt verbinding, en een website begroet je in een ander. Het label in de lijst heeft nooit iets beloofd over het adres waar je uit zou vertrekken: het is een veld dat iemand heeft gepubliceerd, afgeleid met een methode die je niet hebt gezien. Dat veld als adres behandelen is waar de verwarring begint.
Drie afzonderlijke dingen dragen een landwaarde, en ze kunnen het oneens zijn zonder dat iemand liegt. Ze onderscheiden maakt de mismatch diagnoseerbaar in plaats van mysterieus.
Drie verschillende dingen dragen een landlabel
Het eerste is het veld van de gids zelf, dat door de operator zelf kan zijn opgegeven, uit een adressendatabase kan zijn afgeleid of simpelweg is gekopieerd toen de vermelding werd aangemaakt. Het tweede is het adres zelf, dat toebehoort aan welk netwerk het ook aankondigt, en dat is wat een geolocatie-opzoeking beantwoordt met behulp van gepubliceerde kaartgegevens in de vorm die wordt beschreven in RFC 8805. Het derde is wat een applicatie besluit te tonen, dat uit een andere database, een accountinstelling of een toestemming die je op het apparaat gaf kan komen. Alleen het tweede is een netwerkfeit, en zelfs dat is een opzoeking in plaats van een waarneming.
Consistentie tussen die drie zou prettig zijn en wordt nergens vereist. Een mismatch is bewijs dat ze verschillend zijn afgeleid, niets meer.
Controleer het adres, niet de vlag
De nuttige vraag is via welk openbaar adres je verkeer daadwerkelijk naar buiten gaat. Dat is vanaf de client te beantwoorden, en het hangt van geen enkel lijstveld af. Vergelijk het antwoord met het prefix dat je verwachtte en met wat een geolocatie-opzoeking erover zegt, en houd de twee resultaten apart in je notities. Een gat tussen het verwachte land en de opzoeking is een routerings- of databasevraag, terwijl een gat tussen de opzoeking en de mening van de applicatie weer een databasevraag is.
Doe de controle twee keer als de dienst meerdere uitgangen in de regio heeft. Een pool kan bij opeenvolgende verbindingen verschillende adressen uitdelen, en één monster beschrijft er maar één van.
Nabijheid op een kaart is geen nabijheid op het netwerk
Een nabij land kan een langere route zijn dan een ver land, omdat de glasvezelroute de grens niet volgt. Een knooppunt op latentie kiezen betekent de bestemming meten die voor jou belangrijk is in plaats van de dichtstbijzijnde vlag pakken. Dezelfde logica geldt voor capaciteit, want een licht belaste uitgang twee landen verder kan een verzadigde buur verslaan. Meet eerst, beslis daarna, en noteer het uur want beide getallen bewegen.
Locatie zegt ook niets over bewaring of over wie het eindpunt beheert. Dat heeft zijn eigen bewijs nodig, wat een landkolom niet kan bevatten.
Bevestig het uitgangsadres zelf
Vraag de client en een externe dienst hoe je adres eruitziet, en vraag dan de lokale routeringstabel hoe die route is gekozen. De commando's hieronder doen alle drie, en de derde is degene die mensen overslaan. Vervang de interfacenaam door je eigen tunnelapparaat.
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 eerste twee regels zouden moeten overeenkomen, en als ze dat niet doen, is de route waarvan je denkt dat je hem hebt niet de route die je verkeer draagt. De route-opzoeking noemt de interface en het bronadres dat de kernel voor een bestemming zou gebruiken, en dat is het mechanisme achter het uitgangsadres. De IPv6-regel is belangrijk omdat een machine een tunnel voor de ene familie en een directe route voor de andere kan houden. Een landlabel dekt geen van die gevallen op zichzelf.
Schrijf het waargenomen adres, de mening van de database en de weergave van de applicatie als drie aparte notities. De volgende mismatch die je tegenkomt is dan makkelijk toe te schrijven.