Die VPN-bediener loop, die kliënt hou op reageer, en die eerste instink is om 'n toelaat-alles-reël by die sekuriteitsgroep te voeg. Dit laat dit soms werk, en dit is die slegste uitkoms, want nou weet niemand watter grens eintlik gesluit is nie. Vier afsonderlike filters sit tussen die kliënt en die daemon, en net een daarvan is die sekuriteitsgroep.

Noem die protokol voor die reël

'n Reël is 'n protokol, 'n poortreeks en 'n bron. WireGuard luister op UDP, gewoonlik 51820. OpenVPN is gewoonlik UDP of TCP 1194, afhangend van hoe dit opgestel is. IPsec het sy IKE-uitruiling op UDP 500 en 4500 nodig, plus die ESP-protokol self, wat 'n protokolnommer is en nie 'n poort nie. Om TCP te raai omdat die ander reëls TCP is, is hoe mense 'n reël kry wat reg lyk en niks pas nie.

Lees die luisteraar uit die lopende diens, nie uit 'n handleiding nie. 'n Daemon wat aan een adres gebind is, sal nie verkeer aanvaar wat op 'n ander adres aankom nie.

Beperk die bron tot die kliëntreeks wat die ontwerp toelaat, eerder as die hele internet.

Sekuriteitsgroepe is toestandbehoudend; subnet-ACL's is nie

Sekuriteitsgroepe is toestandbehoudend en net-toelaat: 'n toegelate inkomende vloei kry outomaties sy antwoorde, en daar is geen weier-reël om te oorweeg nie. Subnet-ACL's is toestandloos en word in beide rigtings geëvalueer, so 'n inkomende toelating sonder die ooreenstemmende uitgaande efemere reeks faal steeds. Daardie verskil verduidelik baie reëls wat in die konsole korrek lyk.

Bevestig ook watter beleid aan die lopende eindpunt gekoppel is, want 'n instansie kan meer as een groep hê en 'n reël in 'n ongekoppelde groep verander niks nie.

Die effektiewe beleid is die vereniging van wat gekoppel is, nie die lêer wat jy geredigeer het nie.

Die gasheer-firewall is 'n aparte grens

Die wolkbeleid laat verkeer na die netwerkkoppelvlak deur, en dan besluit die bedryfstelsel of die daemon dit sien. 'n Gasheer-firewall met 'n verstek-weierbeleid sal 'n pakket laat val wat die sekuriteitsgroep toegelaat het, en die wolk-konsole sal geen weiering wys nie omdat dit nooit 'n mening gehad het nie. Kontroleer beide, in die volgorde waarin die pakket hulle teëkom.

As die gasheer 'n verspreidings-firewall-front gebruik, bevestig die onderliggende reëls eerder as die profielnaam, want 'n profiel kan aktief wees terwyl die poort toe is.

'n Opname op die koppelvlak vertel jou watter grens die pakket laat val het.

Om die luisteraar toe te laat is nie om die kliënte te roeteer nie

'n VPN-grendel wat kliëntverkeer aanstuur, het meer nodig as 'n oop poort. Dit het IP-aansturing nodig, 'n beleid wat die vloei van die tonnelkoppelvlak na die bestemmingsnetwerk toelaat, en dikwels 'n bron-bestemming-kontrole wat op die koppelvlak afgeskakel is sodat die platform nie verkeer verwerp wat nie aan hom gerig is nie. Niks daarvan word deur die luisteraar-reël geskep nie.

Dit is waar 'n werkende handdruk en 'n gebreekte datapad uiteengaan, en waarom 'n tonnelstatus gesond kan lyk terwyl niks laai nie.

Maak roetering reg as 'n aparte verandering met sy eie verifikasie, en let daarop dat 'n aansturende grendel ook 'n uitgangsbeleid nodig het wat die bestemming toelaat.

Hou 'n pad terug oop, en vernou dan die reël

Voor jy die remote-firewallbeleid verander, bevestig dat daar 'n onafhanklike bestuurspad bestaan, soos 'n sessiebestuurder, 'n reekskonsole of 'n buiteband-netwerk. As die enigste bestuurspad deur die reël loop wat jy wysig, het jy geen herstel nie. Pas dan die smal reël toe, toets vanaf 'n werklike kliënt, en korreleer die poging met bewyse aan die bedienerkant. 'n Antwoord van 'n ander diens op dieselfde masjien is nie bewys dat die luisteraar bereik is nie.

Verwyder enige eksperimentele breë toelating sodra die smal een werk, en merk op waarom die reël bestaan. AWS dokumenteer die toestandbehoudende gedrag van sekuriteitsgroepe, en daardie dokument is die een om aan te haal wanneer iemand 'n wye reeks as 'n kortpad voorstel.

Dokumenteer ook die koppeling, anders sal 'n vervangingskoppelvlak die beleid stilweg verloor.

Verwante artikels