VPN мекенжайы және LAN-ның DHCP жалдауы: туннель IP-сін кім береді?

VPN клиентіңіз LAN жалдау файлында ешқашан көрінбейтін мекенжайды көрсетеді. Нақты тағайындаушыны табу үшін клиентті, IKEv2 жүктемесін және шлюз пулын оқыңыз.

Клиентті қосып, Wi-Fi белгішесінің орнына адаптерге қараңыз. 10.80.0.14 сияқты мекенжай туннельде болуы мүмкін, бірақ кеңсе LAN-ындағы ешбір DHCP сервері ол жалдауды ешқашан тіркемеген. Нөмірді қай процесс таңдағаны ақаулықты іздеудің қайдан басталатынын анықтайды.

Клиентте бәрі бірдей көрінеді: бір IPv4 мекенжайы, бір маска, кейде әдепкі шлюз. Айырмашылық сол мекенжайға кім жауап беретінін және оның жазбасын кім ұстайтынын сұрағанда ғана байқалады.

Туннель мекенжайын клиент жағынан оқу

Windows айырмашылықты бірінші жолды емес, бүкіл блокты оқығанда көрсетеді. ipconfig /all адаптер сипаттамасын, физикалық мекенжайды және DHCP жолын шығарады. PPP немесе IKEv2 теріп қосу адаптері әдетте DHCP-ні өшірілген деп хабарлайды, өйткені қосылым мекенжайын LAN серверінен жалдаудың орнына теріп қосу кезінде келіскен. DHCP қосылған туннель адаптері сирек кездеседі және жеке тексеруді қажет етеді.

Linux бірдей ақпаратты екі құралға бөледі. ip -4 addr show dev tun0 мекенжай мен префикс ұзындығын береді. nmcli -f IP4 connection show work мәннің қосылым профилінен, буындағы DHCP алмасуынан әлде итерілген конфигурациядан келгенін ашады. WireGuard ең айқын жағдай, өйткені wg-quick интерфейс пайда болғанда конфигурация файлындағы Address жолын қолданады және қосылу кезінде ешбір серіктес ештеңе бөлмейді.

Префикс те бірдеңе дейді. /32 немесе 255.255.255.255 маскасы шлюздің бір хост мекенжайына маршруттауды күтетінін білдіреді, ал кеңірек маска туннельдің артындағы бір жердегі буындағы ішкі желіні меңзейді.

IKEv2 конфигурациялық жүктемесі нені тасымалдайды

IKEv2-нің бұл жұмысқа арналған жеке тетігі бар. RFC 7296, 3.15.1 бөлімінде сипатталған конфигурациялық жүктеме INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS сияқты атрибуттарды және олардың IPv6 баламаларын тасымалдайды. Клиент таңдауы болмағанда ұзындығы нөлдік мәнмен атрибут жібереді, ал жауап беруші қолданылуын қалайтын мәнді қайтарады. Бұл алмасу IKE_AUTH ішінде, әлдеқашан шифрланған күйде жүреді, сондықтан ешбір DHCP хабарламасы туннельден өтпейді.

Екі салдар туындайды. Біріншіден, мекенжайды жауап беруші немесе ол кеңесетін кез келген рұқсат беру жүйесі таңдайды, сондықтан пул шлюзде, RADIUS жауабында немесе сәйкестік провайдерінің салыстыруында болуы мүмкін. Екіншіден, DNS атрибуты мекенжай атрибутынан бөлек. 10.80.0.14 алу қай шешуші қайтқанын немесе мүлдем қайтқанын білдірмейді.

Желі маскасының атрибуты іс жүзінде міндетті емес. Көптеген орналастырулар тек мекенжайды қайтарып, клиентке хост маршрутын орнатуға мүмкіндік береді, сондықтан бір пул бір клиентте /32, екіншісінде /24 болып көрінуі мүмкін.

LAN-ның DHCP аумағы мен VPN пулы қақтығысатын жер

Мәселе екі тағайындаушы да бір диапазонды нұсқағанда басталады. 10.20.30.0/24 үшін DHCP сервері 10.20.30.128/25 үшін конфигурацияланған VPN пулы туралы ештеңе білмейді, сондықтан шлюз сол мекенжайды қашықтағы клиентке беріп жатқанда оның 10.20.30.140 мекенжайын принтерге жалдауына ештеңе кедергі болмайды. Қақтығыс күндер бойы үнсіз қалады, содан кейін анда-санда қайталанатын көшірме ретінде беті ашылады.

Маршрутталған сайттан сайтқа жоба қақтығысты өз құрылысымен-ақ болдырмайды. Филиалдағы хост жергілікті DHCP сервері берген мекенжайды сақтайды. Екі шлюздегі туннель интерфейстері өз буын мекенжайларын алып жүреді, ал маршруттау кестесі пакеттердің қалай жүретінін шешеді. Қашықтан қатынау клиенттерінің мекенжайлары үшінші санат болып табылады және оларды шлюздің буын мекенжайларымен араластыруға болмайды.

Туннельді LAN-ға көпірлеу сол бөлінуді жояды. Егер жобаға шынымен бір хабар тарату домені қажет болса, VPN соңғы нүктесі өзі мекенжай шығармай, реле немесе ортақ беделді дереккөз арқылы DHCP сервері сияқты тағайындау шешімдеріне қатысуы керек.

Мекенжай қай процеске тиесілі екенін тексеру

Диапазонды өзгертер алдында иелікті дәлелдеңіз. Клиентте мекенжай мен префиксті жазып алыңыз. LAN-да жалдау дерекқорынан іздеңіз. Шлюзде ол таратуға конфигурацияланған пулдарды тізімдеңіз. Жалдау файлында табылған мекенжай DHCP серверіне тиесілі, яғни туннель көпірленген немесе реле арқылы берілген; тек шлюз пулында табылған мекенжай туннельдің соңғы нүктесіне тиесілі.

# 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

Жауап айқын болғанда төрт нәрсені жазыңыз: қай компонент клиент мекенжайын тағайындайды, оған қай диапазон қорылған, қайтарылатын трафик сол диапазонға қалай жетеді және қандай ресурстар оны қабылдайды. Осы төрт жазба виртуалды адаптер жолын операциялық фактіге айналдырады.

Сол жерде тұрғанда DNS атрибуты үшін тексеруді қайталаңыз. Мекенжайларды беріп, бірақ шешушісін бермейтін пул клиентті өзінің жергілікті DNS-інде қалдырады, бұл LAN әлдеқашан пайдаланып жатқан мекенжайды беретін пулдан өзгеше ақау.

Қатысты мақалалар