Sinu VPN-i aadressipool ei ole LAN-i DHCP vahemik: miks see katki läheb

Ahvatlev otsetee on anda VPN-klientidele aadresse samast vahemikust, mida kontori DHCP-server kasutab, teooriaga, et kõik on ju niikuinii üks võrk. Ei ole. Marsruuditud tunnel kannab unicast-pakette kahe otspunkti vahel, samal ajal kui LAN-i pool on olemas selleks, et vastata saadetistele füüsilisel segmendil. Numbrite korduskasutus paneb kaks jagajat vastutama ühe aadressiruumi eest ja jätab tagasitee määratlemata.

Kaks jagajat, üks aadressiruum

LAN-i DHCP-server teab, milliseid aadresse ta on rentinud ja millisele MAC-aadressile, ning kaitseb neid ARP-iga. VPN-serveril on oma pool ja ta ei tea neist rendilepingutest midagi. Kumbki ei eksi; neid lihtsalt ei ole kunagi kokku viidud.

Aadress LAN-i poolist, mille VPN-server välja annab, võib juba kuuluda printerile. Nüüd nõuavad kaks seadet ühte aadressi samas prefiksis ja kommutaatori edastustabel otsustab, milline neist vastab.

See ongi rike, millega inimesed kõigepealt kokku puutuvad: klient, mis ühendub edukalt ja jõuab seejärel vale masinani, või jõuab õigeni katkendlikult.

Miks ruuter VPN-i aadresse välja ei jaga

DHCP avastamine on saade ja saated peatuvad marsruuditud piiril. Kui lahendus ei silla tunnelit või ei käivita vastava volitusega DHCP releed, ei jõua kliendi päring kunagi LAN-i serverini.

Seetõttu määrab aadressi VPN-server ise: pool serveri konfiguratsioonis, aadress iga partneri kohta WireGuard-i seadistuses, või autentimiskihi poolt läbi surutud aadress IKEv2 juurutuses. Need mehhanismid on LAN-i rendiandmebaasist sõltumatud ja just seetõttu vajavad nad omaette vahemikku.

Sama loogika selgitab, miks DHCP ulatuse muutmine ei paranda VPN-kliienti, mis ei saa kunagi aadressi. Klient ei küsi LAN-i serverilt ja ükski ulatuse muudatus ei pane teda küsima.

Kattuvus ilmub konfliktina, mitte aeglase võrguna

Kaks võrku, mis jagavad prefiksit ilma toetatud lahenduseta, on teine probleem kui topeltomand, ja neid aetakse sageli segamini. Kui VPN-i pool on eraldi prefiks, loeb kattuvus ainult siis, kui marsruut saadab liikluse valele poole. Kui pool asub LAN-i prefiksi sees, on konflikt kohene ja kohalik.

Praktikas näete ARP-vastuseid valelt seadmelt, ühendusi, mis poole peal lähtestatakse, ja klienti, kelle oma aadressi nõuab keegi teine. Miski sellest ei näe välja nagu marsruutimisprobleem, mistõttu rakendatakse parandus valele kihile. Topeltrent on lihtne kinnitada ja tüütu taluda. See elab üle ka taaskäivitused, sest mõlemad jagajad nõuavad jätkuvalt sama aadressi.

Tagasitee on eraldi probleem

Isegi puhta ja eraldiseisva pooliga peavad LAN-i hostid teadma, kuidas kliendile vastata. Nende vaikelüüs on ruuter ja ruuter vajab pooli jaoks VPN-serverile osutavat marsruuti, kui lahendus ei tõlgi hoopis kliendi liiklust.

Lugege teed mõlemas suunas enne, kui midagi muudate. Lüüsil küsige, millist liidest tuum kliendi aadressi jaoks kasutaks; kliendil küsige, millist marsruuti see LAN-i aadressi jaoks kasutab.

Need käsud näitavad edastusotsust lüüsil ja naaberkirjeid, mis paljastavad duplikaadi:

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

Kui esimene käsk vastab tunneli liidesega, on tagasitee olemas. Kui see vastab LAN-i liidesega, usub ruuter, et klient on juhtmel, ja proovib tema jaoks ARP-i teha.

Sillatud lahendused on olemas, aga need tuleb valida

Tunneli sillamine LAN-i on tõeline lahendus, mida kasutatakse siis, kui kliendid peavad saama saateid või neid peavad avastama protokollid, mis eeldavad üht segmenti. See nõuab, et serveril oleks see sillakäitumine ja sellega kaasnev aadressikäsitlus.

See, mis ei tööta, on tulemuse jäljendamine numbrite kopeerimisega. Ühine pool ilma sillata annab teile konflikti ilma avastamiseta, mis on mõlema lahenduse halvim külg.

Valige kolmas kiht eraldi pooliga, kui rakendus tõesti segmenti ei vaja, ja dokumenteerige pool, et järgmine administraator ei kasutaks DHCP vahemikku uuesti korra nimel.