Waarom ’n VPN-landetiket nie die adres is waaruit jy vertrek nie

Jy kies ’n land, maak koneksie, en ’n webwerf groet jou in ’n ander een. Die etiket in die lys het nooit iets belowe oor die adres waaruit jy sou vertrek nie: dit is ’n veld wat iemand gepubliseer het, afgelei deur ’n metode wat jy nog nie gesien het nie. Om daardie veld as ’n adres te behandel, is waar die verwarring begin.

Drie afsonderlike dinge dra ’n landwaarde, en hulle kan verskil sonder dat iemand lieg. Om hulle van mekaar te onderskei maak die wanverhouding diagnoseerbaar eerder as raaiselagtig.

Drie verskillende dinge dra ’n landetiket

Die eerste is die gids se eie veld, wat deur die operateur self gerapporteer kan wees, uit ’n adresdatabasis afgelei, of bloot gekopieer toe die inskrywing geskep is. Die tweede is die adres self, wat aan watter netwerk dit ook al aankondig behoort, en dit is wat ’n geoliggingopsoek beantwoord deur gepubliseerde karteringsdata te gebruik in die vorm wat beskryf word in RFC 8805. Die derde is wat ’n toepassing besluit om te wys, wat uit ’n ander databasis, ’n rekeninginstelling of ’n toestemming wat jy op die toestel gegee het, kan kom. Net die tweede is ’n netwerkfeit, en selfs dit is ’n opsoek eerder as ’n waarneming.

Konsekwentheid tussen daardie drie sou aangenaam wees en word nêrens vereis nie. ’n Wanverhouding is bewys dat hulle anders afgelei is, niks meer nie.

Kontroleer die adres, nie die vlag nie

Die nuttige vraag is watter openbare adres jou verkeer werklik verlaat. Dit is van die kliënt af beantwoordbaar, en dit hang nie van enige lysveld af nie. Vergelyk die antwoord met die voorvoegsel wat jy verwag het en met wat ’n geoliggingopsoek daaroor sê, en hou die twee resultate apart in jou notas. ’n Gap tussen die verwagte land en die opsoek is ’n routerings- of databasisvraag, terwyl ’n gap tussen die opsoek en die toepassing se mening weer ’n databasisvraag is.

Doen die kontrole twee keer as die diens verskeie uitgange in die streek het. ’n Poel kan verskillende adresse by opeenvolgende koneksies uitdeel, en een monster beskryf een van hulle.

Nabyheid op ’n kaart is nie nabyheid op die netwerk nie

’n Nabygeleë land kan ’n langer pad wees as ’n ver land, want die veselroete volg nie die grens nie. Om ’n nodus vir latency te kies beteken om die bestemming te meet wat vir jou saak maak eerder as om die naaste vlag te kies. Dieselfde logika geld vir kapasiteit, want ’n lig belaaide uitgang twee lande weg kan ’n versadigde een langsaan klop. Meet eerste, besluit tweede, en let op die uur want albei syfers beweeg.

Ligging sê ook niks oor bewaring of oor wie die eindpunt bedryf nie. Daardie dinge het hul eie bewyse nodig, wat ’n landkolom nie kan hou nie.

Bevestig die uitgangadres self

Vra die kliënt en ’n buitediens hoe jou adres lyk, en vra dan die plaaslike routeringstabel hoe daardie pad gekies is. Die opdragte hieronder doen al drie, en die derde is die een wat mense oorslaan. Vervang die koppelvlaknaam met jou eie tonneltoestel.

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

Die eerste twee reëls behoort ooreen te stem, en wanneer hulle dit nie doen nie, is die roete wat jy dink jy het nie die roete wat jou verkeer dra nie. Die roeteopsoek noem die koppelvlak en bronadres wat die kernel vir ’n bestemming sou gebruik, wat die meganisme agter die uitgangadres is. Die IPv6-reël maak saak omdat ’n masjien ’n tonnel vir een familie en ’n direkte pad vir die ander kan hou. ’n Landetiket dek nie een van daardie gevalle op sigself nie.

Skryf die waargenome adres, die databasis se mening en die toepassing se vertoning as drie afsonderlike notas neer. Die volgende wanverhouding wat jy tee kom, sal dan maklik toe te skryf wees.