Seis meses despois de poñer en marcha un túnel, unha subrede nova deixa de coincidir coa política e o único documento compartido di VPN de oficina. Ese é o fallo que evita un rexistro de selectores, e é concreto: un conxunto de enderezos cambiou mentres o papeleo non. Escribir ben o rexistro significa saber cal de varios conxuntos de enderezos está describindo, e anotar o que o extremo oposto aplica de verdade en lugar do que configurou.

Configurado non é negociado

Nun túnel IPsec baseado en políticas, cada lado propón selectores de tráfico: rangos de orixe e destino para a asociación filla. O lado que responde pode estreitar esa proposta , así que a asociación instalada pode cubrir menos do que enumera a configuración. Un rexistro que copia a configuración describe, por tanto, unha intención, non o alcance de protección actual. Os dous diverxen en silencio, e nada na páxina de estado do túnel o sinala.

Conserve ambas as columnas, coa data en que as observou. O selector configurado é o que vostede quería; o negociado é o que o núcleo aplica agora mesmo. Cando difiren, esa diferenza explica un fallo sorprendente moito máis a miúdo que un erro de encamiñamento.

Unha asociación tampouco representa todos os pares configurados. Un túnel con varias combinacións de selectores pode acabar con varias asociacións fillas, e un rexistro que enumera unha delas é un inventario parcial. Enuméreas en lugar de resumilas.

Os túneles baseados en rutas seleccionan doutro xeito

Cunha interface baseada en rutas, a táboa de encamiñamento decide que entra no túnel e os selectores poden ser deliberadamente amplos. É un deseño lexítimo e non un descoido, e o rexistro debe describilo como tal. Anote a ruta, a interface á que apunta e a política de devasa que limita que servizos son alcanzables. O alcance de protección é amplo a propósito, e o alcance do servizo fai o estreitamento.

Copiar un modelo baseado en políticas nun túnel baseado en rutas produce un documento que describe un mecanismo que o despregamento non usa. O seguinte enxeñeiro busca entón selectores que nunca deberon estar aí, e conclúe que o túnel está mal configurado cando só está mal documentado.

A tradución pertence á mesma táboa

Cando o NAT presenta un rango distinto ao extremo oposto, rexistre os prefixos orixinais e traducidos xuntos. Anote a etapa na que os selectores e as regras de acceso coinciden con eles, porque a orde decide se o lado remoto chega a ver o enderezo que vostede anotou. Unha táboa con só un dos dous rangos é peor que ningunha táboa, porque parece completa.

Este é o detalle que rompe un túnel que funcionaba tras un cambio de NAT: o selector segue coincidindo co prefixo orixinal, o extremo oposto recibe agora un traducido, e a súa ruta de retorno apunta a un enderezo que xa non existe. Nada rexistra un erro no momento en que os dous deixan de coincidir.

O DNS privado pertence ao mesmo sitio. Un nome que resolve a un enderezo inutilizable desde o sitio correspondente é un erro de documentación cun tique de soporte adxunto, e culparase o túnel.

Anexe o requisito de servizo

Un rango protexido non é unha lista de permisos. Anote que servizos deben ser alcanzables desde que orixe, e quen é o propietario da aplicación que hai detrás. Esos dous campos responden a preguntas distintas, e confundilos é como unha revisión de seguridade acaba discutindo de encamiñamento en lugar de acceso.

Despois nomee o administrador de rede que mantén a regra. Un inventario de selectores sen propietario queda obsoleto en silencio, e o obsoleto non se distingue do incorrecto cando o túnel rompe ás dúas da madrugada. O propietario tamén é a persoa que pode confirmar que un cambio foi deliberado.

Converta o rexistro nun plan de probas

Para cada ruta necesaria, escolla un host de orixe e outro de destino representativos e anote a ruta, o servizo e a devasa de resposta esperados. Iso converte o documento nun plan de probas en lugar dunha descrición. Lea a asociación viva co comando de abaixo, e compárea coa fila negociada que anotou.

swanctl --list-sas

Un esqueleto de cinco liñas adoita abondar para manter o rexistro honesto. A versión de abaixo cabe nun tique de cambio sen recortes:

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

Un ping só á devasa non é a proba de aceptación. Nunca exercita a ruta de tránsito, así que pode pasar mentres todos os fluxos reenviados fallan. Probe desde un host dun lado a un servizo do outro e confirme que a resposta chega polo túnel. Se só pasa o ping, o rexistro acaba de atopar o problema de reenvío que debía previr. documentación de reenvío de strongSwan explica como interactúan os selectores, as rutas e o reenvío nun extremo Linux.

Artigos relacionados