Un tunel cumpără topologie, nu criptare sau latență

Ipoteza este că un tunel este un fir privat și rapid: îl construiești, iar traficul din interior este criptat, calea este mai scurtă, iar legătura se comportă ca un cablu între două locații. Fiecare parte a acestei ipoteze este o proprietate separată, iar tunelul oferă doar primul lucru cerut, și anume o cale logică. Tot restul trebuie ales și configurat intenționat. Confundarea proprietăților este modul în care un proiect ajunge cu o legătură criptată pe care nimeni nu o poate diagnostica și cu o promisiune de latență pe care nimeni nu o poate ține.

Mitul: un tunel, trei garanții

Un tunel face un singur lucru în mod fiabil. Face ca două capete care nu sunt conectate direct să se comporte ca și cum ar fi adiacente pentru un anumit scop, în timp ce rețeaua intermediară transportă pachetele externe. Aceasta este o schimbare de topologie și este cu adevărat utilă în sine.

Criptarea, transportul protocoalelor și izolarea redirecționării sunt decizii separate suprapuse. Un tunel GRE nu are niciuna dintre cele trei în sens criptografic, iar un tunel IP-in-IP este un proiect valid fără nicio confidențialitate. Niciunul nu este o greșeală; sunt tuneluri care fac exact ceea ce fac tunelurile. Eticheta de pe diagramă nu spune ce proprietăți sunt prezente.

Odată ce separi proprietățile, întrebările devin respondabile: acest tunel transportă o adiacență de rutare, transportă cadre, ascunde adresele interne, promite ceva despre întârziere? Acestea sunt patru răspunsuri diferite cu patru consecințe de configurare diferite.

Ce adaugă de fapt tunelul la hartă

Capetele obțin o cale pe care nu o aveau înainte. Dacă acea cale se comportă ca un salt rutat sau ca un segment Ethernet depinde în întregime de encapsulare, iar diferența schimbă ce pot face cele două locații cu ea. Un tunel rutat îți dă un următor salt și un prefix; o extensie Ethernet îți dă comportament de difuzare și un domeniu de eșec mult mai mare.

Un tunel IP nu face automat locația îndepărtată parte din același subrețea și nu face un protocol de rutare să ruleze prin el decât dacă implementarea acceptă acea adiacență. Multicast este o altă întrebare separată, cu propriul răspuns.

ip -d link show type gre
ip route get 10.20.0.5
traceroute -n -T -p 443 10.20.0.5
mtr -n --report -c 20 10.20.0.5

Acele comenzi răspund la părți diferite ale întrebării. Prima spune ce tip de interfață există, a doua spune ce cale ar alege nucleul, iar ultimele două arată comportamentul real al stratului inferior în loc de promisiunea etichetei.

Transportul este o decizie separată de accesibilitate

Un tunel poate transporta un protocol pe care stratul inferior nu îl redirecționează. IPv6 peste o cale IPv4 este cazul clasic și funcționează pentru că extremitățile înțeleg ambele familii, în timp ce routerele dintre ele trebuie doar să livreze pachetele externe. Stratul inferior are nevoie de o cale funcțională până la capătul tunelului și nimic mai mult.

Capetele, însă, au nevoie de suport complet: redirecționare, adrese și o aplicație care folosește efectiv familia internă. Atribuirea unui prefix IPv6 unui tunel nu face un serviciu care funcționează doar cu IPv4 accesibil prin IPv6 și nu face stratul inferior dual-stack.

Transportul cadrelor este un angajament mai mare decât transportul protocoalelor. Extinderea unui domeniu de difuzare printr-un tunel mută cu el comportamentul spanning tree, ARP și propagarea eșecurilor, ceea ce este o decizie de proiectare și nu un comutator de funcție.

Izolarea nu este confidențialitate

VPN-urile furnizorilor țin rutele și traficul clienților în contexte de redirecționare separate, iar acea separare este reală și valoroasă. Nu este criptare. Specificația BGP/MPLS VPN spune explicit că intimitatea sa vine din modelul de redirecționare și nu din criptografie, iar exact aceasta este distincția care se pierde într-un slide care spune doar VPN.

Dacă aveți nevoie de confidențialitate, aveți nevoie de un mecanism criptografic cu autentificare și gestionarea cheilor și trebuie să știți unde se termină. Un tunel care oferă separare și un tunel care oferă criptare pot fi același tunel, dar numai când cineva le-a configurat pe amândouă.

Consecința practică este că „este într-un VPN” răspunde la o întrebare despre contextul de rutare și nu vă spune nimic despre cine poate citi octeții de pe cale. Două echipe pot avea amândouă dreptate și totuși să descrie lucruri diferite. Când apare întrebarea de securitate, întrebați unde se termină criptografia și ce autentifică partenerii, nu dacă există un tunel.

Latența și QoS urmează stratul inferior

O margine logică nu este o cale fizică mai scurtă. Pachetele externe traversează în continuare aceleași legături, cozi și furnizori, iar encapsularea adaugă suprasarcină pe pachet plus procesare la ambele capete. Un tunel poate fi rapid pentru că stratul inferior este bun, niciodată pentru că este un tunel.

Tratamentul calității serviciului este mai rău decât atât, pentru că depinde de domenii administrative pe care s-ar putea să nu le controlați. Marcajele interne trebuie mapate deliberat pe cele externe, iar fiecare furnizor de pe cale trebuie să ofere tratamentul pe care îl așteptați. Criptarea nu creează prioritate; ascunde câmpul pe care un echipament intermediar l-ar fi putut folosi pentru a clasifica fluxul.

Măsurați stratul inferior înainte de a promite ceva. Un raport care arată întârziere stabilă și nicio pierdere pe calea externă este o dovadă; o diagramă cu un tunel pe ea nu este.

Alegeți tunelul pentru relația de rețea de care aveți nevoie, apoi specificați separat criptarea, politica de acces, dimensiunea pachetului și performanța. Patru decizii, patru dovezi și nicio etichetă unică ce ar sta în locul vreuneia dintre ele.