De applicatie sprak elke dag vanaf kantoor met zijn database. Toen zette iemand de commerciële VPN-client aan op dezelfde laptop, en de verbinding begon na de handshake te resetten. Niets in de applicatie veranderde, de tunnel meldt zich gezond, en de firewall die u beheert heeft geen blokkeringsregel. Wat veranderde is het uitgangspad: servers van de provider zijn gedeelde eindpunten met veel verkeer, en providers filteren uitgaande poorten om misbruik te beperken. Database- en mailinzendingspoorten krijgen het grootste deel, omdat dat de poorten zijn die scans en spam uit een anonieme adrespool aantrekken.

De test van vijf minuten die filtering van al het andere scheidt

Onderzoek vanaf dezelfde machine één poort die open moet zijn en de poort die faalt, op dezelfde host, met de tunnel aan en daarna uit. Gebruik beide keren dezelfde opdracht zodat de enige variabele de tunnel is:

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

Vier uitkomsten dekken bijna elk geval. Als 443 werkt en 5432 alleen faalt met de tunnel aan, ziet u poortfiltering op het uitgangspad. Als beide falen met de tunnel aan en beide werken zonder, is het probleem routing of DNS, niet poortbeleid. Als beide poorten verbinden maar de applicatie toch faalt, ligt de fout bij authenticatie of TLS, niet bij bereikbaarheid. En als alleen één serverlocatie van de provider faalt, is het beleid per server, dus probeer een andere locatie voordat u welke configuratie dan ook aanraakt.

Optie één: split-tunnel voor het databasesubnet

Als de laptop de commerciële VPN alleen voor andere doeleinden nodig heeft, sluit dan het adresbereik van de database uit van de tunnel zodat verkeer nooit in de gedeelde uitgang komt. Dit is de schoonste optie wanneer de twee paden echt niet bij elkaar hoeven te komen, en het kost niets meer dan een routeringsregel die u kunt documenteren. De afweging is dat split-tunneling een tweede beleidsoppervlak introduceert: wat van de tunnel is uitgesloten moet bewust zijn, niet een bijwerking van een subnet dat iemand later toevoegde.

Het werkt niet meer op het moment dat de database in het netwerk ligt dat de VPN moet bereiken, dus controleer dat voordat u zich eraan vastlegt.

Optie twee: uw eigen eindpunt, uw eigen uitgang

Een klein VPN-eindpunt op een VPS draaien geeft u de controle over het uitgangsbeleid, en er is geen gedeelde pool bij betrokken. Dit is de optie die een eerlijke vergelijking met de commerciële client verdient: u wint een voorspelbaar bronadres en verliest de wereldwijde voetafdruk en het gemak van de provider. Voor een team dat de hele dag database- en mailpoorten nodig heeft, valt de afweging meestal uit in het voordeel van het bezitten van het eindpunt, omdat de faalmodus uw eigen verkeerde configuratie wordt in plaats van het misbruikbeleid van iemand anders.

Vergelijk de twee op stabiliteit van het bronadres, op wie uw verkeer kan lezen, en op wat er gebeurt op de dag dat de provider van het eindpunt zijn eigen filtering wijzigt.

Optie drie: haal de laptop uit het pad

Een CI-taak, een geplande container of een bastionhost in het toegestane netwerk hangt niet af van de tunnelstatus van een mens. Bereik de database via een SSH-tunnel vanaf een host die al is toegestaan, en de laptop spreekt nooit rechtstreeks met de poort. Dit is de optie die schaalt wanneer meerdere mensen tegen dezelfde beperking aanlopen, en het is ook degene die het probleem wegneemt in plaats van eromheen te routeren.

Het kost meer voorbereiding dan een split-tunnelregel, en het helpt de ene persoon niet die nu een interactieve sessie nodig heeft.

Waarom het adres van de provider op een allowlist zetten de verkeerde vergelijking is

Het uitgangsadres van de provider aan een database-allowlist toevoegen werkt, en het geeft ook toegang aan elke andere abonnee die dat adres op dat moment deelt. Voor een alleen-lezen replica achter een nauw toegekend applicatieaccount kan de blootstelling een dag lang acceptabel zijn. Voor alles wat beschrijfbaar is, is het geen afweging die een naam verdient, en roterende uitgangsadressen maken het erger: elke serverwijziging breekt de regel, en het onderhoud nodigt brede CIDR-vermeldingen uit die het doel van een allowlist tenietdoen.

Toegewijde of statische adressen, waar de provider ze verkoopt, zijn de enige versie hiervan die schaalt. Koppel de allowlist aan een adres dat alleen van u is, of koppel hem helemaal niet.

Wat u ook kiest, schrijf het pad en de reden op. De volgende persoon krijgt dezelfde resetverbinding en begint de applicatie de schuld te geven.

Gerelateerde artikelen