VPN ünvanı LAN DHCP icarəsi ilə: tunel IP-sini kim verir?

Müştərini qoşun və Wi-Fi ikonasına deyil, adapterə baxın. 10.80.0.14 kimi bir ünvan tuneldə otura bilər, halbuki ofis LAN-ındakı heç bir DHCP serveri o icarəni qeydə almayıb. Nömrəni hansı prosesin seçdiyi, nasazlığın axtarışının haradan başlayacağını müəyyən edir.

Müştəridə hər şey eyni görünür: bir IPv4 ünvanı, bir maska, bəzən standart şlüz. Fərq yalnız o ünvan üçün kimin cavab verdiyini və kimin onun qeydini saxladığını soruşanda ortaya çıxır.

Tunel ünvanını müştəri tərəfindən oxuyun

Windows fərqi bütün bloku oxuyanda göstərir, ilk sətri deyil. ipconfig /all adapter təsvirini, fiziki ünvanı və DHCP sətrini çap edir. PPP və ya IKEv2 dial-up adapteri adətən DHCP-ni deaktiv kimi bildirir, çünki bağlantı ünvanını LAN serverindən icarəyə götürmək əvəzinə dial-up zamanı razılaşdırıb. DHCP aktiv olan tunel adapteri qeyri-adidir və özlüyündə araşdırılmağa dəyər.

Linux eyni məlumatı iki alət arasında bölür. ip -4 addr show dev tun0 ünvanı və prefiks uzunluğunu verir. nmcli -f IP4 connection show work dəyərin bağlantı profilindən, keçiddəki DHCP mübadiləsindən yoxsa itələnmiş konfiqurasiyadan gəldiyini göstərir. WireGuard ən aydın haldır, çünki wg-quick interfeys görünəndə konfiqurasiya faylındakı Address sətrini tətbiq edir və qoşulma zamanı heç bir peer heç nə təyin etmir.

Prefiks də bir şey deyir. /32 və ya 255.255.255.255 maskası, şlüzün bir host ünvanına marşrutlaşdırma gözlədiyini bildirir, daha geniş maska isə tunelin arxasında haradasa on-link yarımşəbəkəyə işarə edir.

IKEv2 konfiqurasiya yükünün daşıdığı məlumat

IKEv2-nin bu iş üçün ayrıca mexanizmi var. RFC 7296, bölmə 3.15.1 sənədində təsvir olunan konfiqurasiya yükü INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS və onların IPv6 həmkarları kimi atributları daşıyır. Müştəri seçimi olmayanda sıfır uzunluqlu dəyərlə atribut göndərir, cavab verən isə istifadə olunmasını istədiyi dəyəri qaytarır. Bu mübadilə artıq şifrələnmiş IKE_AUTH içində gedir, ona görə heç bir DHCP yayımı tuneldən keçmir.

Bundan iki nəticə çıxır. Birincisi, ünvanı cavab verən və ya onun müraciət etdiyi avtorizasiya arxa planı seçir, buna görə hovuz şlüzdə, RADIUS cavabında və ya kimlik provayderinin xəritəsində yaşaya bilər. İkincisi, DNS atributu ünvan atributundan ayrıdır. 10.80.0.14 almaq hansı resolverin qayıtdığını və ya ümumiyyətlə qayıtdığını demir.

Şəbəkə maskası atributu praktikada istəyə bağlıdır. Çoxlu yerləşdirmə yalnız ünvan qaytarır və müştərinin host marşrutu quraşdırmasına imkan verir, buna görə eyni hovuz bir müştəridə /32, digərində /24 kimi görünə bilər.

LAN DHCP əhatəsi ilə VPN hovuzunun toqquşduğu yer

Problem hər iki təyin edənin eyni aralığa işarə etməsi ilə başlayır. 10.20.30.0/24 üçün DHCP serveri 10.20.30.128/25 üçün qurulmuş VPN hovuzu haqqında heç nə bilmir, ona görə şlüz eyni ünvanı uzaq müştəriyə verərkən onun 10.20.30.140 ünvanını printerə icarəyə verməsinə heç nə mane olmur. Toqquşma günlərlə səssiz qalır və sonra fasiləli dublikat kimi üzə çıxır.

Marşrutlanan sayt-sayt dizaynı toqquşmadan konstruksiyaya görə qaçır. Filialdakı host yerli DHCP serverinin verdiyi ünvanı saxlayır. Hər iki şlüzdəki tunel interfeysləri öz keçid ünvanlarını daşıyır, paketlərin necə getdiyini marşrut cədvəli həll edir. Uzaq giriş müştəri ünvanları üçüncü kateqoriyadır və şlüzün keçid ünvanları ilə qarışdırılmamalıdır.

Tuneli LAN-a körpüləmək bu ayrılığı aradan qaldırır. Əgər dizayn həqiqətən bir yayım domeni tələb edirsə, VPN son nöqtəsi ünvanları özü vermək əvəzinə rele və ya ortaq səlahiyyətli mənbə vasitəsilə DHCP serveri ilə eyni təyinat qərarlarında iştirak etməlidir.

Ünvanın hansı prosesə aid olduğunu yoxlayın

Əhatəni dəyişməzdən əvvəl sahibliyi sübut edin. Müştəridə ünvanı və prefiksi qeyd edin. LAN-da icarə bazasında axtarın. Şlüzdə onun vermək üçün qurulduğu hovuzları sadalayın. İcarə faylında tapılan ünvan DHCP serverinə aiddir, yəni tunel körpülənib və ya ötürülüb; yalnız şlüz hovuzunda tapılan ünvan tunel son nöqtəsinə aiddir.

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

Cavab aydın olanda dörd şeyi qeyd edin: müştəri ünvanını hansı komponent təyin edir, onun üçün hansı aralıq ayrılıb, qayıdış trafiki o aralığa necə çatır və hansı resurslar onu qəbul edir. Bu dörd qeyd virtual adapter sətrini əməliyyat faktına çevirir.

Orada olarkən DNS atributu üçün yoxlamanı təkrarlayın. Ünvan verən, lakin resolver verməyən hovuz müştərini yerli DNS-də qoyur, bu isə LAN-ın artıq istifadə etdiyi ünvanı verən hovuzdan fərqli bir nasazlıqdır.