Un túnel compra topologia, no xifrat ni latència

La suposició és que un túnel és un cable privat i ràpid: el construïu i el trànsit interior queda xifrat, el camí és més curt i l’enllaç es comporta com un cable entre dos llocs. Cada part d’aquesta suposició és una propietat separada, i el túnel només lliura la primera cosa que li heu demanat, que és un camí lògic. Tota la resta s’ha de triar i configurar a propòsit. Confondre les propietats és com un disseny acaba amb un enllaç xifrat que ningú no pot diagnosticar i una promesa de latència que ningú no pot complir.

El mite: un túnel, tres garanties

Un túnel fa una cosa de manera fiable. Fa que dos extrems que no estan connectats directament es comportin com si fossin adjacents per a algun propòsit, mentre la xarxa intermèdia transporta els paquets externs. Això és un canvi de topologia, i és realment útil per si mateix.

El xifrat, el transport de protocols i l’aïllament del reenviament són decisions separades que es posen a sobre. Un túnel GRE no té cap de les tres en el sentit criptogràfic, i un túnel IP-in-IP és un disseny vàlid sense cap confidencialitat. Cap de les dues coses no és un error; són túnels fent exactament el que fan els túnels. L’etiqueta del diagrama no us diu quines propietats hi són presents.

Un cop separeu les propietats, les preguntes es poden respondre: aquest túnel transporta una adjacència d’encaminament, transporta trames, amaga les adreces internes, promet res sobre el retard? Són quatre respostes diferents amb quatre conseqüències de configuració diferents.

Què afegeix realment el túnel al mapa

Els extrems obtenen un camí que abans no tenien. Que aquest camí es comporti com un salt encaminat o com un segment Ethernet depèn totalment de l’encapsulament, i la diferència canvia què poden fer els dos llocs amb ell. Un túnel encaminat us dona un salt següent i un prefix; una extensió Ethernet us dona comportament de difusió i un domini de fallada molt més gran.

Un túnel IP no fa que el lloc remot formi part automàticament de la mateixa subxarxa, ni fa que un protocol d’encaminament hi corri tret que la implementació admeti aquesta adjacència. El multicast és una altra pregunta separada amb la seva pròpia resposta.

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

Aquestes ordres responen a parts diferents de la pregunta. La primera us diu quin tipus d’interfície existeix, la segona us diu quin camí triaria el nucli, i les dues últimes mostren el comportament real de la capa inferior en lloc de la promesa de l’etiqueta.

El transport és una decisió separada de l’abast

Un túnel pot transportar un protocol que la capa inferior no reenvia. IPv6 sobre un camí IPv4 és el cas clàssic, i funciona perquè els extrems entenen les dues famílies mentre que els encaminadors entremig només han de lliurar els paquets externs. La capa inferior necessita un camí funcional fins a l’extrem del túnel i res més.

Els extrems, però, necessiten suport complet: reenviament, adreces i una aplicació que faci servir realment la família interna. Assignar un prefix IPv6 a un túnel no fa que un servei només IPv4 sigui abastable per IPv6, ni fa que la capa inferior sigui de doble pila.

El transport de trames és un compromís més gran que el transport de protocols. Estendre un domini de difusió per un túnel mou amb ell el comportament de spanning tree, ARP i la propagació de fallades, cosa que és una decisió de disseny i no un commutador de funció.

L’aïllament no és confidencialitat

Les VPN de proveïdor mantenen les rutes i el trànsit dels clients en contextos de reenviament separats, i aquesta separació és real i valuosa. No és xifrat. L’especificació de BGP/MPLS VPN diu explícitament que la seva privadesa ve del model de reenviament i no de la criptografia, que és exactament la distinció que es perd en una diapositiva que només diu VPN.

Si necessiteu confidencialitat, necessiteu un mecanisme criptogràfic amb autenticació i gestió de claus, i heu de saber on acaba. Un túnel que proporciona separació i un túnel que proporciona xifrat poden ser el mateix túnel, però només quan algú ha configurat tots dos.

La conseqüència pràctica és que «està dins d’una VPN» respon una pregunta sobre el context d’encaminament i no us diu res sobre qui pot llegir els bytes del camí. Dos equips poden tenir tots dos raó i tot i així descriure coses diferents. Quan surti la pregunta de seguretat, pregunteu on acaba la criptografia i què autentica els parells, no si existeix un túnel.

La latència i el QoS segueixen la capa inferior

Una vora lògica no és un camí físic més curt. Els paquets externs continuen travessant els mateixos enllaços, cues i proveïdors, i l’encapsulament afegeix sobrecàrrega per paquet més processament als dos extrems. Un túnel pot ser ràpid perquè la capa inferior és bona, mai perquè sigui un túnel.

El tractament de qualitat de servei és pitjor que això, perquè depèn de dominis administratius que potser no controleu. Les marques internes s’han de mapar deliberadament a les externes, i cada proveïdor del camí ha d’oferir el tractament que espereu. El xifrat no crea prioritat; amaga el camp que un equip intermedi podria haver fet servir per classificar el flux.

Mesureu la capa inferior abans de prometre res. Un informe que mostra retard estable i cap pèrdua al camí extern és una prova; un diagrama amb un túnel a sobre no ho és.

Trieu el túnel per a la relació de xarxa que necessiteu, i després especifiqueu per separat el xifrat, la política d’accés, la mida dels paquets i el rendiment. Quatre decisions, quatre proves i cap etiqueta única que substitueixi cap d’elles.