VPN-clientverkeer en firewallstatus: buitenste versus binnenste stroom

De VPN-handshake rondt af, de client krijgt een adres, en een dienst achter de gateway weigert de verbinding nog steeds. De firewall doet vaak precies wat hem is opgedragen. Hij stond de buitenste tunnelstroom toe, en dat is een ander pakket dan de gedecapsuleerde applicatieverbinding. Daaruit volgen twee beslissingen: welke stroom u toestaat, en of de grens überhaupt status bijhoudt.

Tot u die twee scheidt, is elke regelwijziging een gok.

De firewall ziet twee verschillende pakketten

Vóór decapsulatie ziet de firewall verkeer dat aan het VPN-eindpunt is geadresseerd: een buitenste UDP-stroom naar de listener. Na decapsulatie draagt een doorgestuurd pakket het binnenste adres van de client en de bestemming van de dienst.

Een toestemming voor de buitenste stroom machtigt de doorgestuurde TCP-verbinding niet. Ze kunnen in verschillende chains, tegen verschillende interfaces en met verschillende adressen na vertaling worden geëvalueerd.

Vergelijk opnames vanaf gelijkwaardige posities aan beide zijden. Een opname aan de tunnelrand en een opname op de server tonen verschillende tuples voor dezelfde sessie.

Eerste beslissing: de tunnel of de dienst toestaan

Als de client alleen het VPN-eindpunt zelf nodig heeft, kan de buitenste toestemming genoeg zijn. Heeft hij een dienst achter de gateway nodig, dan hebt u een doorvoertoestemming voor die bestemming en poort nodig. Een tunnelregel die ook de dienst toestaat, is een ontwerpkeuze die u zou moeten benoemen, geen ongeluk.

Houd het clientbereik en de reikwijdte van de dienst smal. Een toestemming van het tunnelsubnet naar het hele LAN is een beslissing om elke host te vertrouwen, geen snelkoppeling voor één applicatie.

Schrijf beide regels apart op. De tunnelregel en de dienstregel falen op verschillende manieren en worden met verschillend bewijs gedebugd. Als er één faalt, weet u welke laag u eerst moet onderzoeken.

Tweede beslissing: met of zonder status bij elke grens

Een regel voor gevestigde stromen kan antwoorden voor een toegestane uitwisseling doorlaten, maar het gedrag hangt van het product af. Een cloudbeveiligingsgroep houdt meestal status bij; een subnet-ACL doet dat vaak niet en vereist expliciete afhandeling in beide richtingen. Ga er niet van uit dat elke grens op het pad status hetzelfde behandelt. Lijst elke grens op en markeer die met of zonder status voordat u de regels ontwerpt.

Als een regel verandert, kunnen bestaande gevolgde stromen blijven werken terwijl nieuwe falen, of andersom. Dat verschil is een nuttige aanwijzing, geen reden om alle verbindingsstatus op een live gateway te wissen.

Test met een verse gecontroleerde aanvraag en inspecteer de relevante tellers. Een schone test verslaat een verstorende reset. Noteer de naam van de teller in het wijzigingslogboek, zodat de volgende test hetzelfde bewijs gebruikt.

Verifieer het retourpad onder hetzelfde beleid

Stuur een nieuwe aanvraag van de client naar de dienst en controleer daarna de heen- en terugtellers bij elke grens. Bevestig dat het antwoord het pad gebruikt dat u verwacht, vooral als er vertaling in het spel is.

Houd het bedoelde clientbereik en de reikwijdte van de dienst smal, en verifieer het retourpad onder dezelfde regelset die de aanvraag toestond. Een regel die alleen werkt omdat een oude stroom nog open is, is geen werkende regel.