FortiClient tam tunel: yalnız ofis alt şəbəkəsini yönləndirin

Tunel qalxır, ikon yaşıl olur və yerli şəbəkə yox olur: printerlər, NAS və ofis marşrutlaşdırıcısı cavab verməyi dayandırır. FortiClient profilin tələb etdiyini edir. Şlüz standart marşrut göndərdi, müştəri onu quraşdırdı və indi hər paketin tunelə gedən yolu var. Düzəliş marşrut cədvəlinin redaktəsi və onun arxasında DNS redaktəsidir; bu redaktələrin sırası maşının daha yaxşı və ya daha pis qurtarmasını həll edir.

Müştəri nə quraşdırdı və LAN niyə yox oldu

Müştəri interfeysi yerinə cədvəli oxumaqla başlayın. macOS-də netstat -rn bütün cədvəli çap edir, route -n get default isə hazırda qalib gələn interfeysi və metrikanı göstərir; Linux-da cüt ip route show və ip route get 8.8.8.8-dir. Hər ikisi bir suala cavab verir: daha dəqiq heç nəyə uyğun gəlməyən paketi hansı giriş daşıyacaq.

Tunel cihazının adı sabit deyil. macOS-də IKEv2 profili adətən nömrə ilə utun göstərir, SSL VPN müştərisi ppp0, OpenVPN isə tun0 göstərir. Eyni anda fərqli metrikalarla iki standart marşrut da ola bilər və müştəri girişi göründüyü anda deyil, yalnız yenidən qoşulmadan sonra ələ keçə bilər. Buna görə beş dəqiqə fərqlə götürülmüş iki cədvəl çıxarışı fərqli hekayələr danışa bilər.

Tunel standart marşrutu niyə əvvəl getməlidir

Nüvə ən uzun uyğun prefiksi seçir və bir neçə marşrut eyni dərəcədə dəqiq olduqda ən aşağı metrikalı olanı seçir. Buna görə 0.0.0.0/0-i daha yaxşı metrika ilə quraşdıran müştəri orijinal standartı silmədən hər təyinatı qazanır; fiziki marşrutun hələ də cədvəldə olması və kəsintini hələ də izah etməsi buna görədir. Əvvəlcə tunel standartını silmək əvvəlki davranışı bərpa edir. Yalnız bundan sonra tuneldən keçən prefiks marşrutu müəllifin nəzərdə tutduğunu edir.

Bu addımdan əvvəl prefikslər əlavə etmək yarım işləyən maşın yaradan səhvdir. Yeni prefiksin trafiki tunelə gedir və siyahıda olmayan hər şey də tunel standartına gedir, ona görə heç kim əlavə etmədiyi xidməti açana qədər heç nə pozulmuş görünmür. Silin, bərpa edin, sonra əlavə edin və aralıq vəziyyət proqnozlaşdırıla bilən qalsın.

macOS və Linux-da ardıcıllıq

macOS-də ardıcıllıq tunel standartını silir, fiziki standartı bərpa edir və bir ofis prefiksini tunelə geri göndərir. Buradakı nümunə interfeys adlarını öz cədvəlinizdəki adlarla dəyişin.

sudo route delete -net default -interface utun4
sudo route add -net 0.0.0.0 -interface en0
sudo route add -net 10.20.0.0 -netmask 255.255.0.0 -interface utun4

Linux-da eyni sıra fərqli alətdən istifadə edir: standart üçün LAN şlüzü, ofis prefiksi üçün tunel cihazı. Köhnə route əmri hələ də köhnə sintaksisi qəbul edir, lakin ip route cari sənədlərə uyğun formadır.

sudo ip route del default dev tun0
sudo ip route add default via 192.168.50.1
sudo ip route add 10.20.0.0/16 dev tun0

