VPN-adres teenoor LAN se DHCP-huur: wie ken die tonnel se IP toe?

Jou VPN-kliënt wys 'n adres wat nooit in 'n LAN-huurleêr verskyn nie. Lees die kliënt, die IKEv2-lading en die poel op die gateway om die werklike toekenner te vind.

Verbind die kliënt en kyk na die adapter in plaas van die Wi-Fi-ikoon. 'n Adres soos 10.80.0.14 kan op 'n tonnel sit terwyl geen DHCP-bediener op die kantoor-LAN daardie huur ooit aangeteken het nie. Watter proses die nommer gekies het, bepaal waar die foutsoeking begin.

Op die kliënt lyk alles dieselfde: een IPv4-adres, een masker, soms 'n verstek-gateway. Die verskil kom eers te voorskyn wanneer jy vra wie vir daardie adres instaan en wie 'n rekord daarvan hou.

Lees die tonneladres van die kliënt se kant af

Windows wys die onderskeid as jy die hele blok lees eerder as die eerste reël. ipconfig /all druk 'n adapterbeskrywing, 'n fisiese adres en 'n DHCP-reël. 'n PPP- of IKEv2-inbeladapter rapporteer DHCP gewoonlik as gedeaktiveer, want die verbinding het sy adres tydens inbel onderhandel in plaas daarvan om dit by 'n LAN-bediener te huur. 'n Tonneladapter met DHCP geaktiveer is ongewoon en verdien op sigself ondersoek.

Linux verdeel dieselfde inligting oor twee gereedskap. ip -4 addr show dev tun0 gee die adres en voorvoegsellengte. nmcli -f IP4 connection show work onthul of die waarde uit die verbindingsprofiel, 'n DHCP-uitruiling op die skakel of 'n gestuurde konfigurasie gekom het. WireGuard is die duidelikste geval, want wg-quick pas die Address-reël uit die konfigurasielêer toe wanneer die koppelvlak verskyn, en geen peer ken iets toe tydens verbinding nie.

Die voorvoegsel sê ook iets. 'n /32, of 'n masker van 255.255.255.255, beteken die gateway verwag om na een gasheeradres te roeteer, terwyl 'n wyer masker 'n op-skakel-subnet êrens agter die tonnel aandui.

Wat die IKEv2-konfigurasielading dra

IKEv2 het 'n toegewyde meganisme hiervoor. Die konfigurasielading wat in RFC 7296, afdeling 3.15.1 beskryf word, dra eienskappe soos INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS en hul IPv6-eweknieë. Die kliënt stuur 'n eienskap met 'n waarde van nul lengte wanneer hy geen voorkeur het nie, en die responder gee die waarde terug wat hy wil hê gebruik moet word. Daardie uitruiling ry binne IKE_AUTH, reeds geënkripteer, so geen DHCP-uitsending steek ooit die tonnel oor nie.

Twee gevolge volg. Eerste, die adres word gekies deur die responder of deur watter magtigingsrugsteun ook al die responder raadpleeg, en daarom kan 'n poel op die gateway, in 'n RADIUS-antwoord of in 'n identiteitsverskaffer se kartering woon. Tweede, die DNS-eienskap is apart van die adres-eienskap. Om 10.80.0.14 te ontvang sê niks oor watter oplosser teruggekom het, of of enige teruggekom het nie.

Die netmasker-eienskap is in die praktyk opsioneel. Baie ontplooiings gee net 'n adres terug en laat die kliënt 'n gasheerroete installeer, en daarom kan dieselfde poel soos 'n /32 op een kliënt en 'n /24 op 'n ander lyk.

Waar 'n LAN-DHCP-omvang en 'n VPN-poel bots

Probleme begin wanneer beide toekenners na dieselfde reeks wys. 'n DHCP-bediener vir 10.20.30.0/24 weet niks van 'n VPN-poel wat vir 10.20.30.128/25 opgestel is nie, so niks keer hom om 10.20.30.140 aan 'n drukker te verhuur terwyl die gateway dieselfde adres aan 'n afgeleë kliënt gee nie. Die botsing bly dae lank stil en kom dan as 'n onderbroke duplikaat na vore.

'n Geroteerde werf-tot-werf-ontwerp vermy die botsing uit die aard van die ontwerp. 'n Gasheer in die tak behou die adres wat sy plaaslike DHCP-bediener hom gegee het. Die tonnelkoppelvlakke op beide gateways dra hul eie skakeladresse, en die roetertabel besluit hoe pakkette reis. Adresse van afgeleë-toegang-kliënte is 'n derde kategorie en moet nie met die gateway se skakeladresse vermeng word nie.

Om die tonnel op die LAN te brug, verwyder daardie skeiding. As die ontwerp werklik een uitsaaidomein nodig het, moet die VPN-eindpunt aan dieselfde toekenningsbesluite as die DHCP-bediener deelneem, deur 'n relay of 'n gedeelde gesaghebbende bron, in plaas daarvan om self adresse uit te reik.

Verifieer watter proses die adres besit

Bewys die eienaarskap voordat jy 'n omvang verander. Op die kliënt, teken die adres en voorvoegsel vas. Op die LAN, soek in die huurbasis. Op die gateway, lys die poele wat hy opgestel is om uit te gee. 'n Adres wat in die huurleêr gevind word, behoort aan 'n DHCP-bediener, wat beteken die tonnel is gebrug of deurgestuur; 'n adres wat net in die gateway-poel gevind word, behoort aan die tonnel-eindpunt.

# 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

Teken vier dinge aan sodra die antwoord duidelik is: watter komponent die kliëntadres toeken, watter reeks daarvoor gereserveer is, hoe terugkeerverkeer daardie reeks bereik, en watter hulpbronne dit aanvaar. Daardie vier inskrywings verander 'n virtuele adapter-reël in 'n operasionele feit.

Herhaal die kontrole vir die DNS-eienskap terwyl jy daar is. 'n Poel wat adresse uitdeel maar geen oplosser nie, laat die kliënt op sy plaaslike DNS, wat 'n ander fout is as 'n poel wat 'n adres uitdeel wat die LAN reeds gebruik.

Verwante artikels