VPN-safnið þitt er ekki DHCP-svið LANsins: hvers vegna það brotnar

Hin freistandi flýtileið er að gefa VPN-biðlarum netföng úr sama sviði og DHCP-þjónn skrifstofunnar notar, með þeirri kenningu að allt sé nú samt eitt net. Það er það ekki. Beint túnel flytur unicast-pakka milli tveggja enda, en LAN-safnið er til að svara útvarpsbeiðnum á líkamlegum hluta. Endurnotkun talnanna setur tvo úthlutendur í ábyrgð á einu netfangarými og lætur afturleiðina óskilgreinda.

Tveir úthlutendur, eitt netfangarými

DHCP-þjónn LANsins veit hvaða netföng hann hefur leigt og hvaða MAC-netfangi, og ver þau með ARP. VPN-þjónninn hefur eigið safn og veit ekkert um þær leigur. Hvorugur er rangur; þeim var bara aldrei kynnt hvor fyrir öðrum.

Netfang úr LAN-safninu sem VPN-þjónninn úthlutar gæti þegar tilheyrt prentara. Nú gera tvö tæki tilkall til eins netfangs á sama forskeyti, og framsendingartafla rofans ræður því hvor svarar.

Það er bilunin sem fólk lendir fyrst í: biðlari sem tengist með góðum árangri og nær svo röngu tæki, eða nær því rétta með hléum.

Hvers vegna beininn dreifir ekki VPN-netföngum

DHCP-uppgötvun er útvarp, og útvarp stöðvast á beinum landamærum. Nema hönnunin brúi túnelinn eða keyri DHCP-endurvarpa með samsvarandi heimild, nær beiðni biðlarans aldrei LAN-þjóninum.

Þess vegna úthlutar VPN-þjónninn netfanginu sjálfur: safn í stillingum þjónsins, netfang fyrir hvern jafningja í WireGuard-uppsetningu, eða netfang sem auðkenningarlagið ýtir í IKEv2-uppsetningu. Þessir ferlar eru óháðir leigugrunni LANsins, og þess vegna þurfa þeir eigið svið.

Sama röksemd skýrir hvers vegna breyting á DHCP-sviðinu lagar ekki VPN-biðlara sem fær aldrei netfang. Biðlarinn er ekki að spyrja LAN-þjóninn, og engin ritstjórn sviðsins fær hann til að spyrja.

Skörunin kemur fram sem átök, ekki sem hægt net

Tvö net sem deila forskeyti án studdrar hönnunar eru annað vandamál en tvöfalt eignarhald, og þau eru oft rugluð saman. Ef VPN-safnið er sér forskeyti skiptir skörunin aðeins máli þegar leið sendir umferð á ranga hlið. Ef safnið liggur innan LAN-forskeytisins eru átökin tafarlaus og staðbundin.

Í reynd sérðu ARP-svör frá ranga tækinu, tengingar sem endurstilla hálfa leið, og biðlara sem einhver annar gerir tilkall til eigin netfangs hans. Ekkert af þessu lítur út eins og leiðavandamál, og þess vegna er lagfæringunni beitt á ranga laginu. Tvöföld leiga er auðveld að staðfesta og erfitt að lifa með. Hún lifir einnig endurræsingar af, því báðir úthlutendur halda áfram að krefjast sama netfangs.

Afturleiðin er sérstakt vandamál

Jafnvel með hreinu, aðskildu safni þurfa LAN-hýslar að vita hvernig á að svara biðlara. Sjálfgefna gátt þeirra er beininn, og beininn þarf leið fyrir safnið sem vísar á VPN-þjóninn, nema hönnunin þýði umferð biðlarans í staðinn.

Lestu leiðina í báðar áttir áður en þú breytir einhverju. Á gáttinni, spurðu hvaða tengi kjarninn myndi nota fyrir netfang biðlara; á biðlaranum, spurðu hvaða leið hann notar fyrir LAN-netfang.

Þessar skipanir sýna framsendingarákvörðunina á gáttinni og nágrannafærslurnar sem afhjúpa tvírit:

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

Ef fyrsta skipunin svarar með túnel-tenginu er afturleiðin til staðar. Ef hún svarar með LAN-tenginu telur beininn að biðlarinn sé á vírnum og mun reyna ARP fyrir hann.

Brúaðar hönnunarlausnir eru til, en þær verða að vera valdar

Að brúa túnel inn á LANið er raunveruleg hönnun, notuð þegar biðlarar verða að fá útvarp eða verða uppgötvaðir af samskiptareglum sem gera ráð fyrir einum hluta. Hún krefst þess að þjónninn eigi þessa brúarhegðun og netfangameðferðina sem fylgir.

Það sem virkar ekki er að líkja eftir niðurstöðunni með því að afrita tölur. Sameiginlegt safn án brúar gefur þér átökin án uppgötvunarinnar, sem er það versta af hvoru tveggja.

Veldu lag þrjú með aðskildu safni nema forritið þurfi hlutann virkilega, og skjalfestu safnið svo næsti stjórnandi endurnoti ekki DHCP-sviðið af þrifnaði.