Повежите клијента и гледајте адаптер уместо иконе за 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 већ користи.

Повезани чланци