VPN-tala gegn DHCP-leigu LAN: hver úthlutar IP-tölunni á göngunni?
VPN-biðlarinn þinn sýnir tölu sem kemur aldrei fram í leiguskrá LAN. Lestu biðlarann, IKEv2-hleðsluna og laugina á gáttinni til að finna raunverulega úthlutandann.
Tengdu biðlarann og skoðaðu millistykkið í stað Wi-Fi-táknsins. Tala eins og 10.80.0.14 getur setið á göngu þótt enginn DHCP-þjónn á skrifstofu-LANinu hafi nokkurn tíma skráð þá leigu. Ferlið sem valdi töluna ræður því hvar bilanaleitin hefst.
Hjá biðlaranum lítur allt eins út: ein IPv4-tala, eitt gríma, stundum sjálfgefin gátt. Munurinn kemur aðeins í ljós þegar þú spyrð hver svarar fyrir þá tölu og hver heldur skrá um hana.
Lestu göngutöluna frá hlið biðlarans
Windows sýnir muninn ef þú lest allan blokkinn en ekki fyrstu línuna. ipconfig /all prentar lýsingu millistykkis, líkamlegt heimilisfang og DHCP-línu. PPP- eða IKEv2-hringiboðsmillistykki tilkynnir DHCP venjulega sem óvirkt, því tengingin samdi um töluna sína við hringingu í stað þess að leigja hana af LAN-þjóni. Göngumillistykki með virku DHCP er óvenjulegt og verðskuldar sérstaka rannsókn.
Linux skiptir sömu upplýsingum milli tveggja verkfæra. ip -4 addr show dev tun0 gefur töluna og lengd forskeytisins. nmcli -f IP4 connection show work upplýsir hvort gildið kom úr tengisniðinu, DHCP-skiptum á tenglinum eða ýttri stillingu. WireGuard er skýrasta dæmið, því wg-quick beitir línunni Address úr stillingaskránni þegar viðmótið birtist og enginn jafningi úthlutar neinu við tengingu.
Forskeytið segir líka eitthvað. /32, eða gríma 255.255.255.255, þýðir að gáttin ætlar að beina að einu hýsilheimilisfangi, en breiðari gríma bendir til undirnets á tenglinum einhvers staðar bak við gönguna.
Hvað IKEv2-stillingarhleðslan ber
IKEv2 hefur sérstaka aðferð fyrir þetta verk. Stillingarhleðslan sem lýst er í RFC 7296, kafla 3.15.1 ber eiginleika eins og INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS og IPv6-hliðstæður þeirra. Biðlarinn sendir eiginleika með núlllengd þegar hann hefur enga forgang og svarandinn skilar gildinu sem hann vill nota. Þessi skipti fara inni í IKE_AUTH, þegar dulkóðuð, svo ekkert DHCP-útvarp fer nokkurn tíma yfir gönguna.
Tvær afleiðingar fylgja. Í fyrsta lagi velur svarandinn töluna eða hvaða heimildabakendi sem hann ráðfærir sig við, þess vegna getur laug búið á gáttinni, í RADIUS-svari eða í vörpun auðkennisveitanda. Í öðru lagi er DNS-eiginleikinn aðskilinn frá heimilisfangseiginleikanum. Að fá 10.80.0.14 segir ekkert um hvaða leysir kom til baka, eða hvort nokkur kom.
Netgrímueiginleikinn er valkvæður í reynd. Margar uppsetningar skila aðeins tölu og láta biðlarann setja hýsilveg, þess vegna getur sama laugin litið út eins og /32 á einum biðlara og /24 á öðrum.
Þar sem DHCP-svið LANsins og VPN-laug stangast á
Vandamálið byrjar þegar báðir úthlutendur vísa á sama bilið. DHCP-þjónn fyrir 10.20.30.0/24 veit ekkert um VPN-laug sem stillt er fyrir 10.20.30.128/25, svo ekkert hindrar hann í að leigja 10.20.30.140 út til prentara meðan gáttin gefur sama heimilisfang fjartengdum biðlara. Áreksturinn er hljóður í marga daga og kemur svo fram sem slitrótt tvírit.
Beint stað-til-staðar fyrirkomulag forðast áreksturinn vegna uppbyggingar sinnar. Hýsill í útibúinu heldur heimilisfanginu sem staðbundinn DHCP-þjónn gaf honum. Gönguviðmót beggja gátta bera eigin tenglaheimilisföng og beiningataflan ræður því hvernig pakkar ferðast. Heimilisföng fjaraðgangsbiðlara eru þriðji flokkurinn og ætti ekki að blanda saman við tenglaheimilisföng gáttarinnar.
Að brúa gönguna inn á LANið fjarlægir þessa aðgreiningu. Ef fyrirkomulagið þarf sannarlega eitt útvarpssvið verður VPN-endapunkturinn að taka þátt í sömu úthlutunarákvörðunum og DHCP-þjónninn, í gegnum endurvarpa eða sameiginlega valdbæra heimild, í stað þess að gefa út heimilisföng sjálfur.
Staðfestu hvaða ferli á heimilisfangið
Sannaðu eignarhaldið áður en þú breytir sviði. Á biðlaranum skaltu skrá heimilisfangið og forskeytið. Á LANinu skaltu leita í leigugagnagrunninum. Á gáttinni skaltu telja upp laugarnar sem hún er stillt til að úthluta. Heimilisfang sem finnst í leiguskránni tilheyrir DHCP-þjóni, sem þýðir að göngunni er brúað eða endurvarpað; heimilisfang sem finnst aðeins í laug gáttarinnar tilheyrir endapunkti göngunnar.
# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0
# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases
# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools
Skráðu fjóra hluti þegar svarið er ljóst: hvaða hluti úthlutar heimilisfangi biðlarans, hvaða bil er frátekið fyrir það, hvernig endurkoma nær því bili og hvaða auðlindir samþykkja það. Þessar fjórar færslur breyta línu sýndarmillistykkis í rekstrarstaðreynd.
Endurtaktu athugunina fyrir DNS-eiginleikann á meðan þú ert þar. Laug sem úthlutar heimilisföngum án leysis skilur biðlarann eftir á staðbundna DNS-inu sínu, sem er önnur bilun en laug sem úthlutar heimilisfangi sem LANið notar þegar.