VPN adresas prieš LAN DHCP nuomą: kas priskiria tunelio IP?

Prijunkite klientą ir žiūrėkite į adapterį, o ne į Wi-Fi piktogramą. Toks adresas kaip 10.80.0.14 gali būti tunelyje, nors nė vienas DHCP serveris biuro LAN tinkle niekada neužregistravo tos nuomos. Būtent procesas, pasirinkęs numerį, lemia, nuo ko pradėti trikčių paiešką.

Kliente viskas atrodo vienodai: vienas IPv4 adresas, viena kaukė, kartais numatytasis šliuzas. Skirtumas išryškėja tik paklausus, kas atsako už tą adresą ir kas apie jį veda apskaitą.

Tunelio adresą perskaitykite iš kliento pusės

Windows parodo skirtumą, jei skaitote visą bloką, o ne pirmą eilutę. ipconfig /all išspausdina adapterio aprašymą, fizinį adresą ir DHCP eilutę. PPP arba IKEv2 rinkimo adapteris paprastai praneša DHCP kaip išjungtą, nes ryšys adresą suderino rinkimo metu, o ne išsinuomojo iš LAN serverio. Tunelio adapteris su įjungtu DHCP yra neįprastas ir vertas atskiro tyrimo.

Linux paskirsto tą pačią informaciją dviem įrankiams. ip -4 addr show dev tun0 pateikia adresą ir priešdėlio ilgį. nmcli -f IP4 connection show work atskleidžia, ar reikšmė atėjo iš ryšio profilio, DHCP mainų jungtyje ar įstumtos konfigūracijos. WireGuard yra aiškiausias atvejis, nes wg-quick pritaiko konfigūracijos failo eilutę Address, kai sąsaja atsiranda, ir nė vienas partneris prisijungiant nieko neskiria.

Priešdėlis taip pat ką nors pasako. /32 arba kaukė 255.255.255.255 reiškia, kad šliuzas tikisi maršrutizuoti į vieną hosto adresą, o platesnė kaukė užsimena apie jungties potinklį kažkur už tunelio.

Ką neša IKEv2 konfigūracijos naudingoji apkrova

IKEv2 turi tam skirtą mechanizmą. RFC 7296, 3.15.1 skyriuje aprašyta konfigūracijos naudingoji apkrova neša atributus, tokius kaip INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS ir jų IPv6 atitikmenis. Klientas siunčia nulinio ilgio reikšmės atributą, kai neturi nuostatos, o atsakantis subjektas grąžina reikšmę, kurią nori naudoti. Šie mainai vyksta IKE_AUTH viduje, jau užšifruoti, todėl jokia DHCP transliacija niekada neperžengia tunelio.

Iš to kyla dvi pasekmės. Pirma, adresą pasirenka atsakantis subjektas arba bet kuri autorizacijos sistema, su kuria jis konsultuojasi, todėl telkinys gali būti šliuze, RADIUS atsakyme arba tapatybės teikėjo susiejime. Antra, DNS atributas yra atskiras nuo adreso atributo. Gavus 10.80.0.14 nieko nesakoma apie tai, kurią skyrikę grąžino ar ar apskritai ką nors grąžino.

Tinklo kaukės atributas praktiškai yra neprivalomas. Daug diegimų grąžina tik adresą ir leidžia klientui įdiegti hosto maršrutą, todėl tas pats telkinys viename kliente gali atrodyti kaip /32, o kitame kaip /24.

Kur susiduria LAN DHCP sritis ir VPN telkinys

Bėdos prasideda, kai abu skyrėjai nurodo tą patį diapazoną. 10.20.30.0/24 DHCP serveris nieko nežino apie VPN telkinį, sukonfigūruotą 10.20.30.128/25, todėl niekas netrukdo jam išnuomoti 10.20.30.140 spausdintuvui, kol šliuzas tą patį adresą duoda nuotoliniam klientui. Susidūrimas kelias dienas lieka tylus, o paskui pasireiškia kaip periodiškas dublikatas.

Maršrutizuota svetainės į svetainę schema išvengia susidūrimo dėl pačios konstrukcijos. Filialo hostas išsaugo adresą, kurį jam davė vietinis DHCP serveris. Abiejų šliuzų tunelio sąsajos turi savo jungties adresus, o maršrutų lentelė sprendžia, kaip keliauja paketai. Nuotolinės prieigos klientų adresai yra trečia kategorija ir jų nereikėtų maišyti su šliuzo jungties adresais.

Tunelio tiltinimas į LAN panaikina tą atskyrimą. Jei schemai tikrai reikia vieno transliavimo domeno, VPN galinis taškas turi dalyvauti tuose pačiuose paskirstymo sprendimuose kaip ir DHCP serveris, per relių ar bendrą autoritetingą šaltinį, o ne pats išduoti adresus.

Patikrinkite, kuris procesas valdo adresą

Įrodykite nuosavybę prieš keisdami sritį. Kliente užsirašykite adresą ir priešdėlį. LAN tinkle ieškokite nuomos duomenų bazėje. Šliuze išvardykite telkinius, kuriuos jis sukonfigūruotas išduoti. Nuomos faile rastas adresas priklauso DHCP serveriui, tai reiškia, kad tunelis tiltintas arba perduotas rele; tik šliuzo telkinyje rastas adresas priklauso tunelio galiniam taškui.

# 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

Kai atsakymas aiškus, užrašykite keturis dalykus: kuris komponentas skiria kliento adresą, koks diapazonas jam rezervuotas, kaip grįžtamasis srautas pasiekia tą diapazoną ir kokie ištekliai jį priima. Šie keturi įrašai virtualaus adapterio eilutę paverčia veiklos faktu.

Pakartokite patikrinimą dėl DNS atributo, kol ten esate. Telkinys, kuris išduoda adresus be skyriklės, palieka klientą jo vietiniame DNS, o tai yra kitoks gedimas nei telkinio, kuris išduoda LAN jau naudojamą adresą.