De klant seit ferbûn, it slot is ticht, en in side registrearret noch altyd it adres fan jo flat. Der is neat misgien. In tunnel ferfangt net jo Wi-Fi of jo mobile ferbining; hy set in twadde omhulslein om beskate pakketten en stjoert dat omhulslein oer it netwurk dat jo al hiene. It trúkje begripe is benammen in kwestje fan ien oanfraach folgje en opmerke wêr't it omhulslein iepene wurdt, want hast elk betiizjend symptoom, fan in lekke thúsadres oant in fêstrûn grutte download, komt fan dy grins.

Twa omhulsels, ien fysike keppeling

Jo laptop hâldt syn normale ferbining mei de router, en de router hâldt syn normale ferbining mei de provider. Oan dat paad feroaret neat as in tunnel omheech komt. Wat feroaret is dat beskate pakketten oan in firtuele ynterface jûn wurde, yn in nij pakket ferpakt wurde dat oan de VPN-pear rjochte is, en as gewoan ferkear oer de fysike keppeling stjoerd wurde.

De ûntfangende ein is in apparaat dat it omhulslein iepenet en it oarspronklike pakket nei syn bestimming trochstjoert. Tusken de twa einen sjocht in waarnimmer de bûtenste kop en neat fan 'e binnenste, útsein as it protokol dy fersiferet, wat de measte konsuminteprotokollen dogge en de algemiene technyk net easket.

Dêrom is de firtuele ynterface tagelyk echt en misliedend. Hy bestiet as in kearnobjekt mei in adres en in maksimale oerdrachtienheid, en it bestjoeringssysteem rûtelet ferkear deryn lykas yn elk oar ynterface. It is gjin kabel, en syn bestean bewiist allinnich dat in komponint ynstallearre is. Oft jo browser it brûkt, wurdt besletten troch rûtes, net troch it feit dat it ynterface omheech is.

Sjoch ien oanfraach de reis meitsje

Kies in bestimming en freegje de kearn hokker ynterface hy brûkt. Dit iene kommando beslist de measte diskusjes oer de fraach oft de tunnel eat docht:

ip route get 203.0.113.7
ip -brief addr show
ip -4 addr show dev wg0

As de rûte-útfier it tunnel-ynterface neamt, sil it pakket ferpakt wurde. As it it fysike ynterface neamt, dan net, en gjin hielendal opnij starten fan 'e klant feroaret dat. It twadde kommando lit beide ynterfaces njonken elkoar sjen, en sa merkst in tunnel op dy't omheech kaam sûnder adres of mei in adres út 'e ferkearde famylje.

Sjoch dan nei de earste sprong fan binnenút it omhulslein, en fergelykje dy mei de earste sprong fan bûten:

traceroute -n -m 3 203.0.113.7
sudo tcpdump -ni wg0 -c 5

Binnen de tunnel is de earste sprong it binnenadres fan 'e pear, net jo router. De opname op it tunnel-ynterface lit de binnenste pakketten sjen, dat is it ferkear dat de applikaasje mient te stjoeren. Tagelyk opnimme op it fysike ynterface lit de bûtenste pakketten sjen, en tegearre binne se de dúdlikste demonstraasje fan wat in tunnel eins docht.

Trije adressen, en mar ien wurdt troch de side sjoen

Minsken betiizje dizze hieltyd, en de betizing liedt ta falske lekrapporten. It binne ferskillende fjilden yn ferskillende koppen mei ferskillende libbensdieren.

AddressWhere it appearsWho can see it
Endpoint addressOuter header, the peer you connect toYour access network and the path to it
Inner tunnel addressInside the envelope, on the virtual interfaceThe peer, and anything the peer routes to
Exit addressSource of the packet that reaches the websiteThe website and its upstream

It nûmer njonken de firtuele adapter is de twadde rige. It is net it adres dat in side registrearret, en it as jo iepenbiere IP neame is gewoan ferkeard. It adres dat in side sjocht wurdt tawiisd troch de útgong, en by in tunnel nei in partikulier netwurk is der miskien hielendal gjin iepenbiere útgong, want de bestimming libbet binnen de organisaasje en net op it ynternet.

In tunnel tusken siden is itselde meganisme mei oare einpunten. Twa routers pakke ferkear tusken netwurken yn, en gjin inkeld apparaat hat in klant ynstallearre. It omhulslein is yn prinsipe identyk, de bestjoerlike grins net.

Wêr't it omhulslein iepene wurdt, en wat dat oerlibbet

De tunnel einiget by syn pear. As de eigen fersifering fan 'e applikaasje fierder rikt, oerlibbet dy dy grins, wat it normale gefal is by HTTPS: de sesje fan 'e browser einiget op 'e side, dus de útgong stjoert siferskrift troch dat hy net lêze kin.

Neat oars oerlibbet standert. In net-fersifere oanfraach is by de útgong lêsber krekt sa't er lêsber wie op 'e Wi-Fi fan it kafee, en de tunnel foeget gjin beskerming ta dy't de applikaasje nea hân hat. Likegoed bepale de firewall-regels en it trochstjoerbelied fan 'e útgong wat der folgjende bart; in slagge hânskodding is in feit oer de ferbining mei de pear, net oer de rest fan 'e reis.

Oerheft is it oare sichtbere gefolch. Elk pakket draacht in ekstra kop, en it bûtenste ferfier kin syn eigen tafoegje, sadat de brûkbere lading per pakket krimpt. Op in paad mei in fêste maksimale oerdrachtienheid is dat krekt wêrom't in tunnel in ping trochlitte kin en in grutte upload fêstrinne litte kin.

Kontrolearje it paad dat de applikaasje eins nommen hat

De lêste stap is de spesifike applikaasje te befêstigjen, net de masine yn 't algemien. Los de bestimming op, sjoch nei de rûte foar dat adres, en observearje dan de ferbining wylst dy iepen is:

getent hosts example.com
ip route get "$(getent hosts example.com | awk '{print $1; exit}')"
ss -tnp state established '( dport = :443 )'

As de rûte de tunnel neamt mar de socketlist in ferbining sjen lit mei in boarneadres fan it fysike ynterface, is de applikaasje bûn oan eat spesifyks, of in twadde tunnel konkurrearret om 'e standertrûte. Dat is in rûtefraach, en dy is te beäntwurdzjen út dizze trije útfieringen ynstee fan it statuskerm fan 'e klant.

De RFC 4301-feiligheidsarsjitektuer beskriuwt de IP-laachferzje fan dit ferpakken foar IPsec, en deselde laachlogika jildt foar WireGuard en OpenVPN. Sadree't jo it binnenste pakket en it bûtenste pakket as aparte objekten oanwize kinne, hâldt it measte tunnelgedrach op mysterieus te wêzen en wurdt it in rûtetabel dy't jo lêze kinne.

Relatearre artikelen