VPN-adres tsjin LAN-DHCP-hier: wa jout it tunnel-IP?

Jo VPN-klant lit in adres sjen dat nea yn in LAN-hierbestân ferskynt. Lês de klant, de IKEv2-lading en de poel op de gateway om de wiere tadeler te finen.

Ferbyn de klant en sjoch nei de adapter yn plak fan it Wi-Fi-ikoan. In adres lykas 10.80.0.14 kin op in tunnel sitte wylst gjin DHCP-tsjinner op it kantoar-LAN dy hier ea registrearre hat. Hokker proses it nûmer keas, bepaalt wêr't it sykjen begjint.

Op de klant liket alles itselde: ien IPv4-adres, ien masker, soms in standertgateway. It ferskil komt pas foar it ljocht as jo freegje wa't foar dat adres antwurdet en wa't der in record fan hâldt.

Lês it tunneladres fan 'e klantkant

Windows lit it ferskil sjen as jo it hiele blok lêze en net de earste rigel. ipconfig /all printsje in adapterbeskriuwing, in fysyk adres en in DHCP-rigel. In PPP- of IKEv2-oanbeladapter meldt DHCP meastentiids as útskeakele, om't de ferbining syn adres by it oanbeljen úthannele ynstee fan it fan in LAN-tsjinner te hieren. In tunneladapter mei DHCP ynskeakele is ûngewoan en fertsjinnet in eigen ûndersyk.

Linux ferdielt deselde ynformaasje oer twa ark. ip -4 addr show dev tun0 jout it adres en de foarheakselflingte. nmcli -f IP4 connection show work lit sjen oft de wearde út it ferbiningsprofyl, in DHCP-útwikseling op 'e keppeling of in treaune konfiguraasje kaam. WireGuard is it dúdlikste gefal, om't wg-quick de rigel Address út it konfiguraasjebestân tapast as de ynterface ferskynt en gjin peer by it ferbinen eat tawiist.

It foarheaksel seit ek eat. In /32, of in masker fan 255.255.255.255, betsjut dat de gateway ferwachtet nei ien hostadres te rûten, wylst in breder masker in subnet op 'e keppeling earne efter de tunnel oantsjut.

Wat de IKEv2-konfiguraasjelading draacht

IKEv2 hat in eigen meganisme foar dit wurk. De konfiguraasjelading dy't beskreaun is yn RFC 7296, seksje 3.15.1 draacht attributen lykas INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS en har IPv6-tsjinhingers. De klant stjoert in attribút mei lingte nul as er gjin foarkar hat, en de beantwurder jout de wearde werom dy't er brûke wol. Dy útwikseling giet binnen IKE_AUTH, al fersifere, sadat gjin DHCP-útstjoering ea de tunnel oerstekt.

Twa gefolgen folgje. Earst wurdt it adres keazen troch de beantwurder of troch hokker autorisaasje-backend dan ek dy't er rieplachtet, en dêrom kin in poel op 'e gateway, yn in RADIUS-antwurd of yn in mapping fan in identiteitsprovider wenje. Twadde is it DNS-attribút los fan it adresattribút. It ûntfangen fan 10.80.0.14 seit neat oer hokker resolver weromkaam, of oft der wol ien weromkaam.

It netmaskerattribút is yn 'e praktyk opsjoneel. In protte ynsetten jouwe allinnich in adres werom en litte de klant in hostrûte ynstallearje, en dêrom kin deselde poel as in /32 op ien klant en in /24 op in oare lykje.

Wêr't in LAN-DHCP-berik en in VPN-poel botsje

Swierrichheden begjinne as beide tadelers nei deselde berik wize. In DHCP-tsjinner foar 10.20.30.0/24 wit neat fan in VPN-poel dy't foar 10.20.30.128/25 konfigurearre is, sadat neat him tsjinhâldt 10.20.30.140 oan in printer te hieren wylst de gateway deselde adres oan in klant fan fierrens jout. De botsing bliuwt dagen stil en komt dan as in tuskenskofts dûbel foar it ljocht.

In rûtearre site-to-site-ûntwerp foarkomt de botsing fan natuere. In host yn 'e filiaal hâldt it adres dat syn pleatslike DHCP-tsjinner him joech. De tunnelinterfaces op beide gateways drage har eigen keppelingsadressen, en de rûtingstabel beslút hoe't pakketten reizgje. Adressen fan klanten mei fierte tagong binne in tredde kategory en moatte net mei de keppelingsadressen fan 'e gateway mongen wurde.

It oerbrêgjen fan de tunnel nei it LAN hellet dy skieding wei. As it ûntwerp wier ien broadcast-domein nedich hat, moat it VPN-einpunt meidwaan oan deselde tadielingsbesluten as de DHCP-tsjinner, fia in relay of in mienskiplike autoritative boarne, ynstee fan sels adressen út te jaan.

Kontrolearje hokker proses it adres besit

Bewiis it eigendom foardat jo in berik feroarje. Op 'e klant, skriuw it adres en it foarheaksel op. Op it LAN, sykje yn de hierdatabase. Op 'e gateway, list de poelen op dy't er konfigurearre is út te jaan. In adres dat yn it hierbestân fûn wurdt, heart by in DHCP-tsjinner, wat betsjut dat de tunnel oerbrêge of relaied is; in adres dat allinnich yn 'e poel fan 'e gateway fûn wurdt, heart by it einpunt fan 'e tunnel.

# 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

Skriuw fjouwer dingen op as it antwurd dúdlik is: hokker komponint it klantadres tawiist, hokker berik dêrfoar reservearre is, hoe't weromferkear dat berik berikt en hokker boarnen it akseptearje. Dy fjouwer yngongen meitsje fan in rigel fan in firtuele adapter in operasjoneel feit.

Werhelje de kontrôle foar it DNS-attribút wylst jo der binne. In poel dy't adressen jout sûnder resolver lit de klant op syn pleatslike DNS, wat in oare flater is as in poel dy't in adres jout dat it LAN al brûkt.

Relatearre artikelen