VPN-klienttrafikk og brannmurstatus: ytre og indre flyt

VPN-håndtrykket fullføres, klienten får en adresse, og en tjeneste bak gatewayen avviser fortsatt forbindelsen. Brannmuren gjør ofte nøyaktig det den har fått beskjed om. Den tillot den ytre tunnelstrømmen, som er en annen pakke enn den avkapslede applikasjonsforbindelsen. To beslutninger følger: hvilken strøm du tillater, og om grensen i det hele tatt følger tilstand.

Til du skiller de to, er enhver regelendring en gjetning.

Brannmuren ser to forskjellige pakker

Før avkapsling ser brannmuren trafikk adressert til VPN-endepunktet: en ytre UDP-strøm til lytteren. Etter avkapsling bærer en videresendt pakke klientens indre adresse og tjenestens mål.

En tillatelse for den ytre strømmen autoriserer ikke den videresendte TCP-forbindelsen. De kan vurderes i forskjellige kjeder, mot forskjellige grensesnitt og med forskjellige adresser etter oversettelse.

Sammenlign opptak fra tilsvarende posisjoner på begge sider. Et opptak ved tunnelkanten og et opptak på serveren viser forskjellige tupler for samme økt.

Første beslutning: tillate tunnelen eller tjenesten

Hvis klienten bare trenger selve VPN-endepunktet, kan den ytre tillatelsen være nok. Hvis den trenger en tjeneste bak gatewayen, trenger du en videresendingstillatelse for det målet og den porten. En tunnelregel som også tillater tjenesten, er et designvalg du bør navngi, ikke et uhell.

Hold klientområdet og tjenestens omfang smalt. En tillatelse fra tunnelsubnettet til hele LAN-et er en beslutning om å stole på hver vert, ikke en snarvei for én applikasjon.

Skriv begge reglene ned hver for seg. Tunnelregelen og tjenesteregelen feiler på forskjellige måter og feilsøkes med forskjellige bevis. Når den ene feiler, vet du hvilket lag du skal undersøke først.

Andre beslutning: med eller uten tilstand ved hver grense

En regel for etablert flyt kan slippe gjennom svar for en tillatt utveksling, men oppførselen avhenger av produktet. En skybasert sikkerhetsgruppe følger vanligvis tilstand; en subnett-ACL følger ofte ikke tilstand og krever eksplisitt håndtering i begge retninger. Ikke anta at hver grense på veien behandler tilstand likt. List opp hver grense og merk den med eller uten tilstand før du designer reglene.

Hvis en regel endres, kan eksisterende sporede strømmer fortsette å virke mens nye feiler, eller omvendt. Den forskjellen er et nyttig spor, ikke en grunn til å tømme all tilkoblingstilstand på en aktiv gateway.

Test med en fersk kontrollert forespørsel og inspiser de relevante tellerne. En ren test slår en forstyrrende tilbakestilling. Noter tellerens navn i endringsloggen slik at neste test bruker samme bevis.

Bekreft returveien under samme policy

Send en ny forespørsel fra klienten til tjenesten, og kontroller deretter frem- og returtellerne ved hver grense. Bekreft at svaret bruker veien du forventer, spesielt hvis oversettelse er involvert.

Hold det tiltenkte klientområdet og tjenestens omfang smalt, og bekreft returveien under det samme regelsettet som tillot forespørselen. En regel som bare virker fordi en gammel strøm fortsatt er åpen, er ikke en fungerende regel.