Blokkolja egy kereskedelmi VPN az 5432-es portot? Hasonlítsa össze a lehetőségeit

Az alkalmazás minden nap az irodából beszélt az adatbázisával. Aztán valaki bekapcsolta a kereskedelmi VPN-klienst ugyanazon a laptopon, és a kapcsolat a kézfogás után újraindult. Az alkalmazásban semmi sem változott, az alagút egészségesnek jelenti magát, és a tűzfalban, amelyet Ön irányít, nincs blokkolási szabály. Ami változott, az a kilépési útvonal: a szolgáltató szerverei megosztott, nagy forgalmú végpontok, a szolgáltatók pedig szűrik a kimenő portokat a visszaélések csökkentésére. Az adatbázis- és levélküldő portok kapják a legnagyobb részét, mert ezek a portok vonzzák a vizsgálatot és a spamet egy névtelen címkészletből.

Az ötperces teszt, amely elválasztja a szűrést minden mástól

Ugyanarról a gépről vizsgáljon meg egy portot, amelynek nyitva kell lennie, és a portot, amely hibázik, ugyanazon a gazdagépen, bekapcsolt, majd kikapcsolt alagúttal. Mindkétszer ugyanazt a parancsot használja, hogy az egyetlen változó az alagút legyen:

Test-NetConnection db.example.com -Port 443
Test-NetConnection db.example.com -Port 5432
nc -vz -w3 db.example.com 5432

Négy eredmény szinte minden esetet lefed. Ha a 443 működik és az 5432 csak bekapcsolt alagúttal hibázik, portszűrést lát a kilépési útvonalon. Ha mindkettő hibázik bekapcsolt alagúttal és mindkettő működik nélküle, a probléma az útválasztás vagy a DNS, nem a portszabály. Ha mindkét port csatlakozik, de az alkalmazás továbbra is hibázik, a hiba a hitelesítésben vagy a TLS-ben van, nem az elérhetőségben. És ha csak a szolgáltató egyetlen szerverhelye hibázik, az szerverenkénti szabály, ezért próbáljon másik helyet, mielőtt bármilyen konfigurációhoz hozzányúlna.

Első lehetőség: osztott alagút az adatbázis alhálózatához

Ha a laptopnak a kereskedelmi VPN-re csak más célokra van szüksége, zárja ki az adatbázis címkészletét az alagútból, hogy a forgalom soha ne lépjen be a megosztott kilépésbe. Ez a legtisztább lehetőség, amikor a két útvonalnak valóban nem kell találkoznia, és semmibe nem kerül egy dokumentálható útválasztási szabályon kívül. A kompromisszum az, hogy az osztott alagút második szabályfelületet hoz létre: amit kizárunk az alagútból, annak szándékosnak kell lennie, nem egy később hozzáadott alhálózat mellékhatásának.

Abban a pillanatban abbahagyja a működést, amikor az adatbázis abban a hálózatban él, amelyet a VPN-nek el kell érnie, ezért ezt ellenőrizze, mielőtt elkötelezné magát.

Második lehetőség: saját végpont, saját kimenet

Egy kis VPN-végpont futtatása VPS-en a kimeneti szabály irányítását adja a kezébe, és nem vesz részt megosztott készlet. Ez az a lehetőség, amelyet érdemes őszintén összehasonlítani a kereskedelmi klienssel: kiszámítható forrás címet nyer, és elveszíti a szolgáltató globális lábnyomát és kényelmét. Egy olyan csapatnak, amelynek egész nap szüksége van adatbázis- és levélportokra, a kompromisszum általában a végpont birtoklása felé billen, mert a hiba módja a saját hibás konfigurációja lesz, nem valaki más visszaélés-szabálya.

Hasonlítsa össze a kettőt a forráscím stabilitása, aközött, hogy ki olvashatja a forgalmát, és aközött, hogy mi történik azon a napon, amikor a végpont szolgáltatója megváltoztatja a saját szűrését.

Harmadik lehetőség: vegye ki a laptopot az útvonalból

Egy CI-feladat, egy ütemezett konténer vagy egy bástya gazdagép az engedélyezett hálózaton belül nem függ egy ember alagútállapotától. Érje el az adatbázist SSH-alagúton keresztül egy már engedélyezett gazdagépről, és a laptop soha nem beszél közvetlenül a porttal. Ez az a lehetőség, amely akkor skálázódik, amikor több ember ugyanabba a korlátba ütközik, és ez az is, amely megszünteti a problémát ahelyett, hogy megkerülné.

Ez több munkát igényel előre, mint egy osztott alagút szabálya, és nem segít annak az egy személynek, akinek most azonnal interaktív munkamenetre van szüksége.

Miért rossz összehasonlítás a szolgáltató címét az engedélyezési listára tenni

A szolgáltató kilépési címének felvétele egy adatbázis-engedélyezési listára működik, és hozzáférést ad minden más előfizetőnek is, aki abban a pillanatban megosztja azt a címet. Egy szűken kiadott alkalmazásfiók mögötti csak olvasható replika esetében a kitettség egy napra elviselhető lehet. Bármi írható esetében ez nem névadásra érdemes kompromisszum, a forgó kilépési címek pedig rontják: minden szerverváltás megtöri a szabályt, és a karbantartás széles CIDR-bejegyzéseket hív elő, amelyek meghiúsítják az engedélyezési lista célját.

A dedikált vagy statikus címek, ahol a szolgáltató árulja őket, az egyetlen változata ennek, ami skálázódik. Kössék az engedélyezési listát egy olyan címhez, amely csak az önöké, vagy ne kössék semmihez.

Bármit is választ, írja le az útvonalat és az okot. A következő ember ugyanazzal az újrainduló kapcsolattal találkozik, és az alkalmazást kezdi majd hibáztatni.