Molnsäkerhetsgrupp för en VPN: öppna lyssnaren, inte allt

VPN-servern kör, klienten får timeout, och den första impulsen är att lägga till en regel som tillåter allt i säkerhetsgruppen. Det får det ibland att fungera, och det är det sämsta utfallet, för nu vet ingen vilken gräns som faktiskt stängdes. Fyra separata filter står mellan klienten och daemonen, och bara ett av dem är säkerhetsgruppen.

Namnge protokollet före regeln

En regel är ett protokoll, ett portintervall och en källa. WireGuard lyssnar på UDP, vanligtvis 51820. OpenVPN är vanligtvis UDP eller TCP 1194 beroende på konfigurationen. IPsec behöver sitt IKE-utbyte på UDP 500 och 4500 plus själva ESP-protokollet, som är ett protokollnummer och inte en port. Att gissa TCP eftersom de andra reglerna är TCP är hur man får en regel som ser rätt ut och inte matchar något.

Läs lyssnaren från den körande tjänsten, inte från en guide. En daemon bunden till en adress accepterar inte trafik som kommer in på en annan.

Begränsa källan till det klientintervall designen tillåter, i stället för hela internet.

Säkerhetsgrupper är stateful; undernäts-ACL:er är det inte

Säkerhetsgrupper är stateful och bara tillåtande: ett tillåtet inkommande flöde får sina svar automatiskt, och det finns ingen neka-regel att tänka på. Undernäts-ACL:er är tillståndslösa och utvärderas i båda riktningarna, så ett inkommande tillstånd utan det matchande utgående efemära intervallet misslyckas ändå. Den skillnaden förklarar många regler som ser korrekta ut i konsolen.

Bekräfta också vilken policy som är kopplad till den körande ändpunkten, eftersom en instans kan ha mer än en grupp och en regel i en icke-kopplad grupp ändrar ingenting.

Den effektiva policyn är unionen av det som är kopplat, inte filen du redigerade.

Värdens brandvägg är en egen gräns

Molnpolicyn släpper in trafik till nätverksgränssnittet, och sedan avgör operativsystemet om daemonen ser den. En värdbrandvägg med standardpolicy för neka släpper ett paket som säkerhetsgruppen tillät, och molnkonsolen visar ingen nekning eftersom den aldrig hade en åsikt. Kontrollera båda, i den ordning paketet möter dem.

Om värden använder en brandväggsfrontend från distributionen, bekräfta de underliggande reglerna i stället för profilnamnet, eftersom en profil kan vara aktiv medan porten är stängd.

En inspelning på gränssnittet säger vilken gräns som släppte paketet.

Att tillåta lyssnaren är inte att routa klienterna

En VPN-gateway som vidarebefordrar klienttrafik behöver mer än en öppen port. Den behöver IP-vidarebefordran, en policy som tillåter flödet från tunnelgränssnittet till målnätverket och ofta en källa-destination-kontroll som är avstängd på gränssnittet så att plattformen inte kastar trafik som inte är adresserad till den. Inget av detta skapas av lyssnarregeln.

Här skiljs en fungerande handskakning och en trasig dataväg, och därför kan en tunnelstatus se frisk ut medan ingenting laddas.

Åtgärda routningen som en separat ändring med egen verifiering, och notera att en vidarebefordrande gateway också behöver en utgångspolicy som tillåter målet.

Behåll en väg tillbaka och snäva sedan in regeln

Innan du ändrar brandväggspolicyn på distans, bekräfta att det finns en oberoende administrationsväg, som en sessionshanterare, en seriell konsol eller ett nätverk utanför bandet. Om den enda administrationsvägen går genom regeln du redigerar har du ingen återställning. Använd sedan den smala regeln, testa från en riktig klient och korrelera försöket med bevis på serversidan. Ett svar från en annan tjänst på samma maskin är inte bevis för att lyssnaren nåddes.

Ta bort varje experimentell bred tillåtelse så snart den smala fungerar, och notera varför regeln finns. AWS dokumenterar säkerhetsgruppers stateful beteende, och det dokumentet är det man ska citera när någon föreslår ett brett intervall som genväg.

Dokumentera även kopplingen, annars tappar ett ersättningsgränssnitt policyn tyst.