DHCP trans VPN: ĉu ponti la dissendon aŭ plusendi ĝin?
Klientoj aliflanke de tunelo ne ricevas adreson. Decidu ĉu porti la dissendon aŭ plusendi ĝin, kaj tenu DHCP aparte de ARP.
Nova tekkomputilo aliflanke de la tunelo ne ricevas adreson, dum la sama tekkomputilo funkcias en la ĉefsidejo. La kutima unua supozo estas, ke la tunelo blokas DHCP. Pli ofte la dissendo neniam havis vojon: neagordita kliento sendas al 255.255.255.255, kaj ordinara IP-vojdirektilo ne plusendas tiun paketon. La tunelo faras ĝuste tion, kion faras enkursigita tunelo.
Du dezajnoj povas ŝanĝi tion, kaj ili ne estas ekvivalentaj. Unu portas la dissendon; la alia plusendas la peton.
La dissendo neniam transiras la vojdirektilon
Kliento de DHCPv4 sen adreso sendas de 0.0.0.0 al la limigita dissenda adreso sur UDP-portoj 67 kaj 68. Tiu paketo restas sur sia ligilo laŭ dezajno. Vojdirektilo, kiu plusendus ĝin, superflugus ĉiun segmenton, kiun ĝi servas.
Do enkursigita tunelo de loko al loko ligas la plusendilon al servilo. Ĝi ne etendas la dissendan domajnon de la kliento, kaj neniu fajroŝirma regulo tion atingos.
Kion pontita tunelo efektive etendas
Intence pontita VPN povas porti Ethernet-dissendon en sia subtenata topologio, kaj tiam DHCP povas transiri kiel loka trafiko. Tio estas reala opcio, sed ĝi estas dezajna elekto de tavolo 2. Vi etendas la erardomajnon kaj la alirlimon kune kun la dissendo.
Pontado ankaŭ ŝanĝas, kion povas atingi dissenda ŝtormo, ARP-skanado aŭ fripona DHCP-servilo. Se vi ne ŝtopus la malproksiman oficejon en la saman ŝaltilon, ne pontu la tunelon nur por disdoni adresojn. Testu tiun efikradiuson antaŭ ol ebligi ĝin.
Ĝi estas pli granda decido ol provizi adreson, kaj ĝi devus esti farita konscie.
Anstataŭe plusendu la peton
La kutima respondo estas plusendilo en la loka reto de la kliento. Ĝi ricevas la dissendon, transformas ĝin en unicast-peton kaj metas sian propran adreson en la kampon de pordega adreso. La servilo respondas al tiu plusendila adreso.
Por ilustra malproksima oficejo, la plusendilo staras en la LAN de la oficejo kaj la servilo estas atingata tra la loka VPN. Agordu la amplekson por tiu oficejo, la identecojn de plusendilo kaj servilo, kaj la kompletan revenan vojon. Permesi UDP 67 tra la tunelo ne diras al la servilo, kiun naĝejon uzi.
Plusendilo, kiu plusendas sed neniam ricevas respondon, estas kutime problema revena vojo. Kontrolu la vojon reen al la plusendila adreso antaŭ ol ŝanĝi la amplekson.
Apartigu DHCP disde ARP kaj disde tunela adresado
DHCP veturas super UDP/IP. Sur Ethernet, gastiganto ankaŭ povas uzi ARP por kontroli, ĉu kandidata adreso jam estas uzata. Tiu konflikta kontrolo estas aparta ligilloka operacio, ne la transporto por DHCP-mesaĝoj. Diri, ke DHCP estas esence ARP, estas malĝuste; diri, ke la du neniam rilatas, estas tro larĝa.
VPN-kliento ankaŭ povas ricevi sian tunelan adreson de la VPN-protokolo aŭ de la propra naĝejo de la servilo anstataŭ de DHCP-dissendo. Opcio, kies nomo enhavas DHCP, povas priskribi puŝitajn klientajn agordojn, ne plusenditan DHCP-paketon. Kontrolu la naĝejon de la servilo antaŭ ol supozi, ke DHCP entute partoprenas.
Notu la ricevantan reton, la posedanton de la atribuo, la amplekson, ĉu ekzistas plusendilo, kaj la atendatan konduton dum interrompo. Poste testu novan luon kaj renovigon per tiu modelo. Se du lokoj povas servi la saman neadministritan naĝejon, vi havas konflikton atendanta la unuan migrantan tekkomputilon.