Mamljiva bližnjica je dodeljevati odjemalcem VPN naslove iz istega obsega, kot ga uporablja pisarniški strežnik DHCP, v prepričanju, da je vseeno vse eno omrežje. Ni. Usmerjeni tunel prenaša pakete unicast med dvema koncema, medtem ko nabor LAN obstaja zato, da odgovarja na zahteve za oddajanje v fizičnem segmentu. Ponovna uporaba številk postavi dva razdeljevalca kot odgovorna za en naslovni prostor in pusti povratno pot nedefinirano.

Dva razdeljevalca, en naslovni prostor

Strežnik DHCP v omrežju LAN ve, katere naslove je oddal v najem in kateremu naslovu MAC, ter jih brani z ARP. Strežnik VPN ima svoj nabor in o teh najemih ne ve ničesar. Nobeden se ne moti; preprosto niso bili nikoli predstavljeni drug drugemu.

Naslov iz nabora LAN, ki ga dodeli strežnik VPN, lahko že pripada tiskalniku. Zdaj si dve napravi lastita en naslov v istem predponi, tabela posredovanja stikala pa odloči, katera bo odgovorila.

To je okvara, s katero se ljudje srečajo prvi: odjemalec, ki se uspešno poveže in nato doseže napačen stroj, ali pravega doseže občasno.

Zakaj usmerjevalnik ne razdeljuje naslovov VPN

Odkrivanje DHCP je oddajanje, oddajanja pa se ustavijo na usmerjeni meji. Če zasnova tunela ne premosti ali ne zažene posredovalnika DHCP z ustrezno pristojnostjo, zahteva odjemalca nikoli ne doseže strežnika LAN.

Zato strežnik VPN naslov dodeli sam: nabor v konfiguraciji strežnika, naslov na vsakega partnerja v namestitvi WireGuard, ali naslov, ki ga potisne avtentikacijska plast pri uvedbi IKEv2. Ti mehanizmi so neodvisni od baze najemov LAN, in prav zato potrebujejo svoj obseg.

Ista logika pojasnjuje, zakaj sprememba obsega DHCP ne popravi odjemalca VPN, ki nikoli ne dobi naslova. Odjemalec ne vpraša strežnika LAN in nobeno urejanje obsega ga ne prisili k temu.

Prekrivanje se pokaže kot konflikt, ne kot počasno omrežje

Dve omrežji, ki si delita predpono brez podprte zasnove, sta drugačen problem od dvojnega lastništva, in pogosto se zamenjujeta. Če je nabor VPN ločena predpona, je prekrivanje pomembno le, ko pot pošlje promet na napačno stran. Če je nabor znotraj predpone LAN, je konflikt takojšen in lokalen.

V praksi vidite odgovore ARP z napačne naprave, povezave, ki se ponastavijo na pol poti, in odjemalca, čigar lastni naslov zahteva nekdo drug. Nič od tega ni videti kot težava usmerjanja, zato se popravek uporabi na napačni plasti. Dvojni najem je lahko potrditi in neprijetno je z njim živeti. Preživi tudi ponovne zagone, ker oba razdeljevalca vztrajata pri istem naslovu.

Povratna pot je ločena težava

Tudi s čistim in ločenim naborom morajo gostitelji LAN vedeti, kako odgovoriti odjemalcu. Njihova privzeta prehodna postaja je usmerjevalnik, usmerjevalnik pa potrebuje pot za nabor, ki kaže na strežnik VPN, razen če zasnova namesto tega prevaja promet odjemalca.

Preberite pot v obe smeri, preden karkoli spremenite. Na prehodni postaji vprašajte, kateri vmesnik bi jedro uporabilo za naslov odjemalca; na odjemalcu vprašajte, katero pot uporablja za naslov LAN.

Ti ukazi prikažejo odločitev o posredovanju na prehodni postaji in vnose sosedov, ki razkrijejo dvojnik:

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

Če prvi ukaz odgovori z vmesnikom tunela, povratna pot obstaja. Če odgovori z vmesnikom LAN, usmerjevalnik meni, da je odjemalec na kablu, in bo zanj poskusil ARP.

Premostitvene zasnove obstajajo, vendar jih je treba izbrati

Premostitev tunela v LAN je resnična zasnova, uporabljena, ko morajo odjemalci prejemati oddajanja ali jih morajo odkriti protokoli, ki predpostavljajo en segment. Zahteva, da je strežnik lastnik tega premostitvenega vedenja in z njim povezanega ravnanja z naslovi.

Kar ne deluje, je posnemanje rezultata s kopiranjem številk. Skupni nabor brez mostu vam da konflikt brez odkritja, kar je najslabše od obeh ureditev.

Izberite tretjo plast z ločenim naborom, razen če aplikacija resnično potrebuje segment, in dokumentirajte nabor, da naslednji skrbnik ne bo znova uporabil obsega DHCP zaradi reda.

Sorodni članki