Cloud-sikkerhedsgruppe til VPN: åbn lytteren, ikke alt

VPN-serveren kører, klienten timeouter, og den første indskydelse er at tilføje en regel, der tillader alt, til sikkerhedsgruppen. Det får det nogle gange til at virke, og det er det værste udfald, for nu ved ingen, hvilken grænse der faktisk blev lukket. Fire separate filtre står mellem klienten og daemonen, og kun én af dem er sikkerhedsgruppen.

Navngiv protokollen før reglen

En regel er en protokol, et portinterval og en kilde. WireGuard lytter på UDP, typisk 51820. OpenVPN er normalt UDP eller TCP 1194 afhængigt af konfigurationen. IPsec kræver sin IKE-udveksling på UDP 500 og 4500 plus selve ESP-protokollen, som er et protokolnavn og ikke en port. At gætte på TCP, fordi de andre regler er TCP, er hvordan man ender med en regel, der ser rigtig ud og ikke matcher noget.

Læs lytteren fra den kørende tjeneste, ikke fra en vejledning. En daemon bundet til én adresse accepterer ikke trafik, der ankommer på en anden.

Begræns kilden til det klientinterval, designet tillader, i stedet for hele internettet.

Sikkerhedsgrupper er stateful; undernet-ACL'er er ikke

Sikkerhedsgrupper er stateful og tillader kun: et tilladt indgående flow får sine svar automatisk, og der er ingen afvisningsregel at tænke over. Undernet-ACL'er er stateless og vurderes i begge retninger, så en indgående tilladelse uden det matchende udgående efemere interval fejler stadig. Den forskel forklarer mange regler, der ser korrekte ud i konsollen.

Bekræft også, hvilken politik der er knyttet til det kørende endpoint, da en instans kan have mere end én gruppe, og en regel i en ikke-tilknyttet gruppe ændrer intet.

Den effektive politik er foreningen af det, der er tilknyttet, ikke den fil, du redigerede.

Værtens firewall er en separat grænse

Cloud-politikken lukker trafik ind til netværksgrænsefladen, og derefter afgør operativsystemet, om daemonen ser den. En vært-firewall med en standardafvisningspolitik vil droppe en pakke, som sikkerhedsgruppen tillod, og cloud-konsollen viser ingen afvisning, fordi den aldrig havde en holdning. Kontrollér begge, i den rækkefølge pakken møder dem.

Hvis værten bruger en distributionens firewall-frontend, så bekræft de underliggende regler i stedet for profilnavnet, fordi en profil kan være aktiv, mens porten er lukket.

En optagelse på grænsefladen fortæller dig, hvilken grænse der droppede pakken.

At tillade lytteren er ikke at route klienterne

En VPN-gateway, der videresender klienttrafik, kræver mere end en åben port. Den kræver IP-videresendelse, en politik der tillader flowet fra tunnelgrænsefladen til destinationsnetværket og ofte et kilde-destinationstjek, der er slået fra på grænsefladen, så platformen ikke kasserer trafik, der ikke er adresseret til den. Intet af det skabes af lyttereglen.

Det er her, et fungerende håndtryk og en brudt datasti skilles, og hvorfor en tunnelstatus kan se sund ud, mens intet indlæses.

Ret routing som en separat ændring med sin egen verifikation, og bemærk at en videresendende gateway også kræver en udgangspolitik, der tillader destinationen.

Behold en vej tilbage, og indsnævr derefter reglen

Før du ændrer fjern-firewallpolitikken, skal du bekræfte, at der findes en uafhængig administrationsvej, såsom en sessionsmanager, en seriel konsol eller et out-of-band-netværk. Hvis den eneste administrationsvej går gennem den regel, du redigerer, har du ingen genopretning. Anvend derefter den smalle regel, test fra en rigtig klient, og korrelér forsøget med beviser på serversiden. Et svar fra en anden tjeneste på samme maskine er ikke bevis for, at lytteren blev nået.

Fjern enhver eksperimentel bred tilladelse, så snart den smalle virker, og notér, hvorfor reglen findes. AWS dokumenterer sikkerhedsgruppers stateful adfærd, og det dokument er det, man skal henvise til, når nogen foreslår et bredt interval som en genvej.

Dokumentér også tilknytningen, ellers mister en erstatningsgrænseflade politikken lydløst.