DHCP-ը VPN-ով. կամուրջե՞լ հեռարձակումը, թե՞ փոխանցել

Թունելի մյուս կողմի նոր նոութբուքը հասցե չի ստանում, մինչդեռ նույն նոութբուքը աշխատում է գլխամասում։ Սովորական առաջին ենթադրությունն այն է, որ թունելը արգելափակում է DHCP-ն։ Ավելի հաճախ հեռարձակումը երբեք ուղի չի ունեցել. չկարգավորված հաճախորդը ուղարկում է 255.255.255.255-ին, և սովորական IP երթուղիչը այդ փաթեթը չի փոխանցում։ Թունելը անում է ճիշտ այն, ինչ անում է երթուղավորված թունելը։

Երկու ձևավորում կարող է փոխել դա, և դրանք համարժեք չեն։ Մեկը կրում է հեռարձակումը, մյուսը փոխանցում է հարցումը։

Հեռարձակումը երբեք չի անցնում երթուղիչով

Առանց հասցեի DHCPv4 հաճախորդը 0.0.0.0-ից ուղարկում է սահմանափակ հեռարձակման հասցեին UDP 67 և 68 պորտերով։ Այդ փաթեթը ըստ ձևավորման մնում է իր կապում։ Երթուղիչը, որը կփոխանցեր այն, կհեղեղեր իր սպասարկած յուրաքանչյուր սեգմենտը։

Այսպիսով, երթուղավորված կայք-կայք թունելը միացնում է փոխանցիչը սերվերին։ Այն չի ընդլայնում հաճախորդի հեռարձակման տիրույթը, և ոչ մի ֆայրվոլի կանոն դա չի անի։

Ինչ է իրականում ընդլայնում կամուրջավորված թունելը

Դիտավորյալ կամուրջավորված VPN-ը կարող է կրել Ethernet հեռարձակում իր աջակցվող տոպոլոգիայի շրջանակում, և այդ ժամանակ DHCP-ն կարող է անցնել որպես տեղական երթևեկություն։ Սա իրական տարբերակ է, բայց 2-րդ շերտի ձևավորման ընտրություն է։ Դուք ընդլայնում եք խափանման տիրույթը և մուտքի սահմանը հեռարձակման հետ միասին։

Կամուրջավորումը նաև փոխում է, թե ինչի կարող են հասնել հեռարձակման փոթորիկը, ARP սկանավորումը կամ խարդախ DHCP սերվերը։ Եթե դուք հեռավոր գրասենյակը չէիք միացնի նույն անջատիչին, ապա մի՛ կամուրջավորեք թունելը միայն հասցեներ բաժանելու համար։ Փորձարկեք այդ ազդեցության շառավիղը նախքան այն միացնելը։

Սա ավելի մեծ որոշում է, քան հասցե տրամադրելը, և այն պետք է կայացվի գիտակցաբար։

Փոխարենը փոխանցեք հարցումը

Սովորական պատասխանը հաճախորդի տեղական ցանցում գտնվող փոխանցիչն է։ Այն ընդունում է հեռարձակումը, վերածում է unicast հարցման և տեղադրում իր հասցեն դարպասի հասցեի դաշտում։ Սերվերը պատասխանում է այդ փոխանցիչի հասցեին։

Որպես օրինակ վերցված հեռավոր գրասենյակի համար փոխանցիչը գտնվում է գրասենյակի LAN-ում, իսկ սերվերին հասնում են կայքի VPN-ով։ Կարգավորեք այդ գրասենյակի տիրույթը, փոխանցիչի և սերվերի ինքնությունները և ամբողջական վերադարձի ուղին։ Թունելով UDP 67-ը թույլատրելը սերվերին չի ասում, թե որ լողավազանը օգտագործել։

Փոխանցիչը, որը փոխանցում է, բայց երբեք պատասխան չի ստանում, սովորաբար վերադարձի ուղու խնդիր է։ Ստուգեք վերադարձի երթուղին դեպի փոխանցիչի հասցեն նախքան տիրույթը փոխելը։

Առանձնացրեք DHCP-ն ARP-ից և թունելի հասցեավորումից

DHCP-ն աշխատում է UDP/IP-ի վրա։ Ethernet-ում հոսթը կարող է նաև ARP օգտագործել՝ ստուգելու, թե արդյոք թեկնածու հասցեն արդեն օգտագործվում է։ Այդ բախման ստուգումը առանձին կապ-տեղական գործողություն է, ոչ թե DHCP հաղորդագրությունների տրանսպորտը։ Ասել, թե DHCP-ն ըստ էության ARP է, սխալ է. ասել, թե դրանք երբեք կապված չեն, չափազանց լայն է։

VPN հաճախորդը կարող է իր թունելի հասցեն ստանալ նաև VPN արձանագրությունից կամ սերվերի սեփական լողավազանից, այլ ոչ թե DHCP հեռարձակումից։ DHCP անունը պարունակող ընտրանքը կարող է նկարագրել հրող կլիենտի կարգավորումներ, այլ ոչ թե փոխանցված DHCP փաթեթ։ Ստուգեք սերվերի լողավազանը նախքան ենթադրելը, որ DHCP-ն ընդհանրապես ներգրավված է։

Գրանցեք ստացող ցանցը, հատկացման տիրոջը, տիրույթը, փոխանցիչի առկայությունը և ընդհատման ժամանակ սպասվող վարքը։ Այնուհետև փորձարկեք նոր վարձակալություն և երկարաձգում այդ մոդելով։ Եթե երկու կայք կարող են սպասարկել նույն չկառավարվող լողավազանը, դուք ունեք բախում, որը սպասում է առաջին շրջող նոութբուքին։