O NAT de orixe oculta os enderezos dos clientes a un firewall posterior

Unha regra escrita para clientes de persoal e de laboratorio colócase no novo firewall de bordo, e coincide en silencio con todo ou con nada. A razón está máis arriba: unha pasarela xa reescribiu os enderezos dos clientes, así que a regra ve un só enderezo de tránsito en lugar de dous grupos. Engadir un aparello non restaura a información que o camiño eliminou. Atopade o último punto onde a distinción aínda existe antes de escribir a política.

Por que a regra de bordo ve un só enderezo

A tradución de moitos a un asigna cada par interno de enderezo e porto a un enderezo externo compartido cun porto asignado. As conversas seguen sendo distinguibles para o tradutor grazas a esas vinculacións de porto, pero un dispositivo posterior que fai unha simple coincidencia de prefixo de orixe só ve o enderezo compartido. Iso abonda para que dous grupos sexan idénticos na regra. Os paquetes seguen chegando; a agrupación non.

Comprobade que observa realmente a interface do firewall, non o que promete o diagrama. Ambos difiren máis a miúdo do que ninguén espera.

Atopade a última identidade aplicable

Comezade no punto de aplicación e retrocede até que apareza o prefixo orixinal. Dous comandos adoitan localizar a fronteira.

iptables -t nat -L POSTROUTING -n -v
conntrack -L -s 10.90.0.2 | head

A táboa NAT mostra que tráfico se traduce e mediante que regra, mentres que a listaxe de conntrack mostra as tuplas orixinais e traducidas dos fluxos activos. Onde o firewall anterior só ve o enderezo traducido, as regras de orixe por grupo non poden funcionar alí, por moi ben escritas que estean. Avanzade ou retrocede polo camiño até chegar a un dispositivo no que os dous prefixos de cliente sigan sendo distintos. Anotade a orixe en cada salto en lugar de confiar nunha etiqueta de dentro ou de fóra.

Tres ubicacións e o que custa cada unha

A política pode vivir na pasarela que traduce, onde as orixes orixinais aínda son visibles. Pode vivir no firewall anterior se o tránsito pasa a ser encamiñado en lugar de traducido, o que significa engadir rutas de retorno e eliminar a reescritura de orixe. Ou pode aplicarse sobre a identidade en lugar dos enderezos, mediante un control autenticado que coñece o usuario ou o dispositivo. Cada elección ten un propietario e un modo de fallo, e só as dúas primeiras manteñen a regra puramente sobre enderezos de orixe.

Escollades o que escollades, documentade a regra xunto co enderezo ao que corresponde. Unha regra cuxa suposición de enderezo cambiou en silencio é peor que ningunha regra, porque segue coincidindo co tráfico mentres protexe algo completamente distinto.

Aceptación: un cliente permitido e outro denegado

Probade cun par de clientes, un de cada grupo, e capturade como chega cada un ao punto de aplicación. Conservade as dúas tuplas xunto ao resultado da regra, para que a evidencia mostre que a distinción sobreviviu e non que existe outro firewall. Repetide a proba tras un cambio de NAT ou de encamiñamento, porque o enderezo presentado é a parte que se rompe en silencio. Mantede a autenticación onde haxa que distinguir persoas, xa que un enderezo de orixe é unha entrada de política, non unha proba de identidade.

Escribide o punto de aplicación, a orixe observada e a regra no ticket. Se non, o seguinte enxeñeiro engade un segundo firewall e a mesma regra.