VPN hovuzunuz LAN DHCP diapazonu deyil: niyə bu pozulur

Cazibədar qısa yol, hər şeyin onsuz da bir şəbəkə olduğu fərziyyəsi ilə VPN müştərilərinə ofis DHCP serverinin istifadə etdiyi eyni diapazondan ünvanlar verməkdir. Amma belə deyil. Marşrutlaşdırılmış tunel iki son nöqtə arasında unicast paketlər daşıyır, LAN hovuzu isə fiziki seqmentdə yayım sorğularına cavab vermək üçün mövcuddur. Rəqəmləri təkrar istifadə etmək iki paylayıcını bir ünvan məkanına cavabdeh edir və geri yolu təyinatsız qoyur.

İki paylayıcı, bir ünvan məkanı

LAN DHCP serveri hansı ünvanları hansı MAC ünvanına icarəyə verdiyini bilir və onları ARP ilə müdafiə edir. VPN serverinin öz hovuzu var və həmin icarələrdən xəbəri yoxdur. Heç biri səhv deyil; sadəcə onları bir-biri ilə tanış etməyiblər.

VPN serverinin LAN hovuzundan verdiyi bir ünvan artıq bir printerə aid ola bilər. İndi iki cihaz eyni prefiksdə bir ünvana iddia edir və kommutatorun yönləndirmə cədvəli hansının cavab verəcəyini həll edir.

İnsanların ilk rastlaşdığı nasazlıq budur: uğurla qoşulan və sonra yanlış maşına çatan müştəri, ya da düzgün maşına fasilələrlə çatan müştəri.

Router niyə VPN ünvanları paylamır

DHCP kəşfi yayımdır və yayımlar marşrutlaşdırılmış sərhəddə dayanır. Dizayn tuneli körpüləmir və ya uyğun səlahiyyətli DHCP relay işlətmirsə, müştərinin sorğusu heç vaxt LAN serverinə çatmır.

Buna görə ünvanı VPN serveri özü təyin edir: server konfiqurasiyasındakı hovuz, WireGuard quruluşunda hər peer üçün ünvan, ya da IKEv2 quraşdırmasında autentifikasiya qatının ötürdüyü ünvan. Bu mexanizmlər LAN icarə bazasından asılı deyil, və buna görə də onlara öz diapazonu lazımdır.

Eyni məntiq DHCP əhatəsini dəyişməyin niyə heç ünvan almayan VPN müştərini düzəltmədiyini izah edir. Müştəri LAN serverindən soruşmur və əhatəni redaktə etməklə onu soruşmağa vadar etmək mümkün deyil.

Üst-üstə düşmə yavaş şəbəkə kimi deyil, konflikt kimi görünür

Dəstəklənən dizayn olmadan eyni prefiksi paylaşan iki şəbəkə ikili sahiblikdən fərqli bir problemdir və onlar tez-tez qarışdırılır. VPN hovuzu ayrı prefiksdirsə, üst-üstə düşmə yalnız marşrut trafiki yanlış tərəfə göndərdikdə əhəmiyyətli olur. Hovuz LAN prefiksi daxilindədirsə, konflikt dərhal və lokaldır.

Praktikada yanlış cihazdan ARP cavabları, yarıda sıfırlanan bağlantılar və öz ünvanına başqasının iddia etdiyi müştəri görürsünüz. Bunların heç biri marşrut problemi kimi görünmür, buna görə də düzəliş yanlış qata tətbiq olunur. İkili icarəni təsdiqləmək asandır, onunla yaşamaq isə bezdiricidir. O, yenidən başlatmalardan da sağ çıxır, çünki hər iki paylayıcı eyni ünvanda israr edir.

Geri yol ayrı bir problemdir

Təmiz və ayrı hovuzla belə, LAN hostları müştəriyə necə cavab verəcəyini bilməlidir. Onların default gateway-i routerdir və routerə hovuz üçün VPN serverinə yönələn marşrut lazımdır, əgər dizayn müştəri trafikini tərcümə etmirsə.

Nəyisə dəyişməzdən əvvəl yolu hər iki istiqamətdə oxuyun. Gateway-də kernelin müştəri ünvanı üçün hansı interfeysi istifadə edəcəyini soruşun; müştəridə LAN ünvanı üçün hansı marşrutu istifadə etdiyini soruşun.

Bu əmrlər gateway-də irəli ötürmə qərarını və dublikatı aşkar edən qonşu qeydlərini göstərir:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

Birinci əmr tunel interfeysi ilə cavab verirsə, geri marşrut mövcuddur. Əgər LAN interfeysi ilə cavab verirsə, router müştərinin naqildə olduğuna inanır və onun üçün ARP etməyə çalışacaq.

Körpülü dizaynlar var, amma onları seçmək lazımdır

Tuneli LAN-a körpüləmək real dizayndır və müştərilər yayım almalı olduqda və ya bir seqmenti fərz edən protokollarla aşkar edilməlidirsə istifadə olunur. Bu, serverin həmin körpüləmə davranışına və onunla gedən ünvan idarəçiliyinə sahib olmasını tələb edir.

İşləməyən şey nəticəni rəqəmləri kopyalayaraq təqlid etməkdir. Körpüsüz ortaq hovuz sizə kəşf olmadan konflikt verir ki, bu da hər iki quruluşun ən pisi.

Tətbiq həqiqətən seqmentə ehtiyac duymursa, ayrı hovuzla üçüncü qatı seçin və hovuzu sənədləşdirin ki, növbəti administrator səliqə üçün DHCP diapazonunu təkrar istifadə etməsin.