Wat 'n VPN-tonnel is, en waar die beskerming ophou

Die kliënt sê verbind, die slot is gesluit, en ’n webwerf teken steeds die adres van jou woonstel aan. Niks het misluk nie. ’n Tonnel vervang nie jou Wi-Fi of jou mobiele verbinding nie; dit plaas ’n tweede koevert om sekere pakkies en stuur daardie koevert oor die netwerk wat jy reeds gehad het. Om die truuk te verstaan is meestal ’n kwessie van een versoek volg en oplet waar die koevert oopgemaak word, want byna elke verwarrende simptoom, van ’n lekkende tuisadres tot ’n vasgeloopte groot aflaai, kom van daardie grens.

Twee koeverte, een fisiese skakel

Jou skootrekenaar hou sy normale verbinding met die router, en die router hou sy normale verbinding met die diensverskaffer. Niks aan daardie pad verander wanneer ’n tonnel opkom nie. Wat verander, is dat geselekteerde pakkies aan ’n virtuele koppelvlak oorgehandig word, binne ’n nuwe pakkie toegedraai word wat aan die VPN-eweknie gerig is, en as gewone verkeer oor die fisiese skakel gestuur word.

Die ontvangkant is ’n toestel wat die koevert oopmaak en die oorspronklike pakkie na sy bestemming aanstuur. Tussen die twee kante sien ’n waarnemer die buitenste kop en niks van die binneste nie, tensy die protokol dit versleutel, wat die meeste verbruikerprotokolle doen en die algemene tegniek nie vereis nie.

Dit is waarom die virtuele koppelvlak beide werklik en misleidend is. Dit bestaan as ’n kerndeel met ’n adres en ’n maksimum oordragingseenheid, en die bedryfstelsel stuur verkeer daarin soos in enige ander koppelvlak. Dit is nie ’n kabel nie, en sy bestaan bewys net dat ’n komponent geïnstalleer is. Of jou blaaier dit gebruik, word deur roetes besluit, nie deur die koppelvlak wat op is nie.

Kyk hoe een versoek die reis onderneem

Kies ’n bestemming en vra die kern watter koppelvlak dit sal gebruik. Hierdie enkele opdrag besleg die meeste argumente oor of die tonnel enigiets doen:

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

As die roete-uitvoer die tonnelkoppelvlak noem, sal die pakkie toegedraai word. As dit die fisiese koppelvlak noem, sal dit nie gebeur nie, en geen hoeveelheid herbegin van die kliënt verander dit nie. Die tweede opdrag wys albei koppelvlakke langs mekaar, wat is hoe jy ’n tonnel raaksien wat opgekom het sonder ’n adres of met ’n adres in die verkeerde familie.

Kyk dan na die eerste sprong van binne die koevert, en vergelyk dit met die eerste sprong daarbuite:

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

Binne die tonnel is die eerste sprong die eweknie se binneste adres, nie jou router nie. Die opname op die tonnelkoppelvlak wys die binneste pakkies, dit is die verkeer wat die toepassing glo dit stuur. Om gelyktydig op die fisiese koppelvlak op te neem wys die buitenste pakkies, en die twee saam is die duidelikste demonstrasie van wat ’n tonnel werklik doen.

Drie adresse, en net een word deur die webwerf gesien

Mense verwar hierdie dinge voortdurend, en die verwarring lewer valse lekverslae op. Dit is verskillende velde in verskillende koppe met verskillende leeftye.

Die nommer langs die virtuele adapter is die tweede ry. Dit is nie die adres wat ’n webwerf aanteken nie, en om dit as jou openbare IP aan te haal is eenvoudig verkeerd. Die adres wat ’n webwerf sien, word deur die uitgang toegewys, en vir ’n tonnel na ’n private netwerk is daar dalk glad geen openbare uitgang nie, want die bestemming leef binne die organisasie eerder as op die internet.

’n Tonnel tussen twee terreine is dieselfde meganisme met ander eindpunte. Twee routers verpak verkeer tussen netwerke, en geen individuele toestel het ’n kliënt geïnstalleer nie. Die koevert is in beginsel identies en die administratiewe grens is nie.

Waar die koevert oopgemaak word, en wat dit oorleef

Die tonnel eindig by sy eweknie. As die toepassing se eie versleuteling verder strek, oorleef dit daardie grens, wat die normale geval vir HTTPS is: die blaaier se sessie eindig by die webwerf, so die uitgang stuur syferteks aan wat hy nie kan lees nie.

Niks anders oorleef by verstek nie. ’n Onversleutelde versoek is by die uitgang leesbaar net soos dit op die kafee se Wi-Fi leesbaar was, en die tonnel voeg geen beskerming by wat die toepassing nooit gehad het nie. Net so bepaal die uitgang se firewall-reëls en aanstuurbeleid wat volgende gebeur; ’n suksesvolle handdruk is ’n feit oor die eweknieverbinding, nie oor die res van die reis nie.

Oorhoofs is die ander sigbare gevolg. Elke pakkie dra ’n ekstra kop, en die buitenste vervoer kan sy eie byvoeg, so die bruikbare loonvrag per pakkie krimp. Op ’n pad met ’n vaste maksimum oordragingseenheid is dit presies waarom ’n tonnel ’n ping kan deurlaat en ’n groot oplaai kan laat vasloop.

Kontroleer die pad wat die toepassing werklik geneem het

Die laaste stap is om die spesifieke toepassing te bevestig, eerder as die masjien in die algemeen. Los die bestemming op, kyk na die roete vir daardie adres, en waarneem dan die verbinding terwyl dit oop is:

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

As die roete die tonnel noem maar die sokkie-lys wys ’n verbinding met ’n bronadres van die fisiese koppelvlak, is die toepassing aan iets spesifiek gebind, of ’n tweede tonnel ding mee om die verstekroete. Dit is ’n roetevraag, en dit is beantwoordbaar uit hierdie drie uitsette eerder as uit die kliënt se statuskerm.

Die RFC 4301-sekuriteitsargitektuur beskryf die IP-laag-weergawe van hierdie toedraaiing vir IPsec, en dieselfde laaglogika geld vir WireGuard en OpenVPN. Sodra jy die binneste pakkie en die buitenste pakkie as aparte objekte kan aanwys, hou die meeste tonnelgedrag op om raaiselagtig te wees en word dit ’n roetetabel wat jy kan lees.