Naslov VPN proti najemu DHCP v omrežju LAN: kdo dodeli IP predora?

Povežite odjemalca in poglejte v vmesnik namesto v ikono Wi-Fi. Naslov, kot je 10.80.0.14, lahko sedi na predoru, čeprav noben strežnik DHCP v pisarniškem omrežju LAN tega najema ni nikoli zabeležil. Prav proces, ki je izbral številko, odloča, kje se začne odpravljanje težave.

Na odjemalcu je vse videti enako: en naslov IPv4, ena maska, včasih privzeti prehod. Razlika se pokaže šele, ko se vprašate, kdo odgovarja za ta naslov in kdo o njem vodi evidenco.

Preberite naslov predora z odjemalčeve strani

Windows pokaže razliko, če preberete celoten blok in ne prve vrstice. ipconfig /all izpiše opis vmesnika, fizični naslov in vrstico DHCP. Klicni vmesnik PPP ali IKEv2 običajno poroča DHCP kot onemogočen, ker je povezava naslov dogovorila med klicanjem, namesto da bi ga najela pri strežniku v omrežju LAN. Predorski vmesnik z vklopljenim DHCP je nenavaden in si zasluži ločeno preiskavo.

Linux razdeli isto informacijo med dve orodji. ip -4 addr show dev tun0 poda naslov in dolžino predpone. nmcli -f IP4 connection show work razkrije, ali je vrednost prišla iz profila povezave, izmenjave DHCP na povezavi ali potisnjene konfiguracije. WireGuard je najjasnejši primer, ker wg-quick ob pojavu vmesnika uporabi vrstico Address iz konfiguracijske datoteke in noben partner ob povezavi ničesar ne dodeli.

Tudi predpona nekaj pove. /32 ali maska 255.255.255.255 pomeni, da prehod pričakuje usmerjanje na en naslov gostitelja, medtem ko širša maska nakazuje podomrežje na povezavi nekje za predorom.

Kaj nosi konfiguracijski tovor IKEv2

IKEv2 ima za to opravilo poseben mehanizem. Konfiguracijski tovor, opisan v RFC 7296, razdelek 3.15.1, nosi atribute, kot so INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS in njihovi dvojniki IPv6. Odjemalec pošlje atribut z ničelno dolžino, kadar nima preference, odgovarjajoča stran pa vrne vrednost, ki naj se uporabi. Ta izmenjava poteka znotraj IKE_AUTH, že šifrirana, zato nobeno oddajanje DHCP nikoli ne prečka predora.

Sledita dve posledici. Prvič, naslov izbere odgovarjajoča stran ali katerikoli avtorizacijski backend, ki ga posvetuje, zato bazen lahko živi na prehodu, v odgovoru RADIUS ali v preslikavi ponudnika identitete. Drugič, atribut DNS je ločen od atributa naslova. Prejem 10.80.0.14 ne pove ničesar o tem, kateri razreševalnik se je vrnil ali ali se je sploh kateri vrnil.

Atribut omrežne maske je v praksi neobvezen. Številne namestitve vrnejo le naslov in pustijo odjemalcu, da namesti pot do gostitelja, zato je isti bazen lahko videti kot /32 na enem odjemalcu in /24 na drugem.

Kjer trčita obseg DHCP v omrežju LAN in bazen VPN

Težave se začnejo, ko oba dodeljevalca kažeta na isto območje. Strežnik DHCP za 10.20.30.0/24 ne ve ničesar o bazenu VPN, nastavljenem za 10.20.30.128/25, zato ga nič ne ovira, da bi 10.20.30.140 oddal v najem tiskalniku, medtem ko prehod daje isti naslov oddaljenemu odjemalcu. Trk ostane dneve tih in se nato pokaže kot občasni dvojnik.

Usmerjena zasnova od lokacije do lokacije se trku izogne že po zgradbi. Gostitelj v podružnici obdrži naslov, ki mu ga je dal krajevni strežnik DHCP. Predorski vmesniki na obeh prehodih nosijo lastne naslove povezave, usmerjevalna tabela pa odloča, kako potujejo paketi. Naslovi odjemalcev oddaljenega dostopa so tretja kategorija in jih ne smemo mešati z naslovi povezave prehoda.

Premostitev predora v omrežje LAN odpravi to ločevanje. Če zasnova res potrebuje eno oddajno domeno, mora končna točka VPN sodelovati pri istih odločitvah o dodeljevanju kot strežnik DHCP, prek releja ali skupnega verodostojnega vira, namesto da bi naslove izdajala sama.

Preverite, kateri proces ima naslov

Dokažite lastništvo, preden spremenite obseg. Na odjemalcu si zapišite naslov in predpono. V omrežju LAN poiščite v zbirki najemov. Na prehodu naštejte bazene, ki jih je nastavljen oddajati. Naslov, najden v datoteki najemov, pripada strežniku DHCP, kar pomeni, da je predor premosten ali posredovan z relejem; naslov, najden samo v bazenu prehoda, pripada končni točki predora.

# 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

Ko je odgovor jasen, zapišite štiri stvari: katera komponenta dodeli naslov odjemalca, kateri obseg je zanj rezerviran, kako povratni promet doseže ta obseg in kateri viri ga sprejmejo. Ti štirje vnosi spremenijo vrstico navideznega vmesnika v obratovalno dejstvo.

Ponovite preverjanje za atribut DNS, dokler ste tam. Bazen, ki oddaja naslove brez razreševalnika, pusti odjemalca na njegovem krajevnem DNS, kar je drugačna okvara kot pri bazenu, ki oddaja naslov, ki ga omrežje LAN že uporablja.