Host xarici VPN işlədəndə yerli SSH-ı saxlayın

Kiçik bir Linux serveri host etdiyi tətbiq üçün xarici VPN işlədir, administrator isə yenə də qonşu otaqdakı masadan ona SSH ilə çatmaq istəyir. Bu ağlabatan tələbdir və adətən nə port yönləndirməsi, nə provayder ünvanı, nə də tuneldə deşik tələb edir. Lazım olan şey, VPN müştərisinin marşrut cədvəli ilə nə etdiyindən miras qalan deyil, qəsdən dizayn edilmiş bir idarəetmə yoludur.

Aşağıdakı addımlar administratorun eyni LAN-da olduğunu fərz edir.Uzaqdan idarəetmə fərqli cavabı olan fərqli bir problemdir.

SSH-ı administratorların istifadə etdiyi ünvana bağlayın

Dinləyicidən başlayın.ss -ltnp | grep :22 sshd-nin nəyə bağlandığını göstərir və 0.0.0.0 üzərindəki dinləyici tunel də daxil olmaqla hər interfeysdən bağlantı qəbul edir. LAN ünvanına bağlamaq daha dardır və niyyəti görünən edir:ListenAddress 192.168.10.20 daxilində sshd_config, ardınca konfiqurasiya testi və yenidən yükləmə. Həmin ünvandakı yazı səhvi vəhşi kartdan daha görünəndir, çünki ünvan mövcud olmadıqda sshd başlamaqdan imtina edir.

Host açarı yoxlamasını və istifadəçi üzrə autentifikasiyanı olduğu kimi saxlayın. “Bu sadəcə yerli şəbəkədir” autentifikasiya üsulu deyil və marşrut qısa olduğu üçün açar yoxlamasını atlayan idarəetmə kanalı sui-istifadəni gözləyən idarəetmə kanalıdır. DHCP rezervasiyası və ya statik ünvan hədəfi gözlənilən edir, onu serverin ictimai kimliyinə çevirmədən.

LAN marşrutunu tuneldən kənarda saxlayın

192.168.10.0/24 üzərində ünvanı olan hostun həmin prefiks üçün qoşulmuş marşrutu var və daha dəqiq marşrut eyni cədvəl daxilində VPN-in defoltunu üstələyir. Buna görə yerli SSH tunel qalxdıqda çox vaxt öz-özünə işləməyə davam edir. Fərz etmək yerinə bunu yoxlayın:ip route get 192.168.10.50 nüvənin istifadə edəcəyi interfeysi və mənbə ünvanını göstərir və cavab tunel deyil, LAN cihazı olmalıdır. Yoxlamanı administratorun maşınından da təkrarlayın, çünki paketlərin ümumiyyətlə çatıb-çatmayacağına onun öz cədvəli qərar verir. Eyni naqildə olan iki host hansı istiqamətin əlçatan olduğu barədə fikir ayrılığına düşə bilər.

Fərz iki yerdə pozulur. Siyasət əsaslı marşrut qaydası trafiki əsas cədvələ baxılmadan əvvəl defoltu tunelə yönələn cədvələ göndərə bilər. Kilid və ya kill-switch funksiyası olan VPN müştərisi də tunelə girməyən trafiki bloklaya bilər, marşrut cədvəlinin nə dediyindən asılı olmayaraq.

Marşrutlaşdırılmış idarəetmə VLAN-ları digər haldır. Administrator yerli marşrutlaşdırıcının arxasında 192.168.50.0/24 üzərində oturursa, serverin həmin prefiks üçün 192.168.10.1 vasitəsilə açıq marşrutu olmalıdır və bu marşrut yenidən qoşulmaya dözməlidir. İstisnanı idarəetmə prefiksi ilə konkret saxlayın; şəxsi diapazonlar üçün geniş istisna tunelin məqsədini puça çıxarır.

Firewall istisnasını qayda qədər dar edin

Host firewall işlədirsə, SSH-a yalnız idarəetmə mənbəyindən və yalnız LAN interfeysində icazə verin. Hər yerdən 22 portuna icazə verən qayda tələbdən daha genişdir və yoxlamada əsaslandırmaq daha çətindir. nftables hostunda qayda interfeys və mənbənin uyğunlaşdırıldığı giriş zəncirinə aiddir; iptables hostunda ekvivalent -i və -s üzrə iki uyğunlaşdırma cütüdür. Qaydaya xidmət etdiyi administrator qrupunu şərh kimi yazın ki, növbəti audit 22 portunun niyə açıq olduğunu təxmin etməsin.

VPN müştərisinin öz filtrini də yoxlayın. Bəzi müştərilər dizayn olaraq yerli trafiki atan qaydalar quraşdırır və müştəri səviyyəsindəki atmanın üstünə qoyulan düzgün firewall qaydası heç nəyi dəyişmir. Host firewall-unu redaktə etməzdən əvvəl müştərinin konfiqurasiyasını oxuyun, çünki ardıcıl iki filtr heç birinə bənzəməyən nasazlıq yaradır.

Hər iki vəziyyəti yoxlayın

Testi iki dəfə keçirin: bir dəfə tunel qoşulmuş, bir dəfə isə ayrılmış halda. Hər vəziyyətdə dinləyicini, marşrutu və administratorun maşınından real SSH girişini təsdiqləyin. Yalnız tunel qalxanda işləyən yol yerli idarəetmə yolu deyil; bu təsadüfdür.

Sonra SSH sessiyası açıq ikən tuneli yenidən başladın. Yaşayan sessiya marşrutlaşdırmanın sabit olduğunu sübut edir; düşən sessiya isə müştərinin yenidən qoşularkən marşrutları və ya filtrləri yenidən yazdığını deyir, bunu hadisədən əvvəl bilmək, hadisə zamanı bilməkdən yaxşıdır.

Test etdiyiniz mənbə ünvanını qeyd edin, çünki 192.168.10.50 üçün yazılmış qayda administratorun noutbuku başqa alt şəbəkəyə keçəndə səssizcə uğursuz olur.

Bərpa yolunu runbook-a yazın

Xarici VPN yerli yolu pozarsa nə olacağına indi qərar verin. Konsol girişi, ikinci idarəetmə ünvanı və ya müştərini dayandırmaq üçün sənədləşdirilmiş prosedur hamısı qanuni cavablardır və hər biri problemi daxil olmağa ehtiyac duyduğunuz anda aşkar etməkdən yaxşıdır. Server uzaqdırsa, yerli yol mövcud deyil və düzgün dizayn açıq ictimai port deyil, ayrıca təsdiqlənmiş uzaq giriş marşrutu və ya bastiondur.

Sənədləşdirmədə iki rolu ayrı saxlayın: yaxınlıqdakı administrator üçün yerli SSH və tətbiqin trafiki üçün xarici tunel. Bu rollar yazıya alındıqda hər hansı birinə gələcək dəyişikliyin yoxlanacağı aydın yer olur və növbəti şəxs VPN işlədən serverin niyə hələ də LAN ünvanında cavab verdiyini yenidən kəşf etmək məcburiyyətində qalmır.