Ar komercinis VPN blokuoja 5432 prievadą? Palyginkite savo galimybes
Duomenų bazė ar pašto klientas, kuris nepavyksta tik veikiant VPN, susiduria su teikėjo filtru, o ne su jūsų užkarda. Patikrinkite prievadą ir pasirinkite sprendimą.
Programa kasdien iš biuro kalbėjosi su savo duomenų baze. Tada kažkas tame pačiame nešiojamajame kompiuteryje įjungė komercinį VPN klientą, ir ryšys ėmė atsinaujinti po rankos paspaudimo. Programoje niekas nepasikeitė, tunelis praneša esąs sveikas, o jūsų valdoma užkarda neturi blokavimo taisyklės. Pasikeitė išėjimo kelias: teikėjo serveriai yra bendri, didelio srauto galiniai taškai, o teikėjai filtruoja išeinančius prievadus, kad sumažintų piktnaudžiavimą. Duomenų bazių ir pašto siuntimo prievadai gauna didžiausią dalį, nes būtent šie prievadai pritraukia skenavimą ir šiukšles iš anoniminio adresų baseino.
Penkių minučių testas, atskiriantis filtravimą nuo visko kito
Iš to paties kompiuterio patikrinkite vieną prievadą, kuris turi būti atidarytas, ir prievadą, kuris nepavyksta, tame pačiame hoste, su tuneliu įjungtu ir paskui išjungtu. Abiem kartais naudokite tą pačią komandą, kad vienintelis kintamasis būtų tunelis:
Test-NetConnection db.example.com -Port 443
Test-NetConnection db.example.com -Port 5432
nc -vz -w3 db.example.com 5432Keturi rezultatai apima beveik visus atvejus. Jei 443 veikia, o 5432 nepavyksta tik su įjungtu tuneliu, matote prievadų filtravimą išėjimo kelyje. Jei abu nepavyksta su tuneliu ir abu veikia be jo, problema yra maršrutizavime arba DNS, o ne prievadų politikoje. Jei abu prievadai prisijungia, bet programa vis tiek nepavyksta, kaltė tenka autentifikacijai arba TLS, o ne pasiekiamumui. Ir jei nepavyksta tik viena teikėjo serverio vieta, tai yra politika pagal serverį, tad prieš liesdami bet kokią konfigūraciją pabandykite kitą vietą.
Pirmas variantas: padalytas tunelis duomenų bazės potinkiui
Jei nešiojamajam kompiuteriui komercinis VPN reikalingas tik kitiems tikslams, pašalinkite duomenų bazės adresų diapazoną iš tunelio, kad srautas niekada nepatektų į bendrą išėjimą. Tai švariausias variantas, kai du keliai tikrai neturi susitikti, ir tai nieko nekainuoja, išskyrus maršrutizavimo taisyklę, kurią galite dokumentuoti. Kompromisas yra tas, kad padalytas tunelis įveda antrą politikos paviršių: tai, kas pašalinta iš tunelio, turi būti sąmoninga, o ne vėliau kažkieno pridėto potinkio šalutinis poveikis.
Jis nustoja veikti tą akimirką, kai duomenų bazė yra tinkle, kurį VPN turėtų pasiekti, todėl tai patikrinkite prieš įsipareigodami.
Antras variantas: jūsų pačių galinis taškas, jūsų pačių išėjimas
Nedidelio VPN galinio taško paleidimas VPS serveryje suteikia jums išėjimo politikos kontrolę, ir joks bendras baseinas nedalyvauja. Tai variantas, kurį verta sąžiningai palyginti su komerciniu klientu: įgyjate nuspėjamą šaltinio adresą ir prarandate teikėjo pasaulinį pėdsaką bei patogumą. Komandai, kuriai duomenų bazių ir pašto prievadų reikia visą dieną, kompromisas paprastai krypsta į galinio taško nuosavybę, nes gedimo režimas tampa jūsų pačių neteisinga konfigūracija, o ne kažkieno kito piktnaudžiavimo politika.
Palyginkite abu pagal šaltinio adreso stabilumą, pagal tai, kas gali skaityti jūsų srautą, ir pagal tai, kas nutinka tą dieną, kai galinio taško teikėjas pakeičia savo filtravimą.
Trečias variantas: išimkite nešiojamąjį kompiuterį iš kelio
CI užduotis, suplanuotas konteineris ar bastiono hostas leistiname tinkle nepriklauso nuo žmogaus tunelio būsenos. Pasiekite duomenų bazę SSH tuneliu iš hosto, kuris jau leidžiamas, ir nešiojamasis kompiuteris niekada nekalba su prievadu tiesiogiai. Tai variantas, kuris plečiasi, kai keli žmonės susiduria su tuo pačiu apribojimu, ir jis taip pat pašalina problemą, o ne apeina ją.
Tam reikia daugiau darbo iš anksto nei padalyto tunelio taisyklė, ir tai nepadeda tam vienam žmogui, kuriam dabar reikia interaktyvios sesijos.
Kodėl teikėjo adreso įtraukimas į leidžiamų sąrašą yra neteisingas palyginimas
Teikėjo išėjimo adreso įtraukimas į duomenų bazės leidžiamų sąrašą veikia, ir tai taip pat suteikia prieigą kiekvienam kitam abonentui, kuris tuo metu dalijasi šiuo adresu. Tik skaitymui skirtai replikai už griežtai suteikto programos konto atvirumas gali būti toleruojamas vieną dieną. Bet kam, kas įrašoma, tai nėra kompromisas, vertas pavadinimo, o besikeičiantys išėjimo adresai tai blogina: kiekvienas serverio pakeitimas sulaužo taisyklę, o priežiūra kviečia plačius CIDR įrašus, kurie panaikina leidžiamų sąrašo paskirtį.
Skirti arba statiniai adresai, ten kur teikėjas juos parduoda, yra vienintelė to versija, kuri plečiasi. Susiekite leidžiamų sąrašą su adresu, kuris yra tik jūsų, arba nesusiekite visai.
Kad ir ką pasirinktumėte, užrašykite kelią ir priežastį. Kitas žmogus susidurs su tuo pačiu atsinaujinančiu ryšiu ir pradės kaltinti programą.