SSH në distancë përmes VPN: çfarë nuk bën tuneli

Një VPN i jep një serveri SSH një rrugë private dhe heq nevojën për një dëgjues publik në portën 22. Ai nuk vërteton hostin, nuk autorizon përdoruesin dhe nuk vendos cilat llogari mund të hyjnë. Kjo mbetet puna e SSH. Nëse VPN është mënyra e duhur për të arritur serverin varet nga tri kushte, dhe tuneli është vetëm një nga përgjigjet e mundshme.

Çfarë ndryshon tuneli dhe çfarë vendos ende SSH

Tuneli ndryshon arritshmërinë: cilat adresa mund të arrihen dhe nga ku. Ai nuk ndryshon atë që ndodh pasi lidhja TCP vendoset, ku serveri paraqet një çelës hosti dhe kërkon një identitet përdoruesi.

Mbaji dy shtresat të ndara në mendje dhe në dokumentacion. Një hyrje në VPN provon kush mund të përdorë rrjetin. Nuk thotë asgjë për llogaritë që ekzistojnë në objektiv dhe nuk është leje për t'u futur në çdo makinë të arritshme.

Edhe mënyrat e dështimit janë të ndara, dhe pikërisht kjo e bën ndarjen të dobishme gjatë një incidenti.

Tri kushte që përcaktojnë modelin e aksesit

Së pari, a duhet serveri të jetë i arritshëm nga njerëz jashtë rrjetit tënd? Nëse jo, një rrugë private plus një bastion ose një rrjetë është dizajni më i vogël. Së dyti, a mund popullsia e klientëve vërtet të ekzekutojë klientin VPN, përfshirë ata në pajisje të menaxhuara me kufizime?

Së treti, a të duhet kontroll për shërbim apo për përdorues? Një VPN jep shtrirje rrjeti; SSH jep akses në llogari. Nëse kërkesa është që një kontraktor të arrijë një host dhe asgjë tjetër, ajo është kërkesë autorizimi dhe tuneli vetëm nuk mund ta shprehë.

Përgjigju atyre tre dhe modeli zgjedh vetveten. Nëse i anashkalon, përfundon duke ekspozuar SSH publikisht vetëm për të shmangur shpërndarjen e klientit.

Konfirmo rrugën private përpara se të fajësosh SSH

Lidhu me VPN-në e miratuar dhe përdor emrin ose adresën private të dokumentuar të objektivit. Më pas kontrollo rrugën e zgjedhur, lejen e portës dhe rrugën e kthimit drejt klientit. Një emër që zgjidhet saktë nuk është provë që adresa merr tunelin e synuar, sepse prefikset lokale dhe të largëta që mbivendosen mund ta dërgojnë kërkesën diku krejt tjetër. Ky dallim ia vlen të shkruhet në runbook.

Nëse lidhja nuk vendoset kurrë, konfirmo që serveri po dëgjon në ndërfaqen që pret dhe që muri i tij i zjarrit lejon burimin që ai sheh vërtet. Një NAT e portës mund ta rishkruajë atë burim, kështu që një listë e lejuar e shkruar për adresën e tunelit të klientit mund të mos përputhet kurrë.

Kjo mospërputhje është dështimi SSH më i zakonshëm i vetëshkaktuar përmes një VPN.

Lexo fazën e dështimit, jo gabimin e kombinuar

Tri faza prodhojnë tri mesazhe të ndryshme, dhe vetëm njëri prej tyre ka të bëjë me kredencialet.

Përdor gabimin e saktë dhe regjistrin e vetë serverit në vend që të rivendosësh njëkohësisht kredencialet e VPN-së dhe të SSH-së. Rivendosja e të dyjave është mënyra se si një diagnostikim pesëminutësh bëhet një incident identiteti dyditor.

Dalja e detajuar tregon në cilën fazë ke arritur:

ssh -vv [email protected]

Mbaji çelësat e hostit dhe autorizimin të paprekur

Vërteto çelësin e hostit përmes procesit të synuar të besimit, veçanërisht pas një zëvendësimi serveri. Një paralajmërim i papritur për çelës të ndryshuar është pikërisht mesazhi që nuk duhet ta hedhësh poshtë vetëm sepse VPN u lidh, sepse një tunel privat nuk e bën destinacionin makinën që mendon se është. Kontrollo gjurmën e gishtit kundrejt një burimi të cilit i beson pavarësisht lidhjes.

Në anën e serverit, konfirmo që llogaria është e autorizuar dhe që metoda e vërtetimit që konfigurove është ajo që ofrohet. Një çelës i pranishëm por i anashkaluar është zakonisht një problem leje ose konfigurimi, jo rrjeti.

Kufizo aksesin e shërbimit te identitetet e nevojshme dhe mbaj një rrugë të autorizuar rikuperimi për ndryshimet e rrjetit.