Cloud sigurnosna grupa za VPN: otvorite slušaoca, ne sve
Sigurnosna grupa je jedan od četiri filtera između klijenta i daemona. Navedite protokol, pa provjerite ACL, host firewall i prosljeđivanje.
VPN server radi, klijent ističe, a prva pomisao je dodati pravilo koje dozvoljava sve u sigurnosnu grupu. To ponekad proradi, i to je najgori ishod, jer sada niko ne zna koja je granica zapravo zatvorena. Četiri odvojena filtera stoje između klijenta i daemona, a samo jedan od njih je sigurnosna grupa.
Navedite protokol prije pravila
Pravilo je protokol, raspon portova i izvor. WireGuard sluša na UDP, obično 51820. OpenVPN je obično UDP ili TCP 1194 zavisno od konfiguracije. IPsec traži IKE razmjenu na UDP 500 i 4500 plus sam ESP protokol, koji je broj protokola, a ne port. Pogađanje TCP-a zato što su druga pravila TCP vodi do pravila koje izgleda ispravno i ne odgovara ničemu.
Čitajte slušaoca iz pokrenute usluge, ne iz tutorijala. Daemon vezan na jednu adresu neće prihvatiti saobraćaj koji stigne na drugu.
Ograničite izvor na raspon klijenata koji dizajn dozvoljava, umjesto na cijeli internet.
Sigurnosne grupe pamte stanje; podmrežni ACL-i ne
Sigurnosne grupe pamte stanje i samo dozvoljavaju: dozvoljeni dolazni tok automatski dobija odgovore, i nema pravila odbijanja o kojem treba razmišljati. Podmrežni ACL-i ne pamte stanje i ocjenjuju se u oba smjera, pa dolazno dozvoljavanje bez odgovarajućeg odlaznog efemernog raspona i dalje pada. Ta razlika objašnjava mnoga pravila koja u konzoli izgledaju ispravno.
Potvrdite i koja je politika pridružena pokrenutom endpointu, jer instanca može imati više grupa, a pravilo u nepridruženoj grupi ne mijenja ništa.
Efektivna politika je unija onoga što je pridruženo, a ne datoteka koju ste uredili.
Host firewall je odvojena granica
Cloud politika propušta saobraćaj do mrežnog interfejsa, a zatim operativni sistem odlučuje hoće li ga daemon vidjeti. Host firewall sa podrazumijevanom politikom odbijanja će odbaciti paket koji je sigurnosna grupa dozvolila, a cloud konzola neće pokazati odbijanje jer nikada nije imala mišljenje. Provjerite oboje, redom kojim paket nailazi na njih.
Ako host koristi distribucijski firewall frontend, potvrdite osnovna pravila, a ne ime profila, jer profil može biti aktivan dok je port zatvoren.
Snimak na interfejsu vam kaže koja je granica odbacila paket.
Dopustiti slušaoca nije isto kao rutirati klijente
VPN gateway koji prosljeđuje klijentski saobraćaj traži više od otvorenog porta. Traži IP prosljeđivanje, politiku koja dozvoljava tok od tunelskog interfejsa do odredišne mreže, i često isključenu provjeru izvora i odredišta na interfejsu da platforma ne odbaci saobraćaj koji nije upućen njoj. Ništa od toga ne stvara pravilo za slušaoca.
Ovdje se razilaze radni handshake i pokvarena podatkovna putanja, i zato status tunela može izgledati zdrav dok se ništa ne učitava.
Popravite rutiranje kao odvojenu promjenu sa vlastitom provjerom i zapazite da gateway koji prosljeđuje treba i izlaznu politiku koja dozvoljava odredište.
Ostavite put za povratak, pa suzite pravilo
Prije promjene udaljene firewall politike, potvrdite da postoji nezavisna putanja upravljanja, kao što je upravitelj sesija, serijska konzola ili vanmrežna mreža. Ako jedina putanja upravljanja ide kroz pravilo koje uređujete, nemate oporavak. Zatim primijenite usko pravilo, testirajte sa stvarnog klijenta i povežite pokušaj sa dokazima na strani servera. Odgovor druge usluge na istom stroju nije dokaz da je slušalac dosegnut.
Uklonite svako eksperimentalno široko dozvoljavanje čim usko proradi, i zabilježite zašto pravilo postoji. AWS dokumentuje ponašanje sigurnosnih grupa sa pamćenjem stanja, i taj dokument treba citirati kada neko predloži širok raspon kao prečicu.
Dokumentujte i pridruživanje, inače će zamjenski interfejs tiho izgubiti politiku.