Estääkö kaupallinen VPN portin 5432? Vertaa vaihtoehtojasi
Tietokanta tai sähköpostiohjelma, joka epäonnistuu vain VPN:n ollessa päällä, kohtaa palveluntarjoajan suodattimen, ei palomuutiasi. Testaa portti ja valitse sitten ratkaisu.
Sovellus keskusteli tietokantansa kanssa toimistosta joka päivä. Sitten joku otti kaupallisen VPN-asiakasohjelman käyttöön samalla kannettavalla, ja yhteys alkoi nollautua kättelyn jälkeen. Sovelluksessa ei muuttunut mikään, tunneli ilmoittaa olevansa kunnossa, eikä hallitsemassasi palomuurissa ole estosääntöä. Se mikä muuttui, on lähtöpolku: palveluntarjoajan palvelimet ovat jaettuja, suuren liikenteen päätepisteitä, ja tarjoajat suodattavat lähteviä portteja vähentääkseen väärinkäyttöä. Tietokanta- ja sähköpostin lähetysportit saavat suurimman osan, koska juuri ne portit houkuttelevat skannausta ja roskapostia anonyymista osoitepoolista.
Viiden minuutin testi, joka erottaa suodatuksen kaikesta muusta
Samasta koneesta testaa portti, jonka on oltava auki, ja portti, joka epäonnistuu, samalla isännällä, tunneli päällä ja sitten pois. Käytä samaa komentoa molemmilla kerroilla, jotta ainoa muuttuja on tunneli:
Test-NetConnection db.example.com -Port 443
Test-NetConnection db.example.com -Port 5432
nc -vz -w3 db.example.com 5432Neljä tulosta kattaa lähes kaikki tapaukset. Jos 443 toimii ja 5432 epäonnistuu vain tunnelin ollessa päällä, näet porttisuodatusta lähtöpolulla. Jos molemmat epäonnistuvat tunnelin ollessa päällä ja molemmat toimivat ilman sitä, ongelma on reitityksessä tai DNS:ssä, ei porttikäytännössä. Jos molemmat portit yhdistyvät mutta sovellus epäonnistuu edelleen, vika on todentamisessa tai TLS:ssä, ei tavoitettavuudessa. Ja jos vain yksi palveluntarjoajan palvelinsijainti epäonnistuu, kyse on palvelinkohtaisesta käytännöstä, joten kokeile toista sijaintia ennen minkään asetuksen koskemista.
Vaihtoehto yksi: jaettu tunneli tietokannan aliverkolle
Jos kannettava tarvitsee kaupallista VPN:ää vain muihin tarkoituksiin, jätä tietokannan osoitealue tunnelin ulkopuolelle, jotta liikenne ei koskaan saavu jaettuun lähtöön. Tämä on puhtain vaihtoehto, kun kahden polun ei todella tarvitse kohdata, eikä se maksa mitään muuta kuin reitityssäännön, jonka voit dokumentoida. Kaupan hinta on se, että jaettu tunneli tuo toisen käytäntöpinnan: se, mikä jätetään tunnelin ulkopuolelle, on tehtävä tarkoituksella, ei aliverkon sivutuotteena, jonka joku lisäsi myöhemmin.
Se lakkaa toimimasta sinä hetkenä, kun tietokanta sijaitsee verkossa, johon VPN:n on tarkoitus päästä, joten tarkista se ennen sitoutumista.
Vaihtoehto kaksi: oma päätepiste, oma lähtö
Pienen VPN-päätepisteen ajaminen VPS:llä antaa sinulle lähtökäytännön hallinnan, eikä jaettua poolia ole mukana. Tämä on vaihtoehto, joka kannattaa vertailla rehellisesti kaupalliseen asiakasohjelmaan: voitat ennustettavan lähdeosoitteen ja menetät tarjoajan maailmanlaajuisen jalanjäljen ja mukavuuden. Tiimille, joka tarvitsee tietokanta- ja sähköpostiportteja koko päivän, kauppa kallistuu yleensä päätepisteen omistamisen puolelle, koska vikatilasta tulee oma väärä asetuksesi eikä jonkun toisen väärinkäyttökäytäntö.
Vertaa kahta lähdeosoitteen vakauden, sen suhteen kuka voi lukea liikennettäsi ja sen suhteen, mitä tapahtuu sinä päivänä, kun päätepisteen tarjoaja muuttaa omaa suodatustaan.
Vaihtoehto kolme: ota kannettava pois polulta
CI-työ, ajastettu kontti tai bastion-isäntä sallitun verkon sisällä ei riipu ihmisen tunnelitilasta. Saavuta tietokanta SSH-tunnelilla isännästä, joka on jo sallittu, eikä kannettava puhu portille koskaan suoraan. Tämä on vaihtoehto, joka skaalautuu, kun useat ihmiset kohtaavat saman rajoituksen, ja se on myös se, joka poistaa ongelman sen kiertämisen sijaan.
Se vaatii enemmän työtä etukäteen kuin jaetun tunnelin sääntö, eikä se auta sitä yhtä henkilöä, joka tarvitsee vuorovaikutteisen istunnon juuri nyt.
Miksi tarjoajan osoitteen lisääminen sallittujen luetteloon on väärä vertailu
Tarjoajan lähtöosoitteen lisääminen tietokannan sallittujen luetteloon toimii, ja se antaa pääsyn myös jokaiselle muulle tilaajalle, joka jakaa kyseisen osoitteen sillä hetkellä. Kapeasti myönnetyn sovellustilin takana olevalle vain luku -replikalle altistuminen voi olla päivän ajan siedettävää. Mihin tahansa kirjoitettavaan se ei ole vertailu, jonka nimi kannattaa mainita, ja pyörivät lähtöosoitteet pahentavat sitä: jokainen palvelinmuutos rikkoo säännön, ja ylläpito houkuttelee laajoja CIDR-merkintöjä, jotka tekevät sallittujen luettelon tarkoituksen tyhjäksi.
Omistetut tai staattiset osoitteet, jos tarjoaja niitä myy, ovat ainoa versio tästä, joka skaalautuu. Kiinnitä sallittujen luettelo osoitteeseen, joka on vain sinun, tai älä kiinnitä sitä lainkaan.
Mitä ikinä valitsetkin, kirjoita polku ja syy muistiin. Seuraava henkilö kohtaa saman nollautuvan yhteyden ja alkaa syyttää sovellusta.