Nuba sekurgrupo por VPN: malfermu la aŭskultanton, ne ĉion
Sekurgrupo estas unu el kvar filtriloj inter la kliento kaj la demono. Nomu la protokolon, poste kontrolu la ACL, la gastigantan fajroŝirmilon kaj la plusendadon.
La VPN-servilo funkcias, la kliento finiĝas pro tempo, kaj la unua impulso estas aldoni permesan regulon por ĉio al la sekurgrupo. Tio foje igas ĝin funkcii, kaj tio estas la plej malbona rezulto, ĉar nun neniu scias, kiu limo fakte fermiĝis. Kvar apartaj filtriloj staras inter la kliento kaj la demono, kaj nur unu el ili estas la sekurgrupo.
Nomu la protokolon antaŭ la regulo
Regulo estas protokolo, porto-intervalo kaj fonto. WireGuard aŭskultas je UDP, kutime 51820. OpenVPN estas kutime UDP aŭ TCP 1194 laŭ la agordo. IPsec bezonas sian IKE-interŝanĝon je UDP 500 kaj 4500 plus la protokolon ESP mem, kiu estas protokola numero kaj ne porto. Diveni TCP ĉar la aliaj reguloj estas TCP kondukas al regulo, kiu aspektas ĝusta kaj kongruas kun nenio.
Legu la aŭskultanton el la funkcianta servo, ne el lernilo. Demono ligita al unu adreso ne akceptos trafikon alvenantan al alia.
Limigu la fonton al la klienta intervalo, kiun la dezajno permesas, anstataŭ al la tuta interreto.
Sekurgrupoj konservas staton; subretaj ACL-oj ne
Sekurgrupoj konservas staton kaj nur permesas: permesita envenanta fluo aŭtomate ricevas siajn respondojn, kaj ne ekzistas malpermesa regulo pri kiu pensi. Subretaj ACL-oj estas senstatuj kaj taksataj en ambaŭ direktoj, do envenanta permeso sen la responda elira efemera intervalo ankoraŭ fiaskas. Tiu diferenco klarigas multajn regulojn, kiuj aspektas ĝustaj en la konzolo.
Konfirmu ankaŭ, kiu politiko estas alligita al la funkcianta finpunkto, ĉar kazo povas havi pli ol unu grupon kaj regulo en nealligita grupo ŝanĝas nenion.
La efektiva politiko estas la unio de tio, kio estas alligita, ne la dosiero, kiun vi redaktis.
La gastiganta fajroŝirmilo estas aparta limo
La nuba politiko enlasas trafikon al la reta interfaco, kaj poste la operaciumo decidas, ĉu la demono vidos ĝin. Gastiganta fajroŝirmilo kun defaŭlta malpermesa politiko forĵetos paketon, kiun la sekurgrupo permesis, kaj la nuba konzolo montros neniun malpermeson, ĉar ĝi neniam havis opinion. Kontrolu ambaŭ, laŭ la ordo, en kiu la paketo renkontas ilin.
Se la gastiganto uzas distribuan fajroŝirmilan fasdon, konfirmu la subajn regulojn anstataŭ la profilan nomon, ĉar profilo povas esti aktiva dum la porto estas fermita.
Kaptado ĉe la interfaco diras al vi, kiu limo forĵetis la paketon.
Enlasi la aŭskultanton ne estas enkursigi la klientojn
VPN-pordego, kiu plusendas klientan trafikon, bezonas pli ol malfermitan porton. Ĝi bezonas IP-plusendadon, politikon permesantan la fluon de la tunela interfaco al la cella reto, kaj ofte malŝaltitan fontan-cellokontrolon ĉe la interfaco, por ke la platformo ne forĵetu trafikon ne adresitan al ĝi. Nenion el tio kreas la regulo pri la aŭskultanto.
Ĉi tie disiĝas funkcianta manpremo kaj rompita datenvojo, kaj tial tunela stato povas aspekti sana dum nenio ŝargiĝas.
Riparu la enkursigadon kiel apartan ŝanĝon kun propra kontrolo, kaj notu, ke plusendanta pordego ankaŭ bezonas eliran politikon, kiu permesas la celon.
Konservu vojon reen, poste mallarĝigu la regulon
Antaŭ ol ŝanĝi la malproksiman fajroŝirmilan politikon, konfirmu, ke ekzistas sendependa administra vojo, ekzemple sesia administrilo, seria konzolo aŭ ekstrabanda reto. Se la sola administra vojo iras tra la regulo, kiun vi redaktas, vi ne havas restaŭron. Poste apliku la mallarĝan regulon, testu de reala kliento kaj koreligu la provon kun pruvoj ĉe la servila flanko. Respondo de alia servo sur la sama maŝino ne pruvas, ke la aŭskultanto estis atingita.
Forigu iun ajn eksperimentan larĝan permeson tuj kiam la mallarĝa funkcias, kaj notu, kial la regulo ekzistas. AWS dokumentas la statokonservan konduton de sekurgrupoj, kaj tiu dokumento estas la citinda, kiam iu proponas larĝan intervalon kiel fuĝvojon.
Dokumentu ankaŭ la alligon, alie anstataŭa interfaco silente perdos la politikon.