VPN-klienttrafik och brandväggstillstånd: yttre och inre flöde

VPN-handskakningen slutförs, klienten får en adress, och en tjänst bakom gatewayen nekar fortfarande anslutningen. Brandväggen gör ofta precis det den blev tillsagd. Den tillät det yttre tunnelflödet, som är ett annat paket än den avkapslade applikationsanslutningen. Två beslut följer: vilket flöde du tillåter, och om gränsen över huvud taget följer tillstånd.

Tills du skiljer de två åt är varje regeländring en gissning.

Brandväggen ser två olika paket

Före avkapslingen ser brandväggen trafik adresserad till VPN-slutpunkten: ett yttre UDP-flöde till lyssnaren. Efter avkapslingen bär ett vidarebefordrat paket klientens inre adress och tjänstens mål.

Ett tillstånd för det yttre flödet auktoriserar inte den vidarebefordrade TCP-anslutningen. De kan utvärderas i olika kedjor, mot olika gränssnitt och med olika adresser efter översättning.

Jämför fångster från likvärdiga positioner på båda sidor. En fångst vid tunnelkanten och en fångst på servern visar olika tupler för samma session.

Första beslutet: tillåta tunneln eller tjänsten

Om klienten bara behöver själva VPN-slutpunkten kan det yttre tillståndet räcka. Om den behöver en tjänst bortom gatewayen behövs ett vidarebefordringstillstånd för det målet och den porten. En tunnelregel som också tillåter tjänsten är ett designval du bör namnge, inte en olycka.

Håll klientområdet och tjänstens omfattning smala. Ett tillstånd från tunnelsubnätet till hela LANet är ett beslut att lita på varje värd, inte en genväg för en enda applikation.

Skriv ned båda reglerna separat. Tunnelregeln och tjänsteregeln misslyckas på olika sätt och felsöks med olika bevis. När en misslyckas vet du vilket lager du ska undersöka först.

Andra beslutet: med eller utan tillstånd vid varje gräns

En regel för etablerat flöde kan släppa igenom svar för ett tillåtet utbyte, men beteendet beror på produkten. En molnsäkerhetsgrupp följer vanligtvis tillstånd; en subnät-ACL gör det ofta inte och kräver uttrycklig hantering i båda riktningarna. Anta inte att varje gräns på vägen behandlar tillstånd likadant. Lista varje gräns och markera den med eller utan tillståndsbevakning innan du designar reglerna.

Om en regel ändras kan befintliga spårade flöden fortsätta att fungera medan nya misslyckas, eller tvärtom. Den skillnaden är en användbar ledtråd, inte en anledning att tömma all anslutningstillstånd på en aktiv gateway.

Testa med en färsk kontrollerad begäran och inspektera de relevanta räknarna. Ett rent test slår en störande återställning. Notera räknarens namn i ändringsloggen så att nästa test använder samma bevis.

Verifiera returvägen under samma policy

Skicka en ny begäran från klienten till tjänsten och kontrollera sedan fram- och returräknarna vid varje gräns. Bekräfta att svaret använder den väg du förväntar dig, särskilt om översättning är inblandad.

Håll det avsedda klientområdet och tjänstens omfattning smala och verifiera returvägen under samma regeluppsättning som tillät begäran. En regel som bara fungerar för att ett gammalt flöde fortfarande är öppet är ingen fungerande regel.