Ինչու DHCP վերապահումը ստատիկ IP չէ ձեր VPN սերվերի համար

Տնային VPN տուփը Wi-Fi-ից տեղափոխեցի Ethernet, և նրա «մշտական» հասցեն փոխվեց նույն երեկոյան։ Երթուղիչում ոչինչ չէր փչացել։ Վերապահումը համընկնում էր անլար ադապտերի հետ, և այդ ադապտերն այլևս ուղու վրա չէր։

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

Վերապահումը համընկնում է հաճախորդի հետ, ոչ սարքի

DHCPv4-ում վերապահումը հիմնված է հաճախորդի սարքաշարային հասցեի վրա; DHCPv6-ում՝ DUID-ի, որը հաճախորդը պետք է պահպանի։ hostname դաշտը պիտակ է մարդկանց համար։ Երթուղիչն իրականում համեմատում է հարցման մեջ եկող նույնացուցիչը։

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

OpenWrt-ը ձևը հստակ ցույց է տալիս։ Մեկ config host բլոկ /etc/config/dhcp-ում կապում է անունը, MAC-ը և հասցեն միասին, և ստատիկ վարձակալությունների փաստաթղթերը բացատրում են, թե ինչպես է այդ գրառումը փոխազդում լողավազանի հետ։ Այլ երթուղիչներ նույն երեք դաշտերը թաքցնում են տարբեր պիտակների հետևում։

Որտեղ համընկնումը լուռ ընկնում է

Սարքաշարի փոխարինումը սովորական դեպքն է։ Փոխեք ցանցային քարտը կամ տեղափոխեք մեքենան Ethernet-ի և Wi-Fi-ի միջև, և երթուղիչի տեսած հասցեն փոխվում է նրա հետ։ Հին վերապահումը մնում է ցանկում և դեռ ճիշտ է թվում։

Վերատեղադրումը երկրորդ դեպքն է, և այն ամենից ուժեղ կծում է IPv6-ում։ Թարմ տեղադրումը կարող է ստեղծել նոր DUID, քանի դեռ հին IPv4 վարձակալությունը դեռ վավեր է, այնպես որ v4 հասցեն որոշ ժամանակ ապրում է, իսկ v6 գրառումը դադարում է կիրառվել առանց որևէ տեսանելի խմբագրման։

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

Չորրորդը կրկնօրինակումն է՝ հին բլոկ և նոր բլոկ նույն հոսթի համար։ Սերվերը պատասխանում է այն կանոնով, որը համընկնում է, հաճախ հենց այն լողավազանի հասցեով, որը ցանկանում էիք խուսափել։ Ջնջեք հին գրառումը՝ երկրորդը ավելացնելու փոխարեն։

Կոնֆիգուրացիան հոսթի կողմից և դրա գինը

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

Գինը սեփականությունն է։ Այժմ դուք եք տրամադրում նախդիրը, դարպասը և լուծիչները, և հասցեն պետք է ինքներդ դինամիկ լողավազանից դուրս պահեք։ netplan-ով Ubuntu-ում այն կրում է /etc/netplan/01-vpn.yaml-ը.

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: false
      addresses: [192.168.50.10/24]
      routes:
        - to: default
          via: 192.168.50.1
      nameservers:
        addresses: [192.168.50.1]

NetworkManager-ի օգտատերերը նույն վիճակին հասնում են nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1-ով, ապա nmcli con up "Wired connection 1"-ով։ Առաջին փորձին կիրառեք netplan-ը netplan apply-ի փոխարեն netplan try-ով, սխալ մուտքագրված դարպասը տուփը հանում է ցանցից և ձեզ թողնում է կոնսոլ փնտրելիս։

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

Կայուն LAN հասցեն հանրային վերջնակետ չէ

Ուղղեք պորտի փոխանցումը 192.168.50.10-ին, և կանոնը կդիմանա LAN-ի կողմի ցանկացած փոփոխության։ Այն ձեզ կայուն ինտերնետ հասցե չի տալիս։ Ձեր հանրային IP-ն պատկանում է ISP-ին և կարող է շարժվել վերամիացման կամ մոդեմի փոխարինման ժամանակ, դինամիկ DNS-ը հենց դրա համար է։

Օպերատորի մակարդակի NAT-ի հետևում ընդհանրապես հանրային IPv4 չկա փոխանցելու, և ոչ մի վերապահում այն չի ստեղծում։ Նախ ստուգեք երթուղիչի WAN էջը, եթե հասցեն ընդհանուր տիրույթում է, մուտքային փոխանցումը չի կարող աշխատել, որքան էլ վերապահումը մաքուր լինի։

Երրորդ հասցեն թունելի լողավազանն է, հաճախ ինչ-որ բան, ինչպես 10.8.0.0/24։ Այդ հասցեները գոյություն ունեն միայն թունելի ներսում և երբեք չեն հայտնվում LAN-ում։ Դրանք սերվերի LAN հասցեի հետ շփոթելն այն ճանապարհն է, որով պորտը վերջում փոխանցվում է մի հաճախորդի, որը առցանց է միայն այնքան, քանի դեռ միացված է։

Ստուգեք ուղին այն հերթականությամբ, որով այն կտրվում է

Սկսեք երթուղիչից։ Համեմատեք վարձակալությունների աղյուսակի գրառումը վերապահման թիրախի հետ, եթե սերվերը վերցրել է լողավազանի հասցե, նույնացուցիչը սխալ է, և հոսթի վրա ip link show-ը տալիս է համեմատելու արժեքը։

Ապա հոսթը։ ip -4 addr show eth0-ը պետք է հայտնի սպասվող հասցեն և նախդիրը։ Նույն ինտերֆեյսի վրա երկրորդ հասցեն սովորաբար նշանակում է, որ DHCP-ն դեռ աշխատում է ձեր ստատիկ կոնֆիգուրացիայի կողքին։

Ապա փոխանցումը։ Հաստատեք, որ նպատակակետը դեռ հավասար է այն հասցեին, որը հենց նոր ստուգեցիք, և որ ինչ-որ բան լսում է ss -lntp-ով։ Փակ պորտ ուղղված փոխանցումը դրսից ճիշտ կոտրված փոխանցման տեսք ունի։

Ավարտեք դրսից՝ հեռախոսով, որի Wi-Fi-ը անջատված է։ Այդ մեկ թեստը տարանջատում է «տեղական հասցեն սխալ է»-ը «հանրային հասանելիությունը կոտրված է»-ից, այն երկու խնդիրները, որոնք այս կարգավորումը շարունակ խառնում է։

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