A VPN-kiszolgáló fut, az ügyfél időtúllépést kap, és az első ösztön az, hogy egy mindent engedélyező szabályt adjunk a biztonsági csoporthoz. Ez néha működésre bírja, és éppen ez a legrosszabb kimenet, mert most senki sem tudja, melyik határ zárult be valójában. Négy külön szűrő áll az ügyfél és a daemon között, és csak az egyik a biztonsági csoport.

A szabály előtt nevezze meg a protokollt

Egy szabály protokollból, porttartományból és forrásból áll. A WireGuard UDP-n figyel, általában 51820. OpenVPN általában UDP vagy TCP 1194, a beállítástól függően. Az IPsec IKE-cserét igényel UDP 500 és 4500 porton, valamint magát az ESP protokollt, amely protokollszám, nem port. TCP-t tippelni, mert a többi szabály TCP, pont ahhoz vezet, hogy a szabály jónak látszik és semmihez nem illik.

A figyelőt a futó szolgáltatásból olvassa ki, ne egy útmutatóból. Az egy címhez kötött daemon nem fogadja el a másik címre érkező forgalmat.

A forrást arra az ügyféltartományra korlátozza, amelyet a tervezés engedélyez, ne az egész internetre.

A biztonsági csoportok állapottartók; az alhálózati ACL-ek nem

A biztonsági csoportok állapottartók és csak engedélyeznek: az engedélyezett bejövő folyam automatikusan megkapja a válaszait, és nincs elutasítási szabály, amin gondolkodni kellene. Az alhálózati ACL-ek állapotmentesek, és mindkét irányban kiértékelődnek, ezért a bejövő engedélyezés a megfelelő kimenő efemer tartomány nélkül továbbra is elbukik. Ez a különbség magyarázza sok szabályt, amely a konzolon helyesnek látszik.

Azt is ellenőrizze, melyik házirend van a futó végponthoz csatolva, mert egy példányhoz több csoport is tartozhat, és a nem csatolt csoportban lévő szabály semmit sem változtat.

A tényleges házirend a csatoltak uniója, nem a szerkesztett fájl.

A gazdagép tűzfala külön határ

A felhő házirendje beengedi a forgalmat a hálózati csatolóhoz, majd az operációs rendszer dönti el, látja-e a daemon. Gazdagép-tűzfal alapértelmezett elutasítási házirenddel eldobja azt a csomagot, amelyet a biztonsági csoport engedélyezett, a felhő konzol pedig nem mutat elutasítást, mert soha nem volt véleménye. Ellenőrizze mindkettőt, abban a sorrendben, ahogy a csomag találkozik velük.

Ha a gazdagép a disztribúció tűzfal-előtagját használja, az alapul szolgáló szabályokat ellenőrizze, ne a profil nevét, mert a profil aktív lehet, miközben a port zárva van.

A csatolón készített rögzítés megmondja, melyik határ dobta el a csomagot.

A figyelő engedélyezése nem az ügyfelek útvonalválasztása

Az ügyfélforgalmat továbbító VPN-átjárónak több kell egy nyitott portnál. Kell hozzá IP-továbbítás, az alagút csatolójától a célhálózatig engedélyező házirend, és gyakran a forrás-cél ellenőrzés kikapcsolása a csatolón, hogy a platform ne dobja el a hozzá nem címzett forgalmat. Ezek egyikét sem a figyelő szabálya hozza létre.

Itt válnak el a működő kézfogás és a törött adatút, és ezért tűnhet egészségesnek az alagút állapota, miközben semmi sem töltődik be.

Az útvonalválasztást külön változtatásként javítsa, saját ellenőrzéssel, és jegyezze meg, hogy a továbbító átjárónak kimenő házirendre is szüksége van, amely engedélyezi a célt.

Hagyjon visszautat, majd szűkítse a szabályt

Mielőtt a távoli tűzfal házirendjét módosítja, ellenőrizze, hogy létezik független felügyeleti útvonal, például munkamenet-kezelő, soros konzol vagy sávon kívüli hálózat. Ha az egyetlen felügyeleti útvonal a szerkesztett szabályon megy keresztül, nincs helyreállítás. Ezután alkalmazza a szűk szabályt, teszteljen valódi ügyfélről, és kapcsolja össze a kísérletet a kiszolgálóoldali bizonyítékokkal. Egy másik szolgáltatás válasza ugyanazon a gépen nem bizonyítja, hogy a figyelő elérhető volt.

Távolítson el minden kísérleti széles engedélyezést, amint a szűk működik, és jegyezze fel, miért létezik a szabály. Az AWS dokumentálja a biztonsági csoportok állapottartó viselkedését, és ezt a dokumentumot kell idézni, amikor valaki széles tartományt javasol rövidítésként.

A csatolást is dokumentálja, különben egy csere-csatoló csendesen elveszíti a házirendet.

Kapcsolódó cikkek