Váš pool adries VPN nie je rozsah DHCP v sieti LAN: prečo to padá

Lákavou skratkou je prideľovať klientom VPN adresy z rovnakého rozsahu, aký používa kancelársky server DHCP, s domnienkou, že je aj tak všetko jedna sieť. Nie je. Smerovaný tunel prenáša unicastové pakety medzi dvoma koncami, zatiaľ čo pool v LAN existuje preto, aby odpovedal na broadcastové požiadavky na fyzickom segmente. Opätovné použitie čísel postaví dvoch prideľovačov nad jeden adresný priestor a ponechá spätnú cestu nedefinovanú.

Dvaja prideľovači, jeden adresný priestor

Server DHCP v LAN vie, ktoré adresy prenajal a akej MAC adrese, a bráni ich pomocou ARP. Server VPN má vlastný pool a o týchto prenájmoch nič nevie. Ani jeden sa nemýli; jednoducho ich nikdy nikto nepredstavil.

Adresa z poolu LAN, ktorú server VPN pridelí, môže už patriť tlačiarni. Teraz si dva prístroje nárokujú jednu adresu v tom istom prefixe a tabuľka preposielania prepínača rozhodne, ktorý odpovie.

To je porucha, s ktorou sa ľudia stretávajú prví: klient, ktorý sa úspešne pripojí a potom dosiahne nesprávny stroj, alebo dosiahne správny len občas.

Prečo router neprideľuje adresy VPN

Zisťovanie DHCP je broadcast a broadcasty sa zastavia na smerovanej hranici. Ak návrh tunel nepremosťuje alebo neprevádzkuje DHCP relay s príslušnou právomocou, požiadavka klienta sa nikdy nedostane k serveru v LAN.

Preto server VPN pridelí adresu sám: pool v konfigurácii servera, adresu pre každého partnera v nastavení WireGuard, alebo adresu, ktorú pretlačí autentifikačná vrstva pri nasadení IKEv2. Tieto mechanizmy sú nezávislé od databázy prenájmov v LAN, a práve preto potrebujú vlastný rozsah.

Rovnaká logika vysvetľuje, prečo zmena rozsahu DHCP neopraví klienta VPN, ktorý adresu nikdy nedostane. Klient sa servera v LAN nepýta a žiadna úprava rozsahu ho k tomu neprinúti.

Prekrytie sa prejaví ako konflikt, nie ako pomalá sieť

Dve siete zdieľajúce prefix bez podporovaného návrhu sú iný problém než dvojité vlastníctvo a často sa zamieňajú. Ak je pool VPN samostatný prefix, prekrytie záleží len vtedy, keď smerovanie pošle prevádzku na nesprávnu stranu. Ak pool leží vnútri prefixu LAN, konflikt je okamžitý a miestny.

V praxi vidíte odpovede ARP z nesprávneho zariadenia, spojenia, ktoré sa v polovici resetujú, a klienta, ktorého vlastnú adresu si nárokuje niekto iný. Nič z toho nevyzerá ako problém smerovania, preto sa oprava aplikuje na nesprávnej vrstve. Dvojitý prenájom sa dá ľahko potvrdiť a je otravné s ním žiť. Prežije aj reštarty, pretože obaja prideľovači naďalej trvajú na tej istej adrese.

Spätná cesta je samostatný problém

Aj s čistým a oddeleným poolom musia hostitelia v LAN vedieť, ako klientovi odpovedať. Ich predvolená brána je router a router potrebuje trasu pre pool smerujúcu na server VPN, ak návrh namiesto toho neprekladá prevádzku klienta.

Prečítajte si cestu v oboch smeroch, skôr než čokoľvek zmeníte. Na bráne sa opýtajte, ktoré rozhranie by jadro použilo pre adresu klienta; na klientovi sa opýtajte, ktorú trasu používa pre adresu v LAN.

Tieto príkazy ukazujú rozhodnutie o preposielaní na bráne a záznamy susedov, ktoré odhalia duplikát:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

Ak prvý príkaz odpovie tunelovým rozhraním, spätná trasa existuje. Ak odpovie rozhraním LAN, router sa domnieva, že klient je na kábli, a skúsi preň ARP.

Premostené návrhy existujú, ale treba ich vybrať

Premostenie tunela do LAN je skutočný návrh, používaný vtedy, keď klienti musia prijímať broadcasty alebo ich musia objaviť protokoly, ktoré predpokladajú jeden segment. Vyžaduje, aby server vlastnil toto premostenie a s ním spojenú správu adries.

Čo nefunguje, je napodobnenie výsledku kopírovaním čísel. Zdieľaný pool bez mosta vám dá konflikt bez objavenia, čo je to najhoršie z oboch usporiadaní.

Zvoľte tretiu vrstvu s oddeleným poolom, ak aplikácia skutočne nepotrebuje segment, a zdokumentujte pool, aby ďalší správca znova nepoužil rozsah DHCP len pre poriadok.