Site-naar-site-VPN: welke richting heeft echt een regel nodig?

Beide uiteinden melden een opgezette tunnel, de externe vestiging antwoordt vanaf de gateway, en de applicatie loopt voor gebruikers aan één kant nog steeds in een time-out. Het gebruikelijke advies is om in beide richtingen een firewallregel toe te voegen. Soms is dat juist, soms dupliceert het een regel die al bestaat, en soms is het de tweede regel die de status breekt. Welk geval geldt, hangt af van waar de firewall het pakket ziet.

Stateful terugverkeer verandert het aantal

Een stateful firewall registreert het verzoek en laat het antwoord door zonder tweede regel, dus een ontwerp dat maar één regel nodig heeft is normaal. Een stateless toegangslijst heeft zo'n geheugen niet, en het antwoord moet expliciet worden toegestaan. Beide zijn correct op hun eigen platform, en daarom spreken de adviezen elkaar tegen.

Lees de doorstuurdocumentatie voor het platform voor u, en controleer of het beleid dat u bewerkt stateful is waar het het pakket ziet. Een expliciete weigering voor gevestigd verkeer, of een regelvolgorde die het antwoord vóór de statustabel evalueert, maakt een werkend ontwerp raadselachtig. Het aantal regels is een implementatiedetail, terwijl de eis is dat beide richtingen van een toegestaan gesprek kunnen worden voltooid.

Waar de firewall ontsleutelde pakketten ziet

In een op beleid gebaseerde tunnel kan de firewall het versleutelde pakket vóór ontsleuteling en het ontsleutelde pakket erna evalueren, op verschillende interfaces. Een regel die voor de verkeerde interface is geschreven, is aanwezig, correct en wordt nooit geraakt. Zo kan een regelset die uit een werkende implementatie is gekopieerd op identieke hardware falen.

Op routes gebaseerd IPsec en de meeste moderne implementaties bieden een tunnelinterface, zodat het ontsleutelde pakket daar aankomt en gewone interfaceregels gelden. Bevestig welk model de implementatie gebruikt voordat u een regelset kopieert uit een handleiding die voor het andere is geschreven. De tunnelinterface is ook de plek om te kijken wanneer u wilt weten of een pakket überhaupt is ontsleuteld.

Asymmetrische routering breekt de aanname

Een stateful firewall gaat ervan uit dat hij beide helften van het gesprek ziet. Als het antwoord via een andere gateway terugkomt, heeft dat apparaat geen status voor het verzoek en laat het vallen volgens zijn eigen beleid. Het symptoom is een eenrichtingsfout die geen regel aan de zendende kant kan repareren. Volg het pad van het antwoord voordat u iets bewerkt.

Controleer de route van het antwoord voordat u aan beide kanten een brede toestemmingsregel toevoegt. Alles op elke interface tolereren verbergt de routeringsfout en verruimt tegelijk de toegang, wat de slechtste combinatie is die beschikbaar is.

Controleer beide richtingen met echte bronadressen

Test met het adres dat de externe kant daadwerkelijk ziet, want vertaling kan ervoor zorgen dat een bronregel nergens op past. Voer de opname op beide gateways tegelijk uit.

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

Een verzoek dat op de externe gateway met een onverwacht bronadres verschijnt, verklaart een regel die nooit past, en een antwoord dat op de verkeerde interface aankomt, verklaart een statusafwijking. Test daarna één bestemming binnen het goedgekeurde bereik en één erbuiten, zodat de grens wordt gedemonstreerd in plaats van aangenomen.

Noteer het bronadres na vertaling, de interface die het ontsleutelde pakket gebruikte, en de regel die overeenkwam. Die drie feiten beantwoorden het volgende ticket zonder het hele onderzoek te herhalen.