Blokkerer en kommersiell VPN port 5432? Sammenlign alternativene dine

Applikasjonen snakket med databasen sin fra kontoret hver dag. Så slo noen på den kommersielle VPN-klienten på den samme laptopen, og forbindelsen begynte å nullstilles etter håndtrykket. Ingenting i applikasjonen endret seg, tunnelen rapporterer at den er sunn, og brannmuren du kontrollerer har ingen blokkeringsregel. Det som endret seg, er utgangsveien: leverandørens servere er delte endepunkter med høy trafikk, og leverandører filtrerer utgående porter for å redusere misbruk. Database- og e-postsendingporter får mesteparten, fordi det er disse portene som tiltrekker seg skanning og spam fra en anonym adressepool.

Femminutterstesten som skiller filtrering fra alt annet

Fra samme maskin, undersøk en port som må være åpen og porten som feiler, på samme vert, med tunnelen på og deretter av. Bruk samme kommando begge ganger slik at den eneste variabelen er tunnelen:

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

Fire utfall dekker nesten alle tilfeller. Hvis 443 virker og 5432 bare feiler med tunnelen på, ser du portfiltrering på utgangsveien. Hvis begge feiler med tunnelen på og begge virker uten, er problemet ruting eller DNS, ikke portpolitikk. Hvis begge portene kobler til men applikasjonen fortsatt feiler, er feilen autentisering eller TLS, ikke tilgjengelighet. Og hvis bare én av leverandørens serverplasseringer feiler, er det politikk per server, så prøv en annen plassering før du rører noen konfigurasjon.

Alternativ én: splitt-tunnel for databasesubnettet

Hvis laptopen bare trenger den kommersielle VPN-en til andre formål, utelat databasens adresseområde fra tunnelen slik at trafikken aldri kommer inn i den delte utgangen. Dette er det reneste alternativet når de to veiene virkelig ikke trenger å møtes, og det koster ingenting utover en rutingregel du kan dokumentere. Avveiningen er at splitt-tunnel innfører en annen politikkflate: det som er utelatt fra tunnelen, må være bevisst, ikke en bivirkning av et subnett noen la til senere.

Det slutter å virke i det øyeblikket databasen ligger inne i nettverket VPN-en skal nå, så sjekk det før du forplikter deg.

Alternativ to: ditt eget endepunkt, din egen utgang

Å kjøre et lite VPN-endepunkt på en VPS gir deg kontroll over utgangspolitikken, og ingen delt pool er involvert. Dette er alternativet som er verdt en ærlig sammenligning med den kommersielle klienten: du vinner en forutsigbar kildeadresse og mister leverandørens globale fotavtrykk og bekvemmelighet. For et team som trenger database- og e-postporter hele dagen, faller avveiningen vanligvis ut til fordel for å eie endepunktet, fordi feilmodusen blir din egen feilkonfigurasjon i stedet for noen andres misbrukspolitikk.

Sammenlign de to på stabiliteten til kildeadressen, på hvem som kan lese trafikken din, og på hva som skjer den dagen leverandøren av endepunktet endrer sin egen filtrering.

Alternativ tre: ta laptopen ut av veien

En CI-jobb, en planlagt container eller en bastionvert inne i det tillatte nettverket avhenger ikke av en persons tunnelstatus. Nå databasen via SSH-tunnel fra en vert som allerede er tillatt, og laptopen snakker aldri direkte med porten. Dette er alternativet som skalerer når flere personer treffer den samme begrensningen, og det er også det som fjerner problemet i stedet for å rute rundt det.

Det krever mer arbeid på forhånd enn en splitt-tunnelregel, og det hjelper ikke den ene personen som trenger en interaktiv økt akkurat nå.

Hvorfor det er den gale sammenligningen å sette leverandørens adresse på en tillatelsesliste

Å legge leverandørens utgangsadresse til en databasetillatelsesliste virker, og det gir også tilgang til enhver annen abonnent som deler den adressen i det øyeblikket. For en skrivebeskyttet replika bak en strengt tildelt applikasjonskonto kan eksponeringen være akseptabel i en dag. For noe skrivbart er det ikke en avveining som er verdt et navn, og rullerende utgangsadresser gjør det verre: hver serverendring bryter regelen, og vedlikeholdet inviterer brede CIDR-oppføringer som undergraver formålet med en tillatelsesliste.

Dedikerte eller statiske adresser, der leverandøren selger dem, er den eneste versjonen av dette som skalerer. Lås tillatelseslisten til en adresse som bare er din, eller ikke lås den i det hele tatt.

Uansett hva du velger, skriv ned veien og grunnen. Den neste personen vil møte den samme nullstilte forbindelsen og begynne å skylde på applikasjonen.