Die verleidelike kortpad is om VPN-kliënte adresse uit dieselfde reeks te gee as wat die kantoor se DHCP-bediener gebruik, op die teorie dat alles tog een netwerk is. Dit is nie. ’n Geroteerde tonnel dra unicast-pakkette tussen twee eindpunte, terwyl die LAN-poel bestaan om uitsaaiversoeke op ’n fisiese segment te beantwoord. Om die nommers te hergebruik plaas twee toekenners in beheer van een adresruimte en laat die terugpad ongedefinieer.

Twee toekenners, een adresruimte

Die LAN se DHCP-bediener weet watter adresse hy verhuur het en aan watter MAC-adres, en hy verdedig hulle met ARP. Die VPN-bediener het sy eie poel en geen kennis van daardie verhuringe nie. Nie een is verkeerd nie; hulle is nooit aan mekaar voorgestel nie.

’n Adres uit die LAN-poel wat die VPN-bediener uitdeel, kan reeds aan ’n drukker behoort. Nou eis twee toestelle een adres op dieselfde voorvoegsel, en die skakelaar se aanstuurtafel besluit wie antwoord.

Dit is die fout wat mense eerste teëkom: ’n kliënt wat suksesvol verbind en dan die verkeerde masjien bereik, of die regte een met tussenposes bereik.

Waarom die roeteerder nie VPN-adresse uitdeel nie

DHCP-ontdekking is ’n uitsending, en uitsendings stop by ’n geroteerde grens. Tensy die ontwerp die tonnel brug of ’n DHCP-herstuurder met ooreenstemmende gesag bedryf, bereik die kliënt se versoek nooit die LAN-bediener nie.

Dus ken die VPN-bediener self die adres toe: ’n poel in die bediener se konfigurasie, ’n adres per eweknie in ’n WireGuard-opstelling, of ’n adres wat deur die verifikasielaag in ’n IKEv2-ontplooiing gestoot word. Daardie meganismes is onafhanklik van die LAN se huurdatabasis, en dit is juis waarom hulle ’n eie reeks nodig het.

Dieselfde redenasie verduidelik waarom die verandering van die DHCP-omvang nie ’n VPN-kliënt regmaak wat nooit ’n adres kry nie. Die kliënt vra nie die LAN-bediener nie, en geen mate van omvangredigering maak dat hy vra nie.

Die oorvleueling wys as ’n konflik, nie ’n stadige netwerk nie

Twee netwerke wat ’n voorvoegsel deel sonder ’n ondersteunde ontwerp is ’n ander probleem as dubbele eienaarskap, en hulle word dikwels verwar. As die VPN-poel ’n aparte voorvoegsel is, maak oorvleueling net saak wanneer ’n roete verkeer na die verkeerde kant stuur. As die poel binne die LAN-voorvoegsel sit, is die konflik onmiddellik en plaaslik.

In die praktyk sien jy ARP-antwoorde van die verkeerde toestel, verbindings wat halfpad terugstel, en ’n kliënt wie se eie adres deur iemand anders opgeëis word. Nie een daarvan lyk soos ’n roeteerprobleem nie, en daarom word die oplossing op die verkeerde laag toegepas. ’n Dubbele huur is maklik om te bevestig en lastig om mee saam te leef. Dit oorleef ook herlaai, want albei toekenners bly op dieselfde adres aandring.

Terugpad is ’n aparte probleem

Selfs met ’n skoon, afsonderlike poel moet LAN-gashere weet hoe om ’n kliënt te antwoord. Hulle verstekpoort is die roeteerder, en die roeteerder het ’n roete vir die poel nodig wat na die VPN-bediener wys, tensy die ontwerp eerder kliëntverkeer vertaal.

Lees die pad in beide rigtings voordat jy iets verander. Vra op die poort watter koppelvlak die kern vir ’n kliëntadres sou gebruik; vra op die kliënt watter roete dit vir ’n LAN-adres gebruik.

Hierdie opdragte wys die aanstuur-besluit op die poort en die buurinskrywings wat ’n duplikaat verraai:

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

As die eerste opdrag met die tonnelkoppelvlak antwoord, bestaan die terugroete. As dit met die LAN-koppelvlak antwoord, meen die roeteerder die kliënt is op die draad en sal hy vir dit probeer ARP.

Gebrugde ontwerpe bestaan, maar hulle moet gekies word

Om ’n tonnel aan die LAN te brug is ’n regte ontwerp, gebruik wanneer kliënte uitsendings moet ontvang of ontdek moet word deur protokolle wat een segment veronderstel. Dit vereis dat die bediener daardie brugoptrede besit en die adreshantering wat daarmee saamgaan.

Wat nie werk nie, is om die resultaat na te boots deur nommers te kopieer. ’n Gedeelde poel sonder ’n brug gee jou die konflik sonder die ontdekking, wat die slegste van albei reëlings is.

Kies laag drie met ’n afsonderlike poel tensy die toepassing werklik die segment nodig het, en dokumenteer die poel sodat die volgende administrateur nie die DHCP-reeks vir netheid hergebruik nie.

Verwante artikels