Jūsų VPN telkinys nėra LAN DHCP diapazonas: kodėl tai lūžta

Viliojantis trumpiausias kelias yra duoti VPN klientams adresus iš to paties diapazono, kurį naudoja biuro DHCP serveris, remiantis prielaida, kad viskas vis tiek yra vienas tinklas. Nėra. Maršrutizuotas tunelis perduoda unicast paketus tarp dviejų galų, o LAN telkinys egzistuoja tam, kad atsakytų į transliacijos užklausas fiziniame segmente. Tų pačių numerių naudojimas paveda dviem skirstytojams vieną adresų erdvę ir palieka grįžimo kelią neapibrėžtą.

Du skirstytojai, viena adresų erdvė

LAN DHCP serveris žino, kokius adresus išnuomojo ir kuriam MAC adresui, ir gina juos ARP. VPN serveris turi savo telkinį ir nieko nežino apie tuos nuomos sandorius. Nė vienas neklysta; jie tiesiog niekada nebuvo supažindinti.

Adresas iš LAN telkinio, kurį išduoda VPN serveris, jau gali priklausyti spausdintuvui. Dabar du įrenginiai pretenduoja į vieną adresą tame pačiame prefikse, o komutatoriaus persiuntimo lentelė nusprendžia, kuris atsakys.

Tai gedimas, su kuriuo žmonės susiduria pirmiausia: klientas, kuris sėkmingai prisijungia ir tada pasiekia ne tą mašiną, arba pasiekia tinkamą su pertraukomis.

Kodėl maršrutizatorius nedalina VPN adresų

DHCP aptikimas yra transliacija, o transliacijos sustoja ties maršrutizuota riba. Jei projektas nesujungia tunelio tiltu arba nevykdo DHCP relių su atitinkamu įgaliojimu, kliento užklausa niekada nepasiekia LAN serverio.

Todėl VPN serveris adresą priskiria pats: telkinys serverio konfigūracijoje, adresas kiekvienam partneriui WireGuard sąrankoje, arba adresas, kurį stumia autentifikavimo sluoksnis IKEv2 diegime. Šie mechanizmai nepriklauso nuo LAN nuomos duomenų bazės, ir būtent todėl jiems reikia savo diapazono.

Ta pati logika paaiškina, kodėl DHCP srities pakeitimas nesutvarko VPN kliento, kuris niekada negauna adreso. Klientas neklausia LAN serverio, ir joks srities redagavimas neprivers jo paklausti.

Persidengimas pasireiškia kaip konfliktas, o ne kaip lėtas tinklas

Du tinklai, bendrai naudojantys prefiksą be palaikomo projekto, yra kita problema nei dviguba nuosavybė, ir jie dažnai painiojami. Jei VPN telkinys yra atskiras prefiksas, persidengimas svarbus tik tada, kai maršrutas siunčia srautą į neteisingą pusę. Jei telkinys yra LAN prefikso viduje, konfliktas yra tiesioginis ir vietinis.

Praktiškai matote ARP atsakymus iš netinkamo įrenginio, ryšius, kurie persikrauna pusiaukelėje, ir klientą, kurio savo adresą pretenduoja kažkas kitas. Nė vienas iš jų neatrodo kaip maršrutizavimo problema, todėl pataisa taikoma netinkamam sluoksniui. Dviguba nuoma lengvai patvirtinama ir nemalonu su ja gyventi. Ji išlieka ir po perkrovimų, nes abu skirstytojai toliau reikalauja to paties adreso.

Grįžimo kelias yra atskira problema

Net ir su švariu, atskiru telkiniu LAN mazgai turi žinoti, kaip atsakyti klientui. Jų numatytoji tinklo vartų sąsaja yra maršrutizatorius, o maršrutizatoriui reikia maršruto telkiniui, nukreipto į VPN serverį, nebent projektas verčia kliento srautą.

Perskaitykite kelią abiem kryptimis prieš ką nors keisdami. Tinklo vartuose paklauskite, kokią sąsają branduolys naudotų kliento adresui; kliente paklauskite, kokį maršrutą jis naudoja LAN adresui.

Šios komandos parodo persiuntimo sprendimą tinklo vartuose ir kaimynų įrašus, kurie atskleidžia dublikatą:

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

Jei pirmoji komanda atsako tunelio sąsaja, grįžimo maršrutas egzistuoja. Jei ji atsako LAN sąsaja, maršrutizatorius tiki, kad klientas yra laiduose, ir bandys jam ARP.

Tiltiniai projektai egzistuoja, bet juos reikia pasirinkti

Tunelio sujungimas tiltu su LAN yra tikras projektas, naudojamas, kai klientai turi gauti transliacijas arba juos turi atrasti protokolai, kurie numato vieną segmentą. Tam reikia, kad serveris turėtų šį tilto elgesį ir su juo susijusį adresų tvarkymą.

Tai, kas neveikia, yra rezultato imitavimas kopijuojant numerius. Bendras telkinys be tilto duoda konfliktą be aptikimo, o tai yra blogiausia iš abiejų išdėstymų.

Pasirinkite trečią sluoksnį su atskiru telkiniu, nebent programai tikrai reikia segmento, ir dokumentuokite telkinį, kad kitas administratorius nepanaudotų DHCP diapazono vėl dėl tvarkingumo.