Käll-NAT döljer klientadresserna för en senare brandvägg

En regel skriven för personal- och labbklienter läggs på den nya kantbrandväggen, och den matchar tyst allt eller inget. Orsaken ligger längre upp: en gateway har redan skrivit om klientadresserna, så regeln ser en enda transitadress i stället för två grupper. Att lägga till en enhet återställer inte informationen som vägen tog bort. Hitta den sista punkten där skillnaden fortfarande finns innan du skriver policyn.

Varför kantregeln ser en enda adress

Många-till-ett-översättning mappar varje internt adress- och portpar till en delad extern adress med en tilldelad port. Samtalen förblir urskiljbara för översättaren genom dessa portbindningar, men en enhet längre ned som gör en enkel källprefixmatchning ser bara den delade adressen. Det räcker för att göra två grupper identiska vid regeln. Paketen kommer fortfarande fram; grupperingen inte.

Kontrollera vad brandväggens gränssnitt faktiskt observerar, inte vad diagrammet lovar. De två skiljer sig oftare än någon förväntar sig.

Hitta den sista genomdrivbara identiteten

Börja vid genomdrivningspunkten och gå bakåt tills det ursprungliga prefixet dyker upp. Två kommandon hittar oftast gränsen.

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

NAT-tabellen visar vilken trafik som översätts och av vilken regel, medan conntrack-listan visar ursprungliga och översatta par för aktiva flöden. Där brandväggen längre upp bara ser den översatta adressen kan källbaserade regler per grupp inte fungera, hur de än är skrivna. Gå framåt eller bakåt längs vägen tills du når en enhet där de två klientprefixen förblir olika. Notera källan vid varje hopp i stället för att lita på en inre eller yttre etikett.

Tre placeringar och vad varje kostar

Policyn kan ligga på gatewayen som översätter, där de ursprungliga källorna fortfarande syns. Den kan ligga på brandväggen längre upp om transiten blir routad i stället för översatt, vilket innebär att lägga till returvägar och ta bort källomskrivningen. Eller så kan den genomdrivas på identitet i stället för adresser, via en autentiserad kontroll som känner användaren eller enheten. Varje val har en ägare och ett felläge, och bara de två första håller regeln rent om källadresser.

Vilket du än väljer, dokumentera regeln tillsammans med adressen den matchar. En regel vars adressantagande tyst har ändrats är värre än ingen regel, eftersom den fortsätter att matcha trafik medan den skyddar något helt annat.

Acceptans: en tillåten och en nekad klient

Testa med ett klientpar, en från varje grupp, och registrera hur var och en anländer till genomdrivningspunkten. Behåll båda paren bredvid regelresultatet, så att beviset visar att skillnaden överlevde och inte att det finns en annan brandvägg. Upprepa testet efter en NAT- eller routingändring, eftersom den presenterade adressen är den del som tyst går sönder. Behåll autentisering där människor måste särskiljas, eftersom en källadress är en policyindata, inte ett identitetsbevis.

Skriv genomdrivningspunkten, den observerade källan och regeln i ärendet. Annars lägger nästa ingenjör till en andra brandvägg och samma regel.