SSH üzərindən VPN klienti işə salırsınız? Əvvəlcə öz marşrutunuzu sabitləyin

SSH ilə bir qurğu hostuna qoşulur, orada VPN klientini işə salırsınız və sessiya cavab verməyi dayandırır. Heç nə çökməyib və heç nə açıq-aydın səhv konfiqurasiya olunmuş görünmür. Klient defolt marşrut quraşdırdı, buna görə iş stansiyanıza gedən cavablar indi tuneldən çıxır, halbuki iş stansiyanızın ünvanı orada marşrutlaşdırıla bilən deyil. Maraqlı hissə budur ki, bu nəticə proqnozlaşdırıla bilən idi və düzəliş klient başlamazdan əvvəl yazılan bir marşrutdur. Tək şəbəkə adapteri olan serveri, şlüzü 192.0.2.254 olan və 203.0.113.9 ünvanından qoşulan administratoru fərz edin.

Başlamazdan əvvəl yolu qeyd edin

ip route show default cari şlüzü və interfeysi göstərir, ip route get 203.0.113.9 isə kernelin sessiyanız üçün hansı interfeysi və mənbə ünvanını istifadə edəcəyini göstərir. Hər iki çıxışı saxlayın. Tunel qalxdıqdan sonra bu iki əmr yenə də fiziki yolu təsvir etməlidir və əgər onlar bunun əvəzinə tuneli təsvir edirsə, sessiya artıq borc alınmış vaxt hesabına yaşayır.

Əhəmiyyətli olan mövcud bağlantıdır, ona görə yalnız yeni girişlə yoxlamayın. Yeni sessiya köhnədə artıq olmayan vəziyyət sayəsində qısa müddət uğurlu ola bilər.

Ünvanı klientin öz konfiqurasiyasında sabitləyin

Əl ilə əlavə edilən marşrut yenidən başladıqda yox olur və klientin öz cədvəl yeniləmələri ilə yarışır, buna görə istisnanı cədvəlin idarə olunduğu yerə qoyun. OpenVPN altında net_gateway açar sözü tuneldən əvvəl mövcud olan şlüzə çevrilir, buna görə route 203.0.113.9 255.255.255.255 net_gateway onun xaricində dəqiq bir ünvan saxlayır. WireGuard fərqli yanaşma tələb edir, çünki wg-quick marşrutları özü idarə edir: Table = off ayarlayın və istisnanı PostUp içində əlavə edin, onu silən uyğun PostDown ilə birlikdə. Hər iki forma eyni niyyəti ifadə edir və hər ikisi istisnanı hər şey üçün tuneli zəiflətmək əvəzinə bir ünvanla məhdudlaşdırır.

IPv6 üçün eyni fikir tək host prefiksi götürür və sarılmış nəqliyyat halını xatırlamağa dəyər: əgər tunelin öz xarici bağlantısı sabit ünvanda yaşayırsa, həmin ünvan daşıdığı tuneldən kənarda qalmalıdır, əks halda klient öz nəqlini öz içinə yönləndirir.

Və ya əsas cədvəli mübahisədən çıxarın

Hostdakı bir neçə xidmət öz normal yolunu saxlamalı olduqda, əsas cədvəli redaktə etməyi dayandırın və klientə öz cədvəlini verin. veth cütü ilə şəbəkə adlar fəzası bunu təmiz şəkildə edir: klientin defolt marşrutu başqa yığında yaşayır və tuneldən yalnız onun içində başladılan proseslər istifadə edir. Siyasət marşrutlaşdırması bir təyinat üçün oxşar nəticəyə gəlir: uyğun trafiki defoltu hələ də fiziki şlüzə baxan xüsusi cədvələ göndərir. Hər iki yanaşma hostun əsas cədvəlini yeni defolt marşrutsuz qoyur və SSH-ı cavab verən saxlayan xüsusiyyət məhz budur.

Hər ikisi tək host marşrutundan daha çox mexanizmdir və qutudakı birdən çox şey tuneldən sağ çıxmalı olduqda hər ikisi buna dəyər.

Sabitləmənin uğursuz ola biləcəyini fərz edin

Cari ümumi ünvanınıza bağlanmış marşrut provayderiniz onu yenidən təyin etdiyi anda qırılır. Uzaq server o zaman həmin ünvandan asılı olmayan bir yol tələb edir: konsol, ikinci idarəetmə interfeysi və ya tuneldən kənarda qalan keçid hostu.

İki qoruyucu tədbir on dəqiqəyə başa gəlir. Bir neçə dəqiqə ərzində təsdiq girişi görünməzsə klienti dayandıran nəzarətçi bloklanmanı gecikməyə çevirir və dəyişiklik zamanı açıq saxlanılan ikinci SSH sessiyası tunel qalxanda istisnanın işlədiyini sübut edir. Təkcə keepalive mesajları burada kömək etmir, çünki yol boş deyil, artıq yoxdur; onlar yalnız ölümü görməyi asanlaşdırır.

Əhəmiyyətli ardıcıllıqla yoxlayın

Tuneli qoşun, ünvanınıza gedən marşrutun hələ də fiziki şlüzdən çıxdığını təsdiqləyin, sonra yeni sessiya açın. Əgər yeni sessiya işləyirsə və köhnəsi yenə də ölürsə, səbəb marşrutlaşdırma deyil, bağlantı izləməsi və ya vəziyyət saxlayan firewalldır və bu fərqli bir düzəlişdir.

Sabitlənmiş ünvanı və onu sübut edən əmri dəyişiklik qeydinə yazın. Həmin hostda klient işə salacaq növbəti şəxs hər ikisinə ehtiyac duyacaq və ünvan o vaxta qədər dəyişmiş ola bilər.