Marşrut cihaz yerinə növbəti hopp tələb etdikdə, peer-i müştəri çıxışından götürün. Təxmin iki səhvdən birini verir və onlar fərqli məna daşıyır: səhv şlüz dərhal network unreachable verir, səhv tunel hədəfi isə timeout verir. Əmri yenidən dəyişməzdən əvvəl hansını aldığınızı oxuyun.

Prefikslər, həlledici və qaranlıq qalan DMZ

Bir prefiks işi nadir hallarda örtür. Tətbiq serverləri, idarəetmə şəbəkələri, DMZ və DNS serverlərinin özü hər biri fərqli diapazonda ola bilər, ona görə başlamazdan əvvəl adını çəkə bildiyiniz hər diapazonu sadalayın və hər ping-in yanında bir sorğunu sınayın. Sınaq zamanı aşkar edilən təyinat dəyişiklik qeydində unudulan təyinatdır. Ünvana görə cavab verib ada görə uğursuz olan marşrut adətən yönləndirmə kostyumu geyinmiş həlledici problemidir.

Həlledici ayrı qərardır. Profil daxili DNS serverlərini göndərdikdə, standartın götürülməsi bu ünvanları açıq adlar üçün əlçatmaz və ya yalnız tuneldən əlçatan qoya bilər və hər iki vəziyyət qarışıq qismən nəticələr verir. Həlledici ünvanlarını tuneldən keçirin və ya domen üzrə həlli qurun ki, açıq sorğular yerli həlledicidən istifadə etsin.

Linux SSL müştərisinin bilməyə dəyər sahəyə xas nasazlığı var: tunel qoşulur, ofis LAN-ı cavab verir və bir DMZ diapazonu qaranlıq qalır. Çatışmayan hissə həmin diapazon üçün tunel şlüzündən keçən marşrutdur və şlüz maşından maşına dəyişir, ona görə sərt kodlanmış ünvan növbəti noutbukun necə sındığıdır. Onu müştəri vəziyyətindən çıxarın və əmri özünü sənədləşdirən saxlayın:

PEER=$(ip -4 addr show dev ppp0 | awk '/peer/ {print $4}' | cut -d/ -f1)
sudo ip route add 192.168.30.0/24 via "$PEER"

İşə salmazdan əvvəl iki dəyəri oxuyun. peer nöqtədən nöqtəyə tunelin uzaq ucudur və DMZ marşrutunun ehtiyac duyduğu ünvandır; yönləndirilən tuneldə ekvivalent müştərinin bildirdiyi interfeys və ya şlüzdür. Heç biri görünmürsə, müştəri güman etdiyiniz rejimdə deyil.

Növbəti qoşulmadan sonra və bu işi yerli olaraq nə vaxt dayandırmalı

FortiClient yuxudan və ya şəbəkə dəyişikliyindən sonra yenidən qoşulur və profilin göstərdiyini yenidən quraşdırır. Buna görə əl ilə yaradılan marşrutlar yalnız növbəti qoşulmaya qədər yaşayır; bu, bir uğurlu sınağın düzəliş kimi görünə biləcəyi aralığın özüdür. Gecə yox olan marşrut gözlənilən davranışdır, yeni nasazlıq deyil.

İki davamlı cavab var. Hər qoşulmadan sonra düzəlişi yenidən işə salan skript müəllifindən uzun yaşaya bilən müvəqqəti həlldir, halbuki şlüz administratorundan bölünmüş tunel profili əsl düzəlişdir, çünki o zaman müştəri yalnız işin lazım olduğu diapazonları quraşdırır. İkincisini istəyin və birincini yalnız gözləyərkən istifadə edin. Tam tuneli yerli olaraq bölməzdən əvvəl razılaşdığınız siyasəti də yoxlayın, çünki uzaq şəbəkə bütün trafikinizi görməyə arxalana bilər.

Yoxlama siyahısı qısadır: cədvəli oxuyun, tunel standartını silin, LAN standartını bərpa edin, hər prefiksi əlavə edin, həlli ayrıca düzəldin və yenidən qoşulmada marşrutların qayıdacağını gözləyin.