Blokerer en kommerciel VPN port 5432? Sammenlign dine muligheder

Applikationen talte med sin database fra kontoret hver dag. Så aktiverede nogen den kommercielle VPN-klient på den samme bærbare computer, og forbindelsen begyndte at nulstille efter håndtrykket. Intet i applikationen ændrede sig, tunnelen rapporterer, at den er sund, og den firewall, du kontrollerer, har ingen blokeringsregel. Det, der ændrede sig, er udgangsvejen: udbyderens servere er delte endepunkter med høj trafik, og udbydere filtrerer udgående porte for at reducere misbrug. Databasens og mailafleverings porte får det meste, fordi det er de porte, der tiltrækker scanning og spam fra en anonym adressepulje.

Femminuttesten, der skiller filtrering fra alt andet

Fra den samme maskine undersøger du en port, der skal være åben, og den port, der fejler, på den samme vært, med tunnelen tændt og derefter slukket. Brug den samme kommando begge gange, så den eneste variabel er tunnelen:

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

Fire udfald dækker næsten alle tilfælde. Hvis 443 virker, og 5432 kun fejler med tunnelen tændt, ser du portfiltrering på udgangsvejen. Hvis begge fejler med tunnelen tændt og begge virker uden, er problemet routing eller DNS, ikke portpolitik. Hvis begge porte forbinder, men applikationen stadig fejler, er fejlen godkendelse eller TLS, ikke tilgængelighed. Og hvis kun én af udbyderens serverplaceringer fejler, er det politik pr. server, så prøv en anden placering, før du rører nogen konfiguration.

Mulighed en: split-tunnel for databasesubnettet

Hvis den bærbare kun har brug for den kommercielle VPN til andre formål, skal du udelukke databasens adresseområde fra tunnelen, så trafikken aldrig kommer ind i den delte udgang. Det er den reneste mulighed, når de to veje virkelig ikke behøver at mødes, og det koster intet ud over en routingregel, du kan dokumentere. Afvejningen er, at split-tunnel indfører en anden politikflade: det, der er udelukket fra tunnelen, skal være bevidst, ikke en bivirkning af et subnett, som nogen tilføjede senere.

Det holder op med at virke i det øjeblik, databasen ligger inde i det netværk, som VPN'en skal nå, så kontroller det, før du forpligter dig til det.

Mulighed to: dit eget endepunkt, din egen udgang

At køre et lille VPN-endepunkt på en VPS giver dig kontrol over udgangspolitikken, og der er ingen delt pulje involveret. Det er den mulighed, der er værd at sammenligne ærligt med den kommercielle klient: du får en forudsigelig kildeadresse og mister udbyderens globale fodaftryk og bekvemmelighed. For et team, der har brug for database- og mailporte hele dagen, falder afvejningen normalt ud til fordel for at eje endepunktet, fordi fejltilstanden bliver din egen fejlkonfiguration i stedet for en andens misbrugspolitik.

Sammenlign de to på kildeadressens stabilitet, på hvem der kan læse din trafik, og på hvad der sker den dag, hvor endepunktets udbyder ændrer sin egen filtrering.

Mulighed tre: tag den bærbare ud af vejen

Et CI-job, en planlagt container eller en bastion-vært inde i det tilladte netværk afhænger ikke af en persons tunnelstatus. Nå databasen via SSH-tunnel fra en vært, der allerede er tilladt, og den bærbare taler aldrig direkte med porten. Det er den mulighed, der skalerer, når flere personer rammer den samme begrænsning, og det er også den, der fjerner problemet i stedet for at route uden om det.

Det kræver mere arbejde på forhånd end en split-tunnelregel, og det hjælper ikke den ene person, der har brug for en interaktiv session lige nu.

Hvorfor det er den forkerte sammenligning at sætte udbyderens adresse på en tilladelsesliste

At tilføje udbyderens udgangsadresse til en databasetilladelsesliste virker, og det giver også adgang til enhver anden abonnent, der deler den adresse i det øjeblik. For en skrivebeskyttet replika bag en snævert tildelt applikationskonto kan eksponeringen være tolerabel i en dag. For noget skrivbart er det ikke en afvejning, der er værd at nævne, og roterende udgangsadresser gør det værre: hver serverændring bryder reglen, og vedligeholdelsen inviterer brede CIDR-poster, der underminerer formålet med en tilladelsesliste.

Dedikerede eller statiske adresser, hvor udbyderen sælger dem, er den eneste version af dette, der skalerer. Nøgl tilladelseslisten til en adresse, der kun er din, eller lad være med at nøgle den overhovedet.

Uanset hvad du vælger, skal du skrive vejen og grunden ned. Den næste person vil møde den samme nulstillede forbindelse og begynde at give applikationen skylden.