Skysikkerhetsgruppe for en VPN: åpne lytteren, ikke alt

VPN-serveren kjører, klienten får tidsavbrudd, og den første impulsen er å legge til en regel som tillater alt i sikkerhetsgruppen. Det får det noen ganger til å virke, og det er det verste utfallet, for nå vet ingen hvilken grense som faktisk ble lukket. Fire separate filtre står mellom klienten og daemonen, og bare ett av dem er sikkerhetsgruppen.

Navngi protokollen før regelen

En regel er en protokoll, et portområde og en kilde. WireGuard lytter på UDP, vanligvis 51820. OpenVPN er vanligvis UDP eller TCP 1194 avhengig av konfigurasjonen. IPsec trenger IKE-utvekslingen på UDP 500 og 4500 pluss selve ESP-protokollen, som er et protokollnummer og ikke en port. Å gjette TCP fordi de andre reglene er TCP er hvordan man ender med en regel som ser riktig ut og ikke treffer noe.

Les lytteren fra den kjørende tjenesten, ikke fra en veiledning. En daemon bundet til én adresse godtar ikke trafikk som kommer inn på en annen.

Begrens kilden til klientområdet designet tillater, i stedet for hele internett.

Sikkerhetsgrupper er tilstandsfulle; subnett-ACL-er er det ikke

Sikkerhetsgrupper er tilstandsfulle og bare tillatende: en tillatt inngående flyt får svarene sine automatisk, og det finnes ingen avvisningsregel å tenke på. Subnett-ACL-er er tilstandsløse og vurderes i begge retninger, så en inngående tillatelse uten det matchende utgående efemere området feiler fortsatt. Den forskjellen forklarer mange regler som ser riktige ut i konsollen.

Bekreft også hvilken policy som er knyttet til det kjørende endepunktet, siden en instans kan ha mer enn én gruppe, og en regel i en ikke-tilknyttet gruppe endrer ingenting.

Den effektive policyen er foreningen av det som er tilknyttet, ikke filen du redigerte.

Vertens brannmur er en egen grense

Skypolicyen slipper trafikk til nettverksgrensesnittet, og deretter avgjør operativsystemet om daemonen ser den. En vertsbrannmur med standard avvisningspolicy vil droppe en pakke som sikkerhetsgruppen tillot, og skykonsollen viser ingen avvisning fordi den aldri hadde en mening. Kontroller begge, i den rekkefølgen pakken møter dem.

Hvis verten bruker en brannmur-frontend fra distribusjonen, bekreft de underliggende reglene i stedet for profilnavnet, fordi en profil kan være aktiv mens porten er stengt.

En opptak på grensesnittet forteller deg hvilken grense som droppet pakken.

Å tillate lytteren er ikke å rute klientene

En VPN-gateway som videresender klienttrafikk trenger mer enn en åpen port. Den trenger IP-videresending, en policy som tillater flyten fra tunnelgrensesnittet til målnettverket, og ofte en kilde-mål-sjekk som er slått av på grensesnittet slik at plattformen ikke kaster trafikk som ikke er adressert til den. Ingenting av dette skapes av lytteregelen.

Det er her et fungerende håndtrykk og en ødelagt datasti skilles, og derfor kan en tunnelstatus se sunn ut mens ingenting lastes.

Rett rutingen som en egen endring med sin egen verifisering, og merk at en videresendende gateway også trenger en utgangspolicy som tillater målet.

Behold en vei tilbake, og snevre deretter inn regelen

Før du endrer ekstern brannmurpolicy, bekreft at det finnes en uavhengig administrasjonsvei, som en sesjonsbehandler, en seriell konsoll eller et out-of-band-nettverk. Hvis den eneste administrasjonsveien går gjennom regelen du redigerer, har du ingen gjenoppretting. Bruk deretter den smale regelen, test fra en ekte klient, og korreler forsøket med bevis på serversiden. Et svar fra en annen tjeneste på samme maskin er ikke bevis for at lytteren ble nådd.

Fjern enhver eksperimentell bred tillatelse så snart den smale virker, og noter hvorfor regelen finnes. AWS dokumenterer sikkerhetsgruppers tilstandsfulle oppførsel, og det dokumentet er det man skal sitere når noen foreslår et bredt område som en snarvei.

Dokumenter tilknytningen også, ellers vil et erstatningsgrensesnitt miste policyen lydløst.