Yönləndirilmiş OpenVPN tuneli üzərindən ad axtarışları niyə uğursuz olur

Host ping-ə ünvanla cavab verir, ada görə hər axtarışda isə uğursuz olur. Tunel işləyir və marşrut mövcuddur, ona görə də təbii nəticə VPN-in səhv konfiqurasiya edildiyidir. Daha faydalı nəticə bundan ibarətdir ki, axtarış heç vaxt marşrutlaşa bilməzdi: yönləndirilmiş tunel unicast IP daşıyır, sözügedən sorğu isə o biri tərəfdə mövcud olmayan seqmenti axtaran yayım idi. Qat uyğunsuzluğu görünən kimi düzəlişlər özlərini maya dəyərinə görə sıralayır.

Mif: adlar uğursuz olduğu üçün tunel sınıb

Simptom inandırıcıdır, çünki ad qatından yuxarıda olan hər şey işləyir. Ünvanlar yönləndirilir, interfeys işləkdir və peer ping-ə cavab verir. Uğursuz olan, nöqtədən-nöqtəyə keçid üzərindən heç vaxt yolu olmayan aşkarlama mexanizmidir və bu, sınıq tuneldən fərqli bir ifadədir. Bu iki ifadəni ayırmaq diaqnozun çox hissəsidir.

Bunu tunel nasazlığı kimi qəbul etmək kömək edə bilməyən profil düzəlişlərinə gətirib çıxarır. Seçimlər əlavə etmək, şifrləməni dəyişmək və ya klienti yenidən quraşdırmaq yayımı elə olduğu yerdə saxlayır.

Düzəlişi adlandırmazdan əvvəl uğursuz olan mexanizmi adlandırın. Yayımdan istifadə edən axtarış seqmentə ehtiyac duyur, həlledicidən istifadə edən axtarış isə soruşacaq ünvana ehtiyac duyur.

TUN nə daşıyır, nə daşımır

TUN cihazı IP interfeysidir və onu marşrutlaşdırıla bilən edən də budur. OpenVPN klientə ünvan və marşrutlar dəsti verir, bundan sonra klient dataqramları peer-ə göndərir. Bu modeldə hər hostun hər kadrı eşitdiyi bir paylaşılan keçid yaradan heç nə yoxdur.

Aşkarlama trafiki bu modelə heç uyğun gəlmir. Köhnə Windows ad sorğuları, SSDP elanları və mDNS tələbləri bir təyinat yerinə deyil, seqmentdəki hamıya göndərilir. Yönləndirilmiş keçiddə göndəriləcək «hamı» yoxdur. Bu mexanizmlərin hər biri paylaşılan mühiti fərz edir.

Buna görə tunel sağlam ola bilər, aşkarlama isə tamamilə uğursuz ola bilər. Kimsə VPN-in söndüyünü bildirdikdə yapışmalı olduğunuz cümlə məhz budur.

Körpü sərhədi aradan qaldırmaqla işləyir

TAP cihazı kadrlar daşıyır və körpü onu real LAN seqmentinə qoşur. Sonra klient həmin seqmentdə ünvan saxlayır və onun yayım trafikini eşidir. Körpünün ad problemini sağaltdığı görünməsinin səbəbi budur. Bu həm də klienti ünvanlama üçün həmin seqmentdən asılı edir.

Çarə marşrut sərhədinin aradan qaldırılmasıdır, tunelin içində hər hansı yeni adlandırma qabiliyyəti deyil. Seqmentin yayımladığı hər şey artıq keçiddən də keçir.

Kiçik bir laboratoriya üçün bu ədalətli mübadilədir. Dağınıq işçi qüvvəsi üzrə isə nadir hallarda belədir.

DNS və WINS ötürmək daha dar düzəlişdir

Klientə soruşacağı konkret bir yer verin. dhcp-option DNS və dhcp-option DOMAIN daxili adları zonanı bilən serverə yönəldir, hələ də NetBIOS-a güvənən Windows klienti isə eyni yolla WINS serveri ala bilər. Tunel yönləndirilmiş qalır, seqment də öz yerində qalır.

İki şərt bunun işləyib-işləmədiyini həll edir. Adı çəkilən server zona üçün cavab verməlidir və sorğuya tuneldən keçməyə icazə verilməlidir.

Həlledicini serverin öz qabığından deyil, klientdən sınaqdan keçirin. Lokal olaraq işləyən həlledici tunelin nə daşıdığı barədə heç nə demir.

Hansı qatın uğursuz olduğunu öyrənin

Əvvəlcə ünvana ping vurun, sonra adı həll edin və hansı serverin cavab verdiyini oxuyun. Zonanı yerləşdirməyən serverdən gələn mənfi cavab, maşından heç çıxmayan sorğudan fərqli görünür. Həll olunan, lakin bağlantıları rədd edən ad isə tamamilə üçüncü bir problemdir.

Multicast eyni divarın arxasındadır. 224.0.0.251 kimi bir qrup defolt olaraq yönləndirilmiş tuneldən ötürülmür və qrup üçün marşrut, multicast-ı anlayan yol və ya LAN-da reflektor olmadan kifayət etmir.