VPN-poolisi ei ole LANin DHCP-alue: miksi se hajoaa

Houkutteleva oikotie on antaa VPN-asiakkaille osoitteita samasta alueesta, jota toimiston DHCP-palvelin käyttää, sillä teorialla, että kaikki on kuitenkin yhtä verkkoa. Ei ole. Reititetty tunneli kuljettaa unicast-paketteja kahden päätepisteen välillä, kun taas LANin pooli on olemassa vastatakseen broadcast-pyyntöihin fyysisessä segmentissä. Numeroiden uudelleenkäyttö asettaa kaksi jakajaa vastuuseen yhdestä osoiteavaruudesta ja jättää paluureitin määrittelemättä.

Kaksi jakajaa, yksi osoiteavaruus

LANin DHCP-palvelin tietää, mitkä osoitteet se on vuokrannut ja mille MAC-osoitteelle, ja puolustaa niitä ARPlla. VPN-palvelimella on oma pooli eikä se tiedä näistä vuokrista mitään. Kumpikaan ei ole väärässä; heitä ei vain koskaan esitelty toisilleen.

Osoite LANin poolista, jonka VPN-palvelin jakaa, voi jo kuulua tulostimelle. Nyt kaksi laitetta vaatii yhtä osoitetta samassa etuliitteessä, ja kytkimen edelleenlähetystaulukko päättää, kumpi vastaa.

Se on vika, johon ihmiset törmäävät ensin: asiakas, joka yhdistää onnistuneesti ja päätyy sitten väärään koneeseen, tai saavuttaa oikean ajoittain.

Miksi reititin ei jaa VPN-osoitteita

DHCP-havaitseminen on lähetys, ja lähetykset pysähtyvät reititetylle rajalle. Ellei suunnittelu siltaa tunnelia tai aja DHCP-välittäjää vastaavalla valtuudella, asiakkaan pyyntö ei koskaan saavuta LANin palvelinta.

Siksi VPN-palvelin osoittaa osoitteen itse: pooli palvelimen kokoonpanossa, osoite per vertaislaite WireGuard-asennuksessa, tai osoite, jonka todennuskerros työntää IKEv2-käyttöönotossa. Nämä mekanismit ovat riippumattomia LANin vuokraluettelosta, ja juuri siksi ne tarvitsevat oman alueen.

Sama logiikka selittää, miksi DHCP-alueen muuttaminen ei korjaa VPN-asiakasta, joka ei koskaan saa osoitetta. Asiakas ei kysy LANin palvelimelta, eikä mikään alueen muokkaus saa sitä kysymään.

Päällekkäisyys näkyy ristiriitana, ei hitaana verkkona

Kaksi verkkoa, jotka jakavat etuliitteen ilman tuettua suunnittelua, on eri ongelma kuin kaksinkertainen omistus, ja ne sekoitetaan usein. Jos VPN-pooli on erillinen etuliite, päällekkäisyys merkitsee vain silloin, kun reitti lähettää liikennettä väärälle puolelle. Jos pooli on LANin etuliitteen sisällä, ristiriita on välitön ja paikallinen.

Käytännössä näet ARP-vastauksia väärältä laitteelta, yhteyksiä, jotka nollautuvat kesken, ja asiakkaan, jonka omaa osoitetta joku muu vaatii. Mikään noista ei näytä reititysongelmalta, siksi korjaus kohdistetaan väärälle kerrokselle. Kaksinkertainen vuokra on helppo vahvistaa ja ikävä sietää. Se kestää myös uudelleenkäynnistykset, koska molemmat jakajat vaativat edelleen samaa osoitetta.

Paluureitti on erillinen ongelma

Jopa puhtaalla ja erillisellä poolilla LANin isäntien on tiedettävä, miten asiakkaalle vastataan. Niiden oletusyhdyskäytävä on reititin, ja reititin tarvitsee poolille reitin, joka osoittaa VPN-palvelimeen, ellei suunnittelu käännä asiakkaan liikennettä.

Lue reitti molempiin suuntiin ennen kuin muutat mitään. Yhdyskäytävällä kysy, mitä liitäntää ydin käyttäisi asiakkaan osoitteelle; asiakkaalla kysy, mitä reittiä se käyttää LAN-osoitteelle.

Nämä komennot näyttävät edelleenlähetyspäätöksen yhdyskäytävällä ja naapuritietueet, jotka paljastavat duplikaatin:

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

Jos ensimmäinen komento vastaa tunneliliitännällä, paluureitti on olemassa. Jos se vastaa LAN-liitännällä, reititin uskoo asiakkaan olevan johdolla ja yrittää ARPia sille.

Sillattuja suunnitelmia on olemassa, mutta ne on valittava

Tunnelin siltaaminen LANiin on todellinen suunnitelma, jota käytetään, kun asiakkaiden on saatava lähetykset tai protokollien, jotka olettavat yhden segmentin, on löydettävä heidät. Se vaatii, että palvelin omistaa tämän siltakäyttäytymisen ja siihen kuuluvan osoitehallinnan.

Se mikä ei toimi, on tuloksen jäljitteleminen numeroita kopioimalla. Jaettu pooli ilman siltaa antaa ristiriidan ilman löytämistä, mikä on molempien järjestelyjen huonoin puoli.

Valitse kerros kolme erillisellä poolilla, ellei sovellus todella tarvitse segmenttiä, ja dokumentoi pooli, jotta seuraava ylläpitäjä ei käytä DHCP-aluetta uudelleen siisteyden vuoksi.