DHCP per VPN: sujungti transliaciją tiltu ar persiųsti?
Klientai kitoje tunelio pusėje negauna adreso. Nuspręskite, ar perduoti transliaciją, ar persiųsti ją, ir laikykite DHCP atskirai nuo ARP.
Naujas nešiojamas kompiuteris kitoje tunelio pusėje negauna adreso, nors tas pats kompiuteris veikia būstinėje. Įprasta pirmoji prielaida – tunelis blokuoja DHCP. Dažniau transliacija niekada neturėjo kelio: nesukonfigūruotas klientas siunčia į 255.255.255.255, o paprastas IP maršrutizatorius to paketo nepersiunčia. Tunelis daro būtent tai, ką daro maršrutizuotas tunelis.
Du sprendimai gali tai pakeisti, ir jie nėra lygiaverčiai. Vienas perduoda transliaciją; kitas persiunčia užklausą.
Transliacija niekada neperžengia maršrutizatoriaus
DHCPv4 klientas be adreso siunčia iš 0.0.0.0 į ribotą transliacijos adresą UDP 67 ir 68 portais. Šis paketas pagal projektą lieka savo jungtyje. Maršrutizatorius, kuris jį persiųstų, užtvindytų kiekvieną jo aptarnaujamą segmentą.
Taigi maršrutizuotas tunelis tarp svetainių sujungia retransliatorių su serveriu. Jis neplečia kliento transliacijos domeno, ir jokia ugniasienės taisyklė to nepadarys.
Ką tiltu sujungtas tunelis iš tikrųjų praplečia
Sąmoningai tiltu sujungta VPN gali perduoti Ethernet transliaciją savo palaikomoje topologijoje, ir tada DHCP gali praeiti kaip vietinis srautas. Tai reali galimybė, bet tai 2-ojo lygio dizaino sprendimas. Jūs plečiate gedimo domeną ir prieigos ribą kartu su transliacija.
Tiltas taip pat keičia, ką gali pasiekti transliacijos audra, ARP skenavimas ar netikras DHCP serveris. Jei nuotolinio biuro neprijungtumėte prie to paties komutatoriaus, netilinkite tunelio vien tam, kad išdalintumėte adresus. Išbandykite tą poveikio spindulį prieš įjungdami.
Tai didesnis sprendimas nei adreso suteikimas, ir jį reikia priimti sąmoningai.
Vietoj to persiųskite užklausą
Įprastas atsakymas – retransliatorius kliento vietiniame tinkle. Jis priima transliaciją, paverčia ją unicast užklausa ir įrašo savo adresą į šliuzo adreso lauką. Serveris atsako į tą retransliatoriaus adresą.
Iliustraciniam nuotoliniam biurui retransliatorius yra biuro LAN tinkle, o serveris pasiekiamas per svetainės VPN. Sukonfigūruokite to biuro sritį, retransliatoriaus ir serverio tapatybes bei visą grįžimo kelią. UDP 67 leidimas per tunelį nepasako serveriui, kurį telkinį naudoti.
Retransliatorius, kuris persiunčia, bet niekada negauna atsakymo, paprastai yra grįžimo kelio problema. Prieš keisdami sritį patikrinkite maršrutą atgal į retransliatoriaus adresą.
Atskirkite DHCP nuo ARP ir nuo tunelio adresavimo
DHCP veikia per UDP/IP. Ethernet tinkle mazgas taip pat gali naudoti ARP, kad patikrintų, ar kandidato adresas jau nenaudojamas. Šis konflikto patikrinimas yra atskira jungties vietinė operacija, o ne DHCP pranešimų transportas. Sakyti, kad DHCP iš esmės yra ARP, neteisinga; sakyti, kad šie du niekada nesusiję, per platu.
VPN klientas tunelio adresą gali gauti ir iš VPN protokolo arba paties serverio telkinio, o ne iš DHCP transliacijos. Parinktis, kurios pavadinime yra DHCP, gali aprašyti stumiamus kliento nustatymus, o ne persiųstą DHCP paketą. Prieš manydami, kad DHCP apskritai dalyvauja, patikrinkite serverio telkinį.
Užrašykite gaunančią tinklą, paskirstymo savininką, sritį, ar yra retransliatorius, ir numatomą elgseną trikdžio metu. Tada išbandykite naują nuomą ir atnaujinimą pagal tą modelį. Jei dvi svetainės gali aptarnauti tą patį nevaldomą telkinį, turite konfliktą, kuris laukia pirmo keliaujančio nešiojamojo kompiuterio.