Ավելացրեք կայքի VPN ISP երթուղիչի կողքին՝ չկտրելով զանգերը

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

Գրի առեք արդեն աշխատող դերերը

Գրանցեք լռելյայն դարպասը, DHCP սերվերը, լուծիչը և այն սարքը, որն ունի մատակարարի ձայնային գրանցումը։ Այս օրինակում ISP երթուղիչը 10.50.0.1 է, նոր դարպասը կլինի 10.50.0.2-ում, իսկ հեռավոր կայքը՝ 10.60.0.0/24։ Այդ պլանում ոչինչ չի փոխում առաջին երեք դերերը, և հենց դա է իմաստը։ Այնուհետև հաստատեք, որ երկրորդ սարքը իսկապես կարող է ավարտել թունելը. ստուգեք արձանագրությունը, սպասվող թողունակությունը և արդյոք այն ստանում է firmware կամ փաթեթների թարմացումներ։ VPN տարբերանշանով և թարմացման ուղի չունեցող սարքը բեռ է, ոչ թե հավելում։

Եթե չեք կարող ասել, թե ումն է ձայնային ծառայությունը, կանգնեք։ Գրանցում ունեցող երթուղիչը առանց հետադարձ պլանի փոխելը VPN նախագիծը դարձնում է հեռախոսային ընդհատում։

Տվեք նոր դարպասին մեկ հասցե և մեկ առաջադրանք

Պահեք նրա LAN հասցեն DHCP լողավազանից դուրս, որ վերագործարկումից հետո չշարժվի, և մի տվեք սեփական լռելյայն ուղի, եթե չեք ուզում, որ այն դառնա ինտերնետային ուղի։ Նրա խնդիրն է պահել թունելը և պատասխանել հեռավոր նախածանցներին։ LAN հոսթերի վրա, որոնք պետք է հասնեն հեռավոր կայքին, ապացուցեք, թե որ ուղին են հիմա օգտագործում և որը կուզենաք փոփոխությունից հետո. նույն երկու հրամանները առաջ և հետո ամենաէժան ապացույցն են։

ip route get 10.60.0.55
ip neigh show 10.50.0.2
traceroute -n 10.60.0.55

Եթե որոնումը վերադարձնում է ISP երթուղիչը, և traceroute-ը մահանում է ինտերնետի եզրին, հոսթը դեռ հեռավոր ուղի չունի, ինչը սպասելի է։ Եթե անսպասելի բան է վերադարձնում, նախ լուծեք այն, որովհետև յուրաքանչյուր հաջորդ քայլ ենթադրում է այս հիմքը։

Ընտրեք, թե ումն է հեռավոր նախածանցի ուղին

Տարբերակ A-ն ISP երթուղիչն է. այն պահում է ստատիկ ուղի 10.60.0.0/24-ի համար դեպի դարպասը, և յուրաքանչյուր հոսթ հետևում է իր լռելյայն դարպասին, ինչպես առաջ։ Տարբերակ B-ն ըստ հոսթի է. միայն այն մեքենաները, որոնց պետք է հեռավոր կայքը, ստանում են բացահայտ ուղի 10.50.0.2-ով, իսկ մնացածը մնում է անձեռնմխելի։ A-ն ավելի մաքուր է շատ հոսթերի դեպքում, բայց սովորաբար պահանջում է, որ մատակարարի երթուղիչն ընդունի ստատիկ ուղի, ինչը ոմանք չեն անում։ B-ն մատակարարի համագործակցություն չի պահանջում, բայց հոսթերի կազմաձևի սպասարկումը թողնում է ձեզ, ուստի հարմար է փոքր հաստատված մեքենաների խմբի համար։

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

ip route add 10.60.0.0/24 via 10.50.0.2 dev eth0
ip route get 10.60.0.55 from 10.50.0.77

Դարձրեք գրառումը մշտական հոսթի կազմաձևի տիրոջ միջոցով, ոչ թե մուտքի սկրիպտով։ Այն ուղին, որը գոյություն ունի միայն ինչ-որ մեկի մուտքից հետո, կձախողվի առաջին անգամ, երբ մեքենան վերագործարկվի անկապ պատճառով։

Կազմակերպեք հասանելի ներգնա կետ

Դարպասին պետք է հասցե, որին հեռավոր կայքը կարող է հասնել։ ISP երթուղիչի հետևում դա նշանակում է պորտի փոխանցում կամ DMZ գրառում, և երկուսն էլ կախված են նրանից, թե արդյոք մատակարարը իսկապես հասցնում է երթևեկությունը։ Տեղական փոխանցումը չի հաղթահարի մատակարարի կողմի օպերատորական NAT-ը։ Եթե մատակարարը հասանելի կետ չի տալիս, շրջեք ուղղությունը. թող երկու կայքերն էլ սկսեն դեպի ձեր վերահսկած հանգույցը։ Դա վավեր ձևավորում է, բայց ավելացնում է երրորդ կախվածություն փոխանցման, վստահության և հասանելիության համար, և դինամիկ DNS-ը դա չի փոխարինում։

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

Ընդունեք մասնավոր ծառայությունը և ձայնային գիծը միասին

Փորձարկեք նախատեսված աշխատանքը LAN հոսթից, մասնավոր DNS-ով և հավելվածի սեփական հավատարմագրերով։ Ուղղորդված թունելը հեռավոր զննարկումը տեղական Ethernet հատվածի նման չի դարձնում, ուստի հայտնաբերումը և անունների լուծումը պահանջում են իրենց կարգավորումները։

curl -sS -o /dev/null -w '%{http_code}\n' https://files.example.net
ping -c 3 10.60.0.55

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