Nə üçün LAN hostu OpenVPN müştəri ünvanına ARP göndərir

LAN hostu ilə VPN müştərisi arasındakı əlçatanlıq problemləri çox vaxt ünvan planının özünə gedib çıxır. Bu hosta 10.0.100.0/22 üzərində interfeys verin və o, 10.0.100.0-dan 10.0.103.255-ə qədər hər ünvanı, 10.0.101.0/24 üzərində səssizcə yerləşdirilmiş müştəri hovuzu da daxil olmaqla, birbaşa qoşulmuş hesab edəcək. Cavab heç vaxt marşrutlaşdırıcıya getmir, çünki hostun baxış bucağından heç bir marşrutlaşdırıcı iştirak etmir. Paket qonşuya ünvanlanır və naqildə tələb olunur.

Bu mexanizm bütöv bir hesabat ailəsinin arxasında durur: tunel açıqdır, serverin marşrutu var və LAN hostu yenə də müştəriyə çata bilmir.

/24-ü udan /22

Prefiksi sətir kimi deyil, diapazon kimi oxuyun. /22 prefiksdə 1024 ünvan var və 10.0.100.0/22 10.0.100.0-dan 10.0.103.255-ə qədər uzanır, buna görə 10.0.101.0/24 üzərindəki hovuz tamamilə onun içində qalır. Səhv yoxlamadan keçir, çünki hovuzun ilk oktetləri LAN-ın ilk oktetlərindən fərqli görünür və yalnız üçüncü oktet iç-içəliyi aşkara çıxarır. Onları ayrı elan etməzdən əvvəl hər iki diapazonu rəqəmlərlə yazın.

Eyni iç-içəlik tərs istiqamətdə də görünə bilər. Hazırda heç kim istifadə etmədiyi üçün boş görünən hovuz yenə də hansısa sayt marşrutlaşdırıcısının elan etdiyi prefiksin içinə düşə bilər və ünvan planı bunu göstərən yeganə sənəddir.

Birbaşa əlaqə ARP deməkdir, marşrutlaşdırma deyil

/22 interfeysi olan host 10.0.101.25-ə göndərdikdə, nüvə təyinatı interfeysin prefiksi ilə müqayisə edir və uyğunluq tapır. Paket marşrutlaşdırılmış paket əvəzinə qonşu axtarışına çevrilir və Ethernet-də qonşu axtarışı həmin ünvan üçün ARP sorğusudur. Əgər ünvan marşrutlaşdırılmış şlüzün arxasındakı VPN müştərisinə aiddirsə, LAN-da heç bir host ona sahib deyil, buna görə sorğu cavabsız qalır və paketlər atılır. Tunel günahkar deyil və müştəri trafiki heç vaxt görmür.

Buna görə nasazlıq asimmetrik və bəzən kəsintili görünür. VPN hostu çox vaxt LAN-a çatır, çünki öz marşrutları düzgün istiqaməti göstərir, halbuki LAN hostu cavab verə bilmir və köhnə ARP qeydini keşləyən hər şey simptomu titrədir.

TUN, TAP və hər birinin daşıdığı

TUN cihazı IP paketləri, TAP cihazı isə Ethernet çərçivələri daşıyır. Marşrutlaşdırılmış TUN əlaqəsi IP əlçatanlığını təmin etmək üçün ARP daşımalı deyil və yuxarıdakı cavabsız sorğunun gözlənilən olmasının səbəbi məhz budur. Qəsdən qurulmuş körpü ilə TAP yayım domenini genişləndirə və ARP-ni işlədə bilər, lakin müştərinin nə görə biləcəyini dəyişir, eyni çərçivələməni dəstəkləyən son nöqtələr tələb edir və üst-üstə düşən prefiks üçün təmir deyil, şəbəkə modelinin yenidən dizaynıdır. Marşrutlaşdırılmış quraşdırmanı ünvan planı səhvini sağaltmaq üçün TAP-a keçirmək kiçik problemi daha böyüyü ilə dəyişir.

Nəticə çıxarmazdan əvvəl ARP sorğusunun harada yarandığını və hansı sistemin göndərdiyini qeyd edin. Göndərən sizə təyinat haqqında nə düşündüyünü deyir, tunelin nə etdiyini deyil.

Üst-üstə düşə bilməyən hovuz dizayn edin

Hər qoşulmuş prefiksdən və hər elan edilmiş sayt prefiksindən kənarda hovuz seçin, sonra onu hər iki istiqamətdə əlçatan edən marşrutları əlavə edin. Planın istifadə olunmayan hissəsində 10.8.0.0/24 kimi diapazonu düşünmək asandır və ona çatmalı olan LAN VPN serverinə işarə edən statik marşrut alır. Ayrılmanı, elan edilmiş marşrutları, icazə verilən mənbə ünvanlarını və firewall qaydalarını birlikdə dəyişin, çünki onlar dörd ayar deyil, bir dizayn təsvir edir.

Serverdəki Source NAT hovuzu LAN-dan marşrutlaşdırıla bilən ünvanın arxasında gizlədə bilər və bu, qanuni miqrasiya alətidir. O, mənbəni də yenidən yazır, buna görə LAN əlaqələri fərdi müştərilərə aid etmək və müştəri üzrə qaydalar tətbiq etmək qabiliyyətini itirir.

Qəbul üçün real müştərinin faktiki təyin edilmiş ünvanını və LAN hostundan real tətbiq sorğusunu istifadə edin, sonra cavabın naqili deyil, planlaşdırılmış şlüzü izlədiyini təsdiqləyin.