Tráfico do cliente VPN e estado da devasa: fluxo exterior fronte ao interior

O salto de man VPN complétase, o cliente obtén un enderezo e un servizo detrás da pasarela segue rexeitando a conexión. A devasa adoita facer exactamente o que se lle dixo. Permitiu o fluxo exterior do túnel, que é un paquete distinto da conexión de aplicación desencapsulada. Seguen dúas decisións: que fluxo permite e se a fronteira segue o estado.

Ata que separe esas dúas cousas, cada cambio de regra é unha conxectura.

A devasa ve dous paquetes distintos

Antes da desencapsulación, a devasa ve tráfico dirixido ao extremo VPN: un fluxo UDP exterior cara ao escoitador. Despois da desencapsulación, un paquete reenviado leva o enderezo interior do cliente e o destino do servizo.

Un permiso para o fluxo exterior non autoriza a conexión TCP reenviada. Pódense avaliar en cadeas distintas, contra interfaces distintas e con enderezos distintos tras a tradución.

Compare capturas desde posicións equivalentes nos dous lados. Unha captura no bordo do túnel e unha captura no servidor mostran tuplas distintas para a mesma sesión.

Primeira decisión: permitir o túnel ou o servizo

Se o cliente só precisa o extremo VPN en si, o permiso exterior pode abondar. Se necesita un servizo máis alá da pasarela, cómpre un permiso de reenvío para ese destino e porto. Unha regra de túnel que tamén permite o servizo é unha decisión de deseño que debería nomear, non un accidente.

Manteña estreitos o rango do cliente e o alcance do servizo. Un permiso da subrede do túnel a toda a LAN é unha decisión de confiar en cada equipo, non un atallo para unha aplicación.

Escriba as dúas regras por separado. A regra do túnel e a regra do servizo fallan de maneiras distintas e depúranse con probas distintas. Cando unha falla, sabe que capa inspeccionar primeiro.

Segunda decisión: con estado ou sen estado en cada fronteira

Unha regra de fluxo establecido pode admitir respostas para un intercambio permitido, pero o seu comportamento depende do produto. Un grupo de seguridade na nube adoita ter estado; unha lista de control de subrede a miúdo non o ten e necesita un tratamento explícito en ambos os sentidos. Non supoña que cada fronteira do camiño trata o estado igual. Enumere cada fronteira e márquea con estado ou sen estado antes de deseñar as regras.

Se cambia unha regra, os fluxos rastrexados existentes poden seguir funcionando mentres os novos fallan, ou ao revés. Esa diferenza é unha pista útil, non unha razón para baleirar todo o estado de conexión nunha pasarela en produción.

Probe cunha petición nova e controlada e inspeccione os contadores relevantes. Unha proba limpa supera un reinicio perturbador. Anote o nome do contador no rexistro do cambio para que a seguinte proba use a mesma evidencia.

Verifique o camiño de volta coa mesma política

Enhvíe unha petición nova do cliente ao servizo e despois revise os contadores de ida e de volta en cada fronteira. Confirme que a resposta usa o camiño que espera, sobre todo se hai tradución polo medio.

Manteña estreitos o rango de cliente previsto e o alcance do servizo, e verifique o camiño de volta co mesmo conxunto de regras que permitiu a petición. Unha regra que só funciona porque un fluxo antigo segue aberto non é unha regra que funcione.