Dous saltos de VPN seguidos: quen ve realmente o teu tráfico?

Cada perfil de cliente nomea un servidor, así que desde o asento do usuario hai un túnel e un lugar onde remata a protección. O que ocorre tras esa primeira porta é unha decisión de deseño que o cliente nunca ve, e os dous deseños habituais compórtanse de forma moi distinta baixo inspección. Nunha cadea en serie a primeira porta descifra e volve cifrar. Nunha cadea aniñada quita unha capa exterior e reenvía un túnel interior que non pode abrir. O número de saltos é idéntico en ambos, por iso a diferenza hai que debuxala e non contala.

Empece polo cliente e nomee ambos os extremos

Empece onde empeza o usuario, no perfil de conexión. Contén un enderezo remoto, un método de autenticación e, cando o deseño o admite, unha lista de rutas. Etiquete ese túnel exterior do cliente á porta A e déalle enderezos de exemplo: o enderezo do túnel do cliente 10.77.0.2, o de A 10.77.0.1 e o extremo público de A 198.51.100.10, tomados do rango de documentación TEST-NET-2 para que nada do exemplo poida chocar cun host real.

Nada nese perfil menciona a porta B, e iso non é un defecto. O segundo salto pertence a A, e a única obriga do cliente é entregar o tráfico a A e aceptar o que volve. Se A remata o túnel, o reenvía ou abre un novo é a pregunta que responde o resto deste percorrido, e decide que pode ler A.

En serie: A descifra e logo volve cifrar

No deseño en serie A remata o tráfico dúas veces. Quita a protección ao cliente, obtén o paquete IP da aplicación e logo envía ese paquete por un segundo túnel que A orixina cara a B. Entre esas dúas operacións o paquete está na ruta de reenvío de A como un paquete IP corrente dirixido a un destino privado.

Iso produce dúas consecuencias que convén dicir sen rodeos. A pode aplicar política ao paquete interior, en forma de rutas, regras de filtrado e rexistro de orixe e destino, e A debe manter dous xogos de credenciais: un como servidor para o cliente e outro como cliente de B. A protección existe en cada instante, pero o obxecto protexido cambia de identidade en A.

De aí non se segue que A lea o texto plano da aplicación. Cando o cliente e o servizo usan TLS e verifican os certificados do outro, A ve un fluxo de rexistros TLS en lugar dunha petición lexible. Confirmar onde remata esa protección esixe mirar a cadea de certificados do servizo, non o diagrama do túnel.

Aniñado: A só quita a capa exterior

No deseño aniñado o cliente constrúe primeiro un túnel interior cara a B e logo leva ese túnel dentro do exterior ata A. A quita a cabeceira exterior, atopa un túnel interior e reenvíao sen ter as súas claves, así que a protección interior segue rematando en B.

A ligazón ascendente do cliente leva entón dúas capas, mentres que o camiño entre A e B leva unha. A ve os enderezos exteriores do túnel interior, o que abonda para saber que hai tráfico e aproximadamente cara a onde vai, e non abonda para ler a carga útil. Esa é toda a diferenza co caso en serie, e ningún contador de saltos a mostra. O que A aínda pode facer é negarse a reenviar o que non pode ler, e iso sempre está dispoñible para o operador desa porta.

O aniñamento cobra por esa propiedade. Cada capa engade sobrecarga de cabeceira, así que a planificación de MTU e MSS vólvese obrigatoria e non só ordenada, e un camiño que funciona cunha capa pode descartar en silencio paquetes grandes con dúas. Cada capa necesita ademais o seu propio comportamento de reconexión e de mantemento, e un fallo nunha capa parece unha interrupción parcial a través da outra.

Debuxe os observadores, non só os túneles

Os túneles son a parte fácil do debuxo. Os observadores son o tema do deseño, así que escriba unha fila por punto de vista e encha que pode ler realmente cada un.

Dúas filas confúndense constantemente: o operador de A e o provedor do túnel do cliente. Poden ser unha soa entidade, e nomes de porta separados non os fan independentes. Unha propiedade independente necesita control administrativo separado, credenciais separadas e rexistro separado.

Os metadatos sobreviven a ambos os deseños. O tempo, os tamaños de paquete e os reconto de conexións seguen sendo observables en cada salto, así que dous saltos soben o custo da correlación en lugar de eliminar o sinal. Un deseño que promete invisibilidade debería contrastarse con esa lista antes de que ninguén confíe nel.

Percorra os camiños de fallo antes de escoller

Rolla cousas a propósito desde o cliente, na orde en que un usuario as atoparía. Empece pola interface e o seu MTU, porque o aniñamento falla polo tamaño de paquete moito antes de fallar pola autenticación.

ip -4 addr show dev tun0
ip link show dev tun0 | grep mtu
ping -M do -s 1380 -c 2 10.77.1.1

Logo confirme os extremos de protección en lugar de supoñelos. Pida ao servizo o seu certificado desde dentro do túnel que estea activo, e compare a cadea que ve o cliente coa cadea que o servizo presenta en realidade. Unha porta que refirma ou intercepta cambia ese certificado, e a inspección vólvese visible cun só comando.

openssl s_client -connect intranet.example.com:443 -brief < /dev/null

Remate coa matriz de reconexión: cae o túnel do cliente, cae o túnel de B, cambia o camiño entre A e B. Anote que volve e que non, e se algunha conexión interior cae algunha vez a unha ruta fóra do seu portador previsto. Rexistre os enderezos que usou cada proba, porque repetila noutra rede de acceso responde a outra pregunta. Repita tamén a proba de MTU tras cada reconexión, porque un camiño cambiado pode baixar o tamaño utilizable sen que se mova nin unha liña de configuración.

Escolla en serie cando A deba aplicar política ao paquete interior, ou cando o cliente non poida executar dous túneles apilados. Escolla o aniñamento cando a carga interior deba seguir sendo ilexible en A. Escriba a escolla cos seus observadores e as súas cifras de MTU, e a seguinte persoa non terá que redeseñar todo o cadro para responder unha pregunta.