VPN հասցեն և LAN-ի DHCP վարձակալությունը. ով է տալիս թունելի IP-ը։

Միացրեք հաճախորդը և նայեք ադապտերին, ոչ թե Wi-Fi պատկերակին։ 10.80.0.14-ի նման հասցեն կարող է լինել թունելի վրա, մինչդեռ գրասենյակի LAN-ի ոչ մի DHCP սերվեր երբեք չի գրանցել այդ վարձակալությունը։ Հենց այն գործընթացը, որը ընտրել է համարը, որոշում է, թե որտեղից սկսել խնդրի որոնումը։

Հաճախորդի կողմում ամեն ինչ նույնն է թվում՝ մեկ IPv4 հասցե, մեկ դիմակ, երբեմն լռելյայն դարպաս։ Տարբերությունը երևում է միայն այն ժամանակ, երբ հարցնում եք՝ ով է պատասխանում այդ հասցեի համար և ով է դրա գրառումը պահում։

Կարդացեք թունելի հասցեն հաճախորդի կողմից

Windows-ը ցույց է տալիս տարբերությունը, եթե կարդաք ամբողջ բլոկը, ոչ թե առաջին տողը։ ipconfig /all-ը տպում է ադապտերի նկարագրությունը, ֆիզիկական հասցեն և DHCP տողը։ PPP կամ IKEv2 հավաքման ադապտերը սովորաբար հաղորդում է DHCP-ն որպես անջատված, որովհետև կապը համաձայնեցրել է իր հասցեն հավաքման ընթացքում՝ LAN սերվերից վարձելու փոխարեն։ DHCP-ով միացված թունելային ադապտերը անսովոր է և արժանի է առանձին ուսումնասիրության։

Linux-ը նույն տեղեկությունը բաժանում է երկու գործիքի միջև։ ip -4 addr show dev tun0-ը տալիս է հասցեն և նախածանցի երկարությունը։ nmcli -f IP4 connection show work-ը բացահայտում է՝ արժեքը եկել է կապի պրոֆիլից, կապուղու DHCP փոխանակումից, թե հրված կոնֆիգուրացիայից։ WireGuard-ը ամենապարզ դեպքն է, քանի որ wg-quick-ը ինտերֆեյսի հայտնվելիս կիրառում է կոնֆիգ ֆայլի Address տողը, և ոչ մի զուգընկեր միացման պահին ոչինչ չի հատկացնում։

Նախածանցը նույնպես ինչ-որ բան է ասում։ /32-ը կամ 255.255.255.255 դիմակը նշանակում է, որ դարպասը սպասում է երթուղավորել մեկ հոսթի հասցեի, իսկ ավելի լայն դիմակը հուշում է թունելի հետևում ինչ-որ տեղ գտնվող կապուղու ենթահամակարգի մասին։

Ինչ է կրում IKEv2 կոնֆիգուրացիայի ծանրաբեռնվածությունը

IKEv2-ն այս աշխատանքի համար ունի առանձին մեխանիզմ։ RFC 7296, 3.15.1 բաժնում նկարագրված կոնֆիգուրացիայի ծանրաբեռնվածությունը կրում է այնպիսի հատկանիշներ, ինչպիսիք են INTERNAL_IP4_ADDRESS-ը, INTERNAL_IP4_NETMASK-ը, INTERNAL_IP4_DNS-ը և դրանց IPv6 համարժեքները։ Հաճախորդը զրո երկարությամբ արժեքով հատկանիշ է ուղարկում, երբ նախապատվություն չունի, և պատասխանողը վերադարձնում է այն արժեքը, որը ցանկանում է օգտագործել։ Այդ փոխանակումը ընթանում է IKE_AUTH-ի ներսում՝ արդեն գաղտնագրված, ուստի ոչ մի DHCP հեռարձակում երբեք չի անցնում թունելով։

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

Ցանցային դիմակի հատկանիշը գործնականում ընտրովի է։ Շատ տեղաբաշխումներ վերադարձնում են միայն հասցե և թույլ են տալիս հաճախորդին տեղադրել հոսթի երթուղի, դրա համար էլ նույն լողավազանը կարող է մի հաճախորդի վրա երևալ որպես /32, մյուսի վրա՝ /24։

Որտեղ բախվում են LAN-ի DHCP տիրույթը և VPN լողավազանը

Խնդիրը սկսվում է, երբ երկու շնորհողներն էլ մատնանշում են նույն միջակայքը։ 10.20.30.0/24-ի համար DHCP սերվերը ոչինչ չգիտի 10.20.30.128/25-ի համար կարգավորված VPN լողավազանի մասին, ուստի ոչինչ չի խանգարում նրան 10.20.30.140-ը վարձակալությամբ տալ տպիչին, մինչ դարպասը նույն հասցեն տալիս է հեռավոր հաճախորդի։ Բախումը օրերով լուռ է մնում, ապա ի հայտ է գալիս որպես պարբերական կրկնօրինակ։

Երթուղավորված տեղամաս-տեղամաս նախագիծը խուսափում է բախումից իր իսկ կառուցվածքով։ Մասնաճյուղի հոսթը պահպանում է այն հասցեն, որը տվել է իր տեղական DHCP սերվերը։ Երկու դարպասների թունելային ինտերֆեյսները կրում են իրենց սեփական կապուղու հասցեները, և երթուղային աղյուսակը որոշում է, թե ինչպես են փաթեթները շարժվում։ Հեռավոր մուտքի հաճախորդների հասցեները երրորդ կատեգորիա են և չպետք է խառնվեն դարպասի կապուղու հասցեների հետ։

Թունելը LAN-ի վրա կամրջելը վերացնում է այդ բաժանումը։ Եթե նախագիծն իսկապես պահանջում է մեկ հեռարձակման տիրույթ, VPN-ի վերջնակետը պետք է մասնակցի նույն հատկացման որոշումներին, ինչ DHCP սերվերը՝ ռելեի կամ ընդհանուր հեղինակավոր աղբյուրի միջոցով, փոխարենը ինքը հասցեներ թողարկելու։

Ստուգեք, թե որ գործընթացն է տիրում հասցեին

Ապացուցեք սեփականությունը նախքան միջակայքը փոխելը։ Հաճախորդի վրա գրանցեք հասցեն և նախածանցը։ LAN-ում որոնեք վարձակալությունների տվյալների բազայում։ Դարպասի վրա թվարկեք այն լողավազանները, որոնք այն կարգավորված է տրամադրել։ Վարձակալության ֆայլում գտնված հասցեն պատկանում է DHCP սերվերին, այսինքն՝ թունելը կամրջված կամ ռելեով փոխանցված է, իսկ միայն դարպասի լողավազանում գտնված հասցեն պատկանում է թունելի վերջնակետին։

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

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

Կրկնեք ստուգումը DNS հատկանիշի համար, քանի դեռ այնտեղ եք։ Լողավազանը, որը հասցեներ է տալիս առանց լուծիչի, հաճախորդին թողնում է իր տեղական DNS-ի վրա, ինչը տարբեր խափանում է այն լողավազանից, որը տալիս է LAN-ի արդեն օգտագործած հասցեն։