MikroTik PPTP qopur? Serverə marşrutu düzəldin

RouterOS PPTP klienti qoşulur, bir az trafik ötürür və sonra ölür, jurnal isə etimad məlumatları və ya server problemi kimi görünür. Adətən heç biri deyil. Tunel öz nəqliyyat paketlərini daşıyır, çünki serverə gedən marşrut tunelin quraşdırdığı marşrutla da üst-üstə düşür. Qarşı tərəf routerdən heç nə eşitmir və interfeys hələ də işlək olduğunu bildirsə də, sessiya ölür.

Düzəliş bir marşrut, ya da bir ayardır: serveri fiziki WAN üzərindən əlçatan saxlayır. Hansının lazım olduğu routerin tam tunel şlüzü olub-olmamasından asılıdır.

Simptom: qoşulur, trafik ötürür, ölür

Naxış hər yenidən qoşulmada təkrarlanır və bu, ilk faydalı ipucudur. Rədd edilən parol interfeys qalxmadan əvvəl uğursuz olur, firewall səhv konfiqurasiyası adətən bir istiqaməti bloklayır, marşrut dövrəsi isə interfeysin qalxmasına imkan verib sonra onu boğur. Sayğacları izləyin: tunel ilkin paketlərdən ibarət bir partlayış göstərir, sonra heç nə, halbuki WAN interfeysi kapsullanmış surətləri göndərməyə davam edir. Bu, öz çıxışını yenidən özünə verən routerdir.

PPTP bunu asan tetikləyir, çünki nəqliyyat serverin ünvanına düz IP-dir, digər ucu başqa altşəbəkədə olan tunel deyil. Bu ünvanı yönləndirən hər şey nəqliyyatı da onunla yönləndirir.

Tunel niyə öz paketlərini udur

Klient qoşulduqda şlüzü tunel interfeysi olan bir marşrut quraşdırır. Profil həm də defolt marşrut quraşdırırsa, daha dəqiq uyğunluğu olmayan hər təyinat, o cümlədən serverin ictimai ünvanı, tunelə çevrilir. Router paketi kapsullayır, xarici paketi serverə ünvanlayır və marşruta yenidən baxır: eyni təyinat, eyni defolt, eyni tunel. Buraxılışdan asılı olaraq bu rekursiya atılır, növbəyə qoyulur və ya qarşı tərəf əl çəkib sessiyanı bağlayana qədər dövrəyə salınır.

Cihaz istehsalçıları çox vaxt öz serverləri üçün avtomatik host marşrutu əlavə edir, məhz bunun qarşısını almaq üçün. RouterOS bunu fərz etmir, ona görə operator ya istisnanı ifadə etməli, ya da defolt marşrutdan əvvəldən çəkinməlidir.

Server ünvanını WAN-a bağlayın

Mümkün olan ən dar marşrutu əlavə edin: serverin ictimai ünvanı üçün /32, növbəti hop kimi provayder şlüzü ilə, internetə çıxan interfeysdə. /32 prefiks uzunluğuna görə hər hansı defoltu üstələyir və əgər eyni prefiks üçün başqa marşrut artıq varsa, daha aşağı məsafə qalib gəlir. Sonra yenidən qoşulun və marşrutun sadəcə siyahıda görünmədiyini, aktiv olduğunu təsdiqləyin.

/ip route add dst-address=198.51.100.10/32 gateway=192.0.2.1 distance=10

Provayder şlüzü DHCP ilə öyrənilirsə, DHCP-nin quraşdırdığı şlüz ünvanından istifadə edin və ya buraxılış dəstəkləyirsə marşrutu interfeysə bağlayın. Növbəti icarədə dəyişən sərt kodlanmış şlüz gecikmiş nasazlıqdır. Ünvanı WAN yenidən qoşulduqdan sonra yoxlayın, çünki köhnəlmiş şlüz o zaman üzə çıxır və tunel yenidən qopmağa başlayır.

Və ya tunelin defoltu ələ keçirməsini dayandırın

Tək bir uzaq LAN-a ehtiyacı olan filial PPTP profilini defolt marşrutdan tamamilə uzaq saxlamalıdır. Bu seçimi klient profilində söndürün və əvəzində uzaq prefiks üçün tunel interfeysindən keçən xüsusi marşrut əlavə edin. Adi trafik WAN-da qalır, tunelin öz nəqliyyatı təbii yolunu saxlayır və marşrut cədvəlini izah etmək asanlaşır. Bu, bir altşəbəkəyə ehtiyacı olan filial üçün daha yaxşı dizayndır, saytın çıxışı olmalı olan router üçün deyil.

Tam tunelin öz tələbləri var: seçilmiş mənbələr üçün siyasət əsaslı marşrutlaşdırma, qayıdış trafiki üçün plan və tunel qopduqda nə olacağına dair qərar. Bunların heç birini host marşrutu həll etmir, o yalnız nəqliyyatı canlı saxlayır.

Qatlarla yoxlayın, sonra idarəetmə dəliyini bağlayın

Qatlarla sınaqdan keçirin: qoşulmadan əvvəl serverin ictimai ünvanına ping edin, qoşulduqdan sonra uzaq şlüzə ping edin, sonra uzaq LAN-dakı bir hosta ping edin. Routerin arxasındakı hostların cavabların ondan geri qayıtmasına ehtiyacı varsa, tunel interfeysinə masquerade əlavə edin.

/ip firewall nat add chain=srcnat out-interface=pptp-out1 action=masquerade

Sonra routeri yenidən başladın və ya WAN-ın yenidən qoşulmasını məcbur edin və üç ping-i təkrarlayın, çünki yalnız işlək konfiqurasiyada mövcud olan marşrut qalmayacaq. Ehtiyat faylına ixrac edilib sonra bərpa olunan konfiqurasiya bunun pozulduğu digər yerdir, çünki marşrut işləmə zamanı əlavə olunubsa, ixracda ola bilməz.

Nəhayət, hər hansı VPN və ya marşrut dəyişikliyini dərc etməzdən əvvəl Winbox və veb idarəetməsini tanınmış mənbə ünvanları ilə məhdudlaşdırın. Tunelləri sonlandıran router idarəetmə hədəfidir və dünyaya açıq port 80 indicə düzəltdiyiniz marşrutdan daha böyük tapıntıdır.