VPN адреса наспроти LAN DHCP закуп: кој ја доделува IP-адресата на тунелот?

Вашиот VPN клиент прикажува адреса што никогаш не се појавува во датотеката за закуп на LAN. Прочитајте го клиентот, IKEv2 товарот и базенот на портата за да го најдете вистинскиот доделувач.

Поврзете го клиентот и гледајте го адаптерот наместо иконата за Wi-Fi. Адреса како 10.80.0.14 може да стои на тунел, иако ниту еден DHCP сервер на канцеларискиот LAN никогаш не го забележал тој закуп. Токму процесот што го избрал бројот одредува каде започнува отстранувањето на проблемот.

На клиентот сето изгледа исто: една 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 базенот

Проблемот започнува кога двата доделувача покажуваат на истиот опсег. DHCP сервер за 10.20.30.0/24 не знае ништо за VPN базен конфигуриран за 10.20.30.128/25, така што ништо не го спречува да изнајми 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 веќе ја користи.

Поврзани статии