LAN hostlarına DHCP 121 seçimi ilə VPN qayıdış marşrutu verin

Uzaq VPN müştəriləri qoşulur, LAN serveri cavab verir və cavab adi internet marşrutlaşdırıcısından keçib orada ölür. Bir serveri statik marşrutla düzəltmək olar, amma onların bütöv bir alt şəbəkəsini artıq şəbəkə konfiqurasiyasını aldıqları yerdə idarə etmək daha yaxşıdır. DHCPv4-ün 121 seçimi məhz bu cür təyinat marşrutunu paylayır və bu, insanların standart marşrutu unutduqları anda adətən səhv saldıqları hissədir. Simptom birtərəfli trafikdir: sorğular gəlir, cavablar yox olur.

Əvvəlcə üç ünvanı adlandırın

Konkret bir LAN götürün: 192.168.50.0/24, adi standart marşrutlaşdırıcı 192.168.50.1 ünvanında və ayrıca VPN şlüzü 192.168.50.2 ünvanında. Autentifikasiya olunmuş uzaq müştərilər 10.90.0.0/24 şəbəkəsini tutur.

Hər iştirakçı hostun ehtiyac duyduğu marşrut 10.90.0.0/24 via 192.168.50.2-dir. Təyinat müştəri hovuzudur, növbəti hop isə şlüzün tunel ünvanı deyil, LAN ünvanıdır.

Onu sinifsiz statik marşrut kimi kodlayın

121 seçimi prefiks və növbəti hop cütlərini daşıyır və RFC 3442 həm kodlaşdırmanı, həm də ona uyğun müştəri davranışını müəyyən edir. Yalnız bu nümunəvi LAN-a xidmət edən mövcud dnsmasq nüsxəsi üçün konfiqurasiya forması belədir:

dhcp-option=121,10.90.0.0/24,192.168.50.2,0.0.0.0/0,192.168.50.1

Bu bir fraqmentdir, yeni DHCP xidməti deyil. Bir neçə seqmentə xidmət edən serverdə seçimi artıq istifadə etdiyiniz teqlər və ya şəbəkə siyasəti ilə məhdudlaşdırın. Əvvəlki konfiqurasiyanı əlçatan saxlayın, çünki geri qaytarmaq yenidən başlatma deyil, başqa bir icarə yenilənməsi deməkdir.

Standart marşrutu itirməyin

Tələ budur. 121 seçimini alan müştəri adi Router seçimini nəzərə almamalıdır, buna görə yalnız VPN hovuzu marşrutunu elan etmək həmin hostu ümumiyyətlə standart marşrutsuz qoya bilər. Maşın hələ də konfiqurasiya olunmuş görünür və sakitcə interneti itirir. İstifadəçilər bunu hər interfeys işləyərkən şəbəkənin söndüyü kimi təsvir edir.

Nəzərdə tutulan standartı eyni siyahıya daxil edin, yuxarıdakı fraqmentin etdiyi kimi. Adi Router seçimini də yerində saxlayın, sinifsiz marşrutları tətbiq etməyən müştərilər üçün; kimə nə göndəriləcəyinə serverin öz seçim emalı qərar verir.

Müştərinin nəyi qəbul edəcəyini yoxlayın

Əl ilə ünvanlanmış host bunu heç vaxt götürmür, çünki icarə istəmir. Müştəri dəstəyi də fərqlidir, ona görə hər cihazın 121 seçiminə hörmət etdiyini güman etmək əvəzinə həqiqətən işlətdiyiniz əməliyyat sistemində sınaqdan keçirin. O serverlərə sahib olanlarla hansıların statik ünvanlandığını təsdiqləyin. Belə hostların öz marşrut qeydləri lazımdır, əks halda sadəcə iştirak etməyəcəklər.

İdarə olunan DHCP xidmətləri başqa bir məhdudiyyətdir. Bəzi bulud şəbəkələri administratorlara ixtiyari seçimlər yaymağa icazə vermir və eyni seqmentdə rəqib DHCP serveri heç seçim olmamasından pisdir.

İcarəni, sonra axtarışı yoxlayın

DHCP sahibindən dəyişikliyi tətbiq etməsini xahiş edin, sonra müştəridə icarəni yeniləyin. Mövcud icarələr yenilənənə qədər köhnə konfiqurasiyanı saxlayır, ona görə dərhal nəticə zəmanətli deyil.

Linux müştərisində faktiki marşrutları oxuyun və hər iki qeydi təsdiqləyin:

ip -4 route
ip -4 route get 10.90.0.23

Kontekstual axtarış hovuz marşrutunu 192.168.50.2 vasitəsilə, standartı isə 192.168.50.1 vasitəsilə göstərməlidir. Standart yoxdursa, yuxarıdakı tələni təkrar yaratmısınız.

Sonra real mübadiləni sınayın

Marşrut paylanması bütün yol deyil. Ayrıca şlüz hələ də yönləndirmə, uzaq peer sahibliyi və serverə icazə verən giriş siyasəti tələb edir, DHCP isə heç kimi autentifikasiya etmir.

Nəhayət, silmə planı saxlayın. Öyrənilmiş statik marşrut VPN düşəndə özünü geri çəkmir, buna görə köhnə növbəti hop tunel getdikdən çox sonra həmin prefiksi qara dəliyə çevirə bilər.