DHCP VPN baten bidez: broadcast-a zubiratu ala birbidali?

Tunelaren beste aldeko ordenagailu eramangarri berri batek ez du helbiderik lortzen, baina ordenagailu berak egoitza nagusian funtzionatzen du. Ohiko lehen susmoa tunelak DHCP blokeatzen duela da. Gehienetan broadcast-ak ez zuen inoiz biderik izan: konfiguratu gabeko bezero batek 255.255.255.255 helbidera bidaltzen du, eta IP bideratzaile arrunt batek ez du pakete hori birbidaltzen. Tunelak bideratutako tunel batek egiten duen bera egiten du.

Bi diseinuk alda dezakete hori, eta ez dira baliokideak. Batek broadcast-a eramaten du; besteak eskaera birbidaltzen du.

Broadcast-ak ez du inoiz bideratzailea zeharkatzen

Helbiderik gabeko DHCPv4 bezero batek 0.0.0.0-tik broadcast mugatuaren helbidera bidaltzen du UDP 67 eta 68 portuetan. Pakete horrek bere estekan geratzen da diseinuaren arabera. Birbidaliko lukeen bideratzaile batek zerbitzatzen duen segmentu bakoitza gainezkatu luke.

Beraz, gunez guneko tunel bideratu batek errelebo-lotura bat zerbitzari batekin konektatzen du. Ez du bezeroaren broadcast domeinua zabaltzen, eta ez du suebaki-arau batek ere lortuko.

Zer zabaltzen duen zubiratutako tunel batek benetan

Borrokatutako VPN batek Ethernet broadcast-a eraman dezake onartzen duen topologian, eta orduan DHCP tokiko trafiko gisa igaro daiteke. Benetako aukera da, baina 2. geruzako diseinu-erabakia da. Hutsegite-domeinua eta sarbide-muga zabaltzen ari zara broadcast-arekin batera.

Zubiratzeak ere aldatzen du broadcast ekaitz batek, ARP eskaneatze batek edo DHCP zerbitzari maltzur batek zer har dezaketen. Ez bazenu bulego urruneko ordenagailua switch berera konektatuko, ez zubiratu tunela helbideak banatzeko soilik. Probatu eragin-erradio hori gaitu aurretik.

Helbide bat hornitzea baino erabaki handiagoa da, eta nahita hartu behar da.

Birbidali eskaera, horren ordez

Ohiko erantzuna bezeroaren sare lokaleko errelebo bat da. Broadcast-a jasotzen du, unicast eskaera bihurtzen du eta bere helbidea atearen helbide-eremuan jartzen du. Zerbitzariak errelebo-helbide horri erantzuten dio.

Adibide gisa hartutako bulego urrun batean, erreleboa bulegoko LANean dago eta zerbitzaria guneko VPN bidez iristen da. Konfiguratu bulego horretarako esparrua, erreleboaren eta zerbitzariaren identitateak eta itzulera-bide osoa. Tunelaren bidez UDP 67 baimentzeak ez dio zerbitzariari zein igerileku erabili esaten.

Birbidaltzen duen baina inoiz erantzunik jasotzen ez duen errelebo bat itzulera-bidearen arazoa izan ohi da. Egiaztatu errelebo-helbiderako bidea esparrua aldatu aurretik.

Bereizi DHCP ARP-tik eta tuneleko helbideratzetik

DHCP UDP/IP gainean doa. Etherneten, ostalari batek ARP ere erabil dezake hautagai-helbide bat erabilia ote dagoen egiaztatzeko. Gatazka-egiaztapen hori estekako tokiko eragiketa bereizia da, ez DHCP mezuentzako garraioa. DHCP funtsean ARP dela esatea okerra da; biak inoiz erlazionatzen ez direla esatea zabalegia da.

VPN bezero batek tuneleko helbidea VPN protokoloitik edo zerbitzariaren beraren igerilekutik ere lor dezake, DHCP broadcast batetik beharrean. Izenak DHCP duen aukera batek bultzatutako bezero-ezarpenak deskriba ditzake, ez birbidalitako DHCP pakete bat. Egiaztatu zerbitzariaren igerilekua DHCP inplikatuta dagoela pentsatu aurretik.

Erregistratu hartzaile-sarea, esleipenaren jabea, esparrua, erreleborik badagoen eta etenaldian espero den portaera. Ondoren probatu alokairu berri bat eta berritze bat eredu horren bidez. Bi gunek kudeatu gabeko igerileku bera zerbitza badezakete, lehen ordenagailu ibiltariaren zain dagoen gatazka duzu.