VPN de sitio a sitio: que dirección necesita realmente unha regra?

Ambos extremos informan dun túnel establecido, a sucursal remota responde desde a pasarela e a aplicación segue esgotando o tempo para os usuarios dun lado. O consello habitual di que hai que engadir unha regra de devasa en ambas direccións. Ás veces é correcto, ás veces duplica unha regra que xa existe e ás veces a segunda regra é a que rompe o estado. Que caso se aplica depende de onde vexa o paquete a devasa.

O tráfico de retorno con estado cambia a conta

Unha devasa con estado rexistra a solicitude e admite a resposta sen unha segunda regra, así que un deseño que só necesita unha regra é normal. Unha lista de acceso sen estado non ten esa memoria, e a resposta debe permitirse explicitamente. Ambos son correctos na súa propia plataforma, e por iso os consellos se contradín.

Lea a documentación de reenvío da plataforma que ten diante e comprobe se a política que está editando ten estado onde ve o paquete. Unha denegación explícita para o tráfico establecido, ou unha orde de regras que avalía a resposta antes da táboa de estados, converte un deseño funcional nun desconcertante. O número de regras é un detalle de implementación, mentres que o requisito é que ambas direccións dunha conversa permitida poidan completarse.

Onde ve a devasa os paquetes descifrados

Nun túnel baseado en políticas, a devasa pode avaliar o paquete cifrado antes do descifrado e o paquete descifrado despois, en interfaces diferentes. Unha regra escrita para a interface equivocada está presente, é correcta e nunca coincide. Así é como un conxunto de regras copiado dun despregamento funcional pode fallar en hardware idéntico.

O IPsec baseado en rutas e a maioría das implementacións modernas presentan unha interface de túnel, de modo que o paquete descifrado chega alí e aplícanse as regras de interface habituais. Confirme que modelo usa o despregamento antes de copiar un conxunto de regras dunha guía escrita para o outro. A interface de túnel tamén é o lugar onde mirar cando necesita saber se un paquete se descifrou sequera.

O encamiñamento asimétrico rompe a suposición

Unha devasa con estado supón que ve ambas metades da conversa. Se a resposta volve por outra pasarela, ese dispositivo non mantén estado para a solicitude e descártaa segundo a súa propia política. O síntoma é un fallo unidireccional que ningunha regra do lado emisor pode reparar. Siga a ruta da resposta antes de editar nada.

Comprobe a ruta da resposta antes de engadir unha regra ampla de permiso en ambos lados. Tolerar todo en cada interface oculta o erro de encamiñamento e amplía o acceso ao mesmo tempo, que é a peor combinación dispoñible.

Comprobe ambas direccións con enderezos de orixe reais

Probe co enderezo que o lado remoto observa realmente, xa que a tradución pode facer que unha regra de orixe non coincida con nada. Execute a captura en ambas pasarelas ao mesmo tempo.

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

Unha solicitude que aparece na pasarela remota cun enderezo de orixe inesperado explica unha regra que nunca coincide, e unha resposta que chega á interface equivocada explica un desaxuste de estado. Despois probe un destino dentro do alcance aprobado e outro fóra, para que o límite se demostre en lugar de supoñerse.

Rexiste o enderezo de orixe despois da tradución, a interface que utilizou o paquete descifrado e a regra que coincidiu. Eses tres feitos responden ao seguinte tícket sen repetir toda a investigación.