VPN-klienttrafik og firewalltilstand: ydre kontra indre flow

VPN-håndtrykket fuldføres, klienten får en adresse, og en tjeneste bag gatewayen afviser stadig forbindelsen. Firewallen gør ofte præcis, hvad den har fået besked på. Den tillod det ydre tunnelflow, som er en anden pakke end den dekapsulerede applikationsforbindelse. To beslutninger følger: hvilket flow du tillader, og om grænsen overhovedet følger tilstand.

Indtil du adskiller de to, er enhver regelændring et gæt.

Firewallen ser to forskellige pakker

Før dekapsuleringen ser firewallen trafik adresseret til VPN-endepunktet: et ydre UDP-flow til lytteren. Efter dekapsuleringen bærer en videresendt pakke klientens indre adresse og tjenestens destination.

En tilladelse til det ydre flow autoriserer ikke den videresendte TCP-forbindelse. De kan evalueres i forskellige kæder, mod forskellige grænseflader og med forskellige adresser efter oversættelse.

Sammenlign optagelser fra tilsvarende positioner på begge sider. En optagelse ved tunnelkanten og en optagelse på serveren viser forskellige tupler for samme session.

Første beslutning: tillad tunnelen eller tjenesten

Hvis klienten kun har brug for selve VPN-endepunktet, kan den ydre tilladelse være nok. Hvis den har brug for en tjeneste bag gatewayen, skal du have en videresendelsestilladelse til den destination og port. En tunnelregel, der også tillader tjenesten, er et designvalg, du bør navngive, ikke et uheld.

Hold klientområdet og tjenestens omfang snævert. En tilladelse fra tunnelsubnettet til hele LAN’et er en beslutning om at stole på hver vært, ikke en genvej til én applikation.

Skriv begge regler ned hver for sig. Tunnelreglen og tjenestereglen fejler på forskellige måder og fejlfindes med forskellige beviser. Når den ene fejler, ved du, hvilket lag du skal undersøge først.

Anden beslutning: tilstand eller uden tilstand ved hver grænse

En regel for etableret flow kan tillade svar for en tilladt udveksling, men dens adfærd afhænger af produktet. En cloud-sikkerhedsgruppe følger normalt tilstand; en subnets ACL følger ofte ikke tilstand og kræver eksplicit håndtering i begge retninger. Antag ikke, at hver grænse på vejen behandler tilstand ens. List hver grænse og markér den med eller uden tilstand, før du designer reglerne.

Hvis en regel ændres, kan eksisterende sporede flows fortsætte med at virke, mens nye fejler, eller omvendt. Den forskel er et nyttigt fingerpeg, ikke en grund til at skylle al forbindelsestilstand på en aktiv gateway.

Test med en frisk kontrolleret anmodning, og undersøg de relevante tællere. En ren test slår en forstyrrende nulstilling. Notér tællerens navn i ændringsloggen, så den næste test bruger samme bevis.

Bekræft returvejen under samme politik

Send en ny anmodning fra klienten til tjenesten, og kontrollér derefter videresendelses- og returtællerne ved hver grænse. Bekræft, at svaret bruger den vej, du forventer, især hvis der er oversættelse involveret.

Hold det tilsigtede klientområde og tjenestens omfang snævert, og bekræft returvejen under det samme regelsæt, som tillod anmodningen. En regel, der kun virker, fordi et gammelt flow stadig er åbent, er ikke en fungerende regel.