Kommersiële VPN blokkeer poort 5432? Vergelyk jou opsies

Die toepassing het elke dag van die kantoor af met sy databasis gepraat. Toe aktiveer iemand die kommersiële VPN-kliënt op dieselfde skootrekenaar, en die verbinding het ná die handskud begin terugstel. Niks in die toepassing het verander nie, die tonnel rapporteer gesond, en die firewall wat jy beheer het geen blokkerende reël nie. Wat verander het, is die uitgangspad: verskafferbedieners is gedeelde eindpunte met hoë volumes, en verskaffers filter uitgaande poorte om misbruik te verminder. Databasis- en e-posindieningspoorte kry die meeste daarvan, want dit is die poorte wat skandering en strooipos uit 'n anonieme adrespoel lok.

Die vyfminuuttoets wat filtering van al die res onderskei

Vanaf dieselfde masjien, ondersoek een poort wat oop moet wees en die poort wat misluk, op dieselfde gasheer, met die tonnel aan en dan af. Gebruik albei kere dieselfde opdrag sodat die enigste veranderlike die tonnel is:

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

Vier uitkomste dek byna elke geval. As 443 werk en 5432 misluk net met die tonnel aan, kyk jy na poortfiltering op die uitgangspad. As albei misluk met die tonnel aan en albei werk sonder dit, is die probleem roetering of DNS eerder as poortbeleid. As albei poorte verbind maar die toepassing steeds misluk, is die fout verifikasie of TLS, nie bereikbaarheid nie. En as net een verskafferbediener-ligging misluk, is dit per-bediener beleid, so probeer 'n ander ligging voordat jy enige konfigurasie aanraak.

Opsie een: split-tonnel die databasis-subnet

As die skootrekenaar die kommersiële VPN net vir ander doeleindes nodig het, sluit die databasis se adresreeks van die tonnel uit sodat verkeer glad nie by die gedeelde uitgang instap nie. Dit is die skoonste opsie wanneer die twee paaie werklik nie hoef te ontmoet nie, en dit kos niks buiten 'n roeteringsreël wat jy kan dokumenteer. Die kompromie is dat split-tonnel maak 'n tweede beleidsoppervlak oop: wat van die tonnel uitgesluit word, moet doelbewus wees, nie 'n newe-effek van 'n subnet wat iemand later bygevoeg het nie.

Dit hou op werk die oomblik wanneer die databasis binne die netwerk woon wat die VPN veronderstel is om te bereik, so kontroleer dit voordat jy daartoe verbind.

Opsie twee: jou eie eindpunt, jou eie uitgang

Om 'n klein VPN-eindpunt op 'n VPS te bedryf, plaas jou in beheer van die uitgangsbeleid, en geen gedeelde poel is betrokke nie. Dit is die opsie wat eerlik teenoor die kommersiële kliënt vergelyk moet word: jy kry 'n voorspelbare bronadres en verloor die verskaffer se globale voetspoor en gerief. Vir 'n span wat databasis- en e-pospoorte heeldag nodig het, val die ruil gewoonlik ten gunste van die besit van die eindpunt, want die foutmodus word jou eie verkeerde konfigurasie eerder as iemand anders se misbruikbeleid.

Vergelyk die twee op stabiliteit van die bronadres, wie jou verkeer kan lees, en wat gebeur op die dag wanneer die eindpunt se verskaffer sy eie filtering verander.

Opsie drie: haal die skootrekenaar uit die pad

'n CI-werk, 'n geskeduleerde houer, of 'n bastion-gasheer binne die toegelate netwerk hang nie van 'n mens se tonneltoestand af nie. Bereik die databasis per SSH-tonnel vanaf 'n gasheer wat reeds toegelaat is, en die skootrekenaar praat nooit direk met die poort nie. Dit is die opsie wat skaal wanneer verskeie mense dieselfde beperking tref, en dit is ook die een wat die probleem verwyder eerder as om dit te omseil.

Dit is meer werk vooraf as 'n split-tonnelreël, en dit help nie die een persoon wat nou 'n interaktiewe sessie nodig het nie.

Waarom die verskaffer se adres op 'n toelaatlys sit die verkeerde vergelyking is

Om die verskaffer se uitgangadres by 'n databasis-toelaatlys te voeg, werk, en dit verleen ook toegang aan elke ander intekenaar wat daardie adres op daardie oomblik deel. Vir 'n lees-alleen replika agter 'n eng toegekende toepassingsrekening, mag die blootstelling vir 'n dag verdraagsaam wees. Vir enigiets skryfbaar is dit nie 'n kompromie wat die naam werd is nie, en roterende uitgangadresse maak dit erger: elke bedienerverandering breek die reël, en die instandhouding nooi breë CIDR-inskrywings uit wat die doel van 'n toelaatlys verydel.

Toegewyde of statiese adresse, waar die verskaffer dit verkoop, is die enigste weergawe hiervan wat skaal. Sleutel die toelaatlys aan 'n adres wat alleen aan jou behoort, of sleutel dit glad nie.

Wat jy ook al kies, skryf die pad en die rede neer. Die volgende persoon sal dieselfde terugstellende verbinding teëkom en sal begin om die toepassing te blameer.