VPN vasitəsilə uzaq SSH: tunelin nə etmədiyi

VPN SSH serverinə xüsusi yol verir və 22-ci portda açıq dinləyiciyə ehtiyacı aradan qaldırır. O, hostu autentifikasiya etmir, istifadəçini səlahiyyətləndirmir və hansı hesabların daxil ola biləcəyini qərar vermir. Bunlar SSH-in işidir. VPN-in serverə çatmaq üçün düzgün üsul olub-olmadığı üç şərtdən asılıdır və tunel yalnız mümkün cavablardan biridir.

Tunel nəyi dəyişir və SSH hələ nəyə qərar verir

Tunel əlçatanlığı dəyişir: hansı ünvanlara çatmaq mümkündür və haradan. O, TCP bağlantısı yerə çatdıqdan sonra baş verənləri dəyişmir; orada server host açarı təqdim edir və istifadəçi kimliyini tələb edir.

İki qatı həm beyninizdə, həm də sənədlərinizdə ayrı saxlayın. VPN girişi şəbəkədən kimin istifadə edə biləcəyini sübut edir. O, hədəfdə hansı hesabların olduğu barədə heç nə demir və hər əlçatan maşına daxil olmaq üçün icazə deyil.

Uğursuzluq rejimləri də ayrıdır və bu ayrılıq hadisə zamanı faydalı olur.

Giriş modelini müəyyən edən üç şərt

Birincisi, server şəbəkənizdən kənardakı insanlar üçün əlçatan olmalıdır? Əgər yoxsa, xüsusi yol üstəgəl bastion və ya mesh daha kiçik dizayndır. İkincisi, müştəri kütləsi, o cümlədən məhdudiyyətləri olan idarə olunan cihazlardakılar, VPN müştərisini həqiqətən işlədə bilirmi?

Üçüncüsü, hər xidmət üzrə nəzarət, yoxsa hər istifadəçi üzrə nəzarət lazımdır? VPN şəbəkə çıxışı verir; SSH hesab girişi verir. Tələb podratçının bir hosta çatması və başqa heç nəyə çatmamasıdırsa, bu səlahiyyətləndirmə tələbidir və yalnız tunel bunu ifadə edə bilməz.

Bu üçünə cavab verin və model özünü seçir. Onları atlayın və müştəri yayımından qaçmaq üçün SSH-i açıq şəkildə ifşa edirsiniz.

SSH-i günahlandırmadan əvvəl xüsusi yolu təsdiqləyin

Təsdiqlənmiş VPN-ə qoşulun və hədəfin sənədləşdirilmiş xüsusi adını və ya ünvanını istifadə edin. Sonra seçilmiş marşrutu, şlüzün icazəsini və müştəriyə geri yolu yoxlayın. Düzgün həll olunan ad ünvanın nəzərdə tutulan tunelə getdiyini sübut etmir, çünki üst-üstə düşən yerli və uzaq prefikslər sorğunu tamamilə başqa yerə göndərə bilər. Bu fərq runbook-a yazılmağa dəyər.

Bağlantı heç vaxt yerə çatmırsa, serverin gözlədiyiniz interfeysdə dinlədiyini və host firewallunun həqiqətən gördüyü mənbəyə icazə verdiyini təsdiqləyin. Şlüz NAT-ı bu mənbəni yenidən yaza bilər, buna görə müştərinin tunel ünvanı üçün yazılmış icazə siyahısı heç vaxt uyğun gəlməyə bilər.

Bu uyğunsuzluq VPN üzərində ən çox rast gəlinən öz-özünə yaradılmış SSH nasazlığıdır.

Birləşdirilmiş xətanı deyil, uğursuzluq mərhələsini oxuyun

Üç mərhələ üç fərqli mesaj yaradır və onlardan yalnız biri etimadnamələrlə bağlıdır.

Hər iki VPN və SSH etimadnamələrini birlikdə sıfırlamaq əvəzinə dəqiq xətanı və serverin öz jurnalını istifadə edin. İkisini birlikdə sıfırlamaq beş dəqiqəlik diaqnozun iki günlük kimlik hadisəsinə çevrilmə üsuludur.

Ətraflı çıxış hansı mərhələyə çatdığınızı göstərir:

ssh -vv [email protected]

Host açarlarını və səlahiyyətləndirməni toxunulmaz saxlayın

Host açarını nəzərdə tutulan etibarlı proseslə yoxlayın, xüsusən server dəyişdirildikdən sonra. Gözlənilməz dəyişmiş açar xəbərdarlığı VPN qoşuldu deyə laqeyd qala bilməyəcəyiniz yeganə mesajdır, çünki xüsusi tunel təyinatı düşündüyünüz maşın etmir. Barmaq izini bağlantıdan asılı olmayaraq etibar etdiyiniz mənbə ilə yoxlayın.

Server tərəfində hesabın səlahiyyətli olduğunu və konfiqurasiya etdiyiniz autentifikasiya metodunun təklif olunan metod olduğunu təsdiqləyin. Mövcud olan, lakin nəzərə alınmayan açar adətən şəbəkə deyil, icazə və ya konfiqurasiya problemidir.

Xidmət çıxışını tələb olunan kimliklərlə məhdudlaşdırın və şəbəkə dəyişiklikləri üçün səlahiyyətli bərpa yolu saxlayın.