Адрас VPN супраць арандавання DHCP у лакальнай сетцы: хто выдае IP тунэля?

Кліент VPN паказвае адрас, якога ніколі няма ў файле арандавання LAN. Прачытайце кліент, карысную нагрузку IKEv2 і пул шлюза, каб знайсці сапраўднага выдаўца.

Падключыце кліент і паглядзіце на адаптар, а не на значок Wi-Fi. Адрас накшталт 10.80.0.14 можа знаходзіцца на тунэлі, хоць ніводзін сервер 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 на іншым.

Дзе сутыкаюцца дыяпазон DHCP лакальнай сеткі і пул VPN

Праблема пачынаецца, калі абодва размеркавальнікі паказваюць на адзін дыяпазон. Сервер DHCP для 10.20.30.0/24 нічога не ведае пра пул VPN, наладжаны для 10.20.30.128/25, таму нішто не перашкаджае яму аддаць 10.20.30.140 у аранду прынтару, пакуль шлюз выдае той самы адрас аддаленаму кліенту. Канфлікт застаецца незаўважным днямі, а потым праяўляецца як перыядычны дубль.

Маршрутызаваная схема сайт-сайт пазбягае канфлікту па самай канструкцыі. Вузол у філіяле захоўвае адрас, які даў яму мясцовы сервер DHCP. Тунэльныя інтэрфейсы на абодвух шлюзах нясуць уласныя адрасы канала, а маршрутная табліца вырашае, як ідуць пакеты. Адрасы кліентаў аддаленага доступу — трэцяя катэгорыя, іх нельга змешваць з адрасамі канала шлюза.

Мост паміж тунэлем і лакальнай сеткай здымае гэтае размежаванне. Калі схема сапраўды патрабуе аднаго шырокавяшчальнага дамена, канцавы пункт VPN павінен удзельнічаць у тых жа рашэннях аб размеркаванні, што і сервер DHCP, праз рэтранслятар або агульную аўтарытэтную крыніцу, а не выдаваць адрасы самастойна.

Праверце, які працэс валодае адрасам

Дакажыце права валодання, перш чым мяняць дыяпазон. На кліенце зафіксуйце адрас і прэфікс. У лакальнай сетцы пашукайце ў базе арандавання. На шлюзе пералічыце пулы, якія ён наладжаны выдаваць. Адрас, знойдзены ў файле арандавання, належыць серверу 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, і гэта іншая памылка, чым пул, які выдае адрас, ужо заняты лакальнай сеткай.

Падобныя артыкулы