VPN адрес срещу DHCP наем в LAN: кой раздава IP адреса на тунела?

VPN клиентът показва адрес, който никога не се появява във файла с наеми на LAN. Прочетете клиента, полезния товар на IKEv2 и пула на шлюза, за да откриете истинския раздавач.

Свържете клиента и погледнете адаптера, а не иконата за Wi-Fi. Адрес като 10.80.0.14 може да стои на тунел, докато нито един DHCP сървър в офисната LAN никога не е записвал този наем. Процесът, който е избрал номера, определя откъде започва отстраняването на проблема.

На клиента всичко изглежда еднакво: един адрес IPv4, една маска, понякога шлюз по подразбиране. Разликата се появява само когато попитате кой отговаря за този адрес и кой води запис за него.

Прочетете адреса на тунела от страната на клиента

Windows показва разликата, ако прочетете целия блок, а не първия ред. ipconfig /all отпечатва описание на адаптера, физически адрес и ред за DHCP. PPP или IKEv2 dial-up адаптер обикновено отчита 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.

Подобни статии