Que rexistrar para unha VPN de sitio a sitio: selectores e alcance
Un rexistro de selectores debe dicir que ve cada extremo. Os prefixos configurados, as asociacións negociadas, a tradución e a propiedade do servizo pertencen todos a el.
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.