Հաջորդ ցատկը VPN երթուղում. ինչու դարպասը պետք է տեղայնորեն հասանելի լինի

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

Այս ուղեցույցը ընդգրկում է սովորական դեպքը՝ նոութբուք 192.168.20.0/24-ում, VPN դարպաս՝ 192.168.20.5 LAN հասցեով, և հեռավոր ցանց 10.70.0.0/24 այդ դարպասի հետևում։ Ստորև բոլոր հրամանները ենթադրում են, որ դուք նոութբուքում եք, եթե այլ բան նշված չէ։

Երկու հասցե, մեկ երթուղի

Նախատեսված գրառումը 10.70.0.0/24 via 192.168.20.5 է։ Նախածանցը ասում է, թե ուր է գնում փաթեթը, via հասցեն՝ թե ով է տանում այն այնտեղ։ Միջուկը հրաժարվում է տեղադրել երթուղի, որի դարպասին այն չի կարող հասնել ձեր նշած ինտերֆեյսով, և այդ հրաժարումը հենց ամբողջ իմաստն է՝ հաջորդ ցատկը, որին հասանելի լինելու համար թունել է պետք, չի կարող լինել այն հաջորդ ցատկը, որը կառուցում է թունելը։

Այսպիսով, առաջին ստուգումը «աշխատում է դարպասը» չէ, այլ «դարպասը այս կապուղում է»։ Նոութբուքի սեփական ենթացանցը, նրա ARP կամ հարևանի գրառումը և երթուղու ինտերֆեյսը բոլորը պետք է համաձայնեն։ Հասցեն, որը գոյություն ունի միայն 10.70.0.0/24-ի ներսում, կարող է լինել երկրորդ երթուղու նպատակակետ, բայց երբեք՝ առաջինի via-ը։

Ինչի է հաջորդ ցատկը պարտավորեցնում դարպասին

Նոութբուքում երթուղու տեղադրումը որոշում է միայն առաջին փոխանցումը։ Այնուհետև դարպասին պետք է իր ուղին՝ միացված փոխանցում, թունելային երթուղի 10.70.0.0/24-ի համար և ցանկացած մուտքի քաղաքականություն, որը սահմանում է, թե ով կարող է օգտագործել այն։ Linux-ում դա net.ipv4.ip_forward=1-ն է գումարած թունելային երթուղի, իսկ դիմացի հրային պատին պետք է կանոն, որը թույլատրում է փոխանցվող հոսքը։

Վերադարձի ուղղությունը այն մասն է, որը մարդիկ մոռանում են։ Հեռավոր կողմը պետք է ունենա վերադարձի երթուղի դեպի 192.168.20.0/24, կամ դիզայնը պետք է թարգմանի նոութբուքի աղբյուրը մի բանի, որը հեռավոր կողմը գիտի։ Դարպասից աշխատող ping-ը ապացուցում է, որ դարպասը կարող է հասնել հեռավոր ցանցին, սակայն ոչինչ չի ասում այն մասին, թե արդյոք նոութբուքի փաթեթները կդիմանան վերադարձի ճանապարհին։

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

Հարցրեք միջուկին, թե որ հաջորդ ցատկը կընտրի, և կարդացեք պատասխանի ինտերֆեյսը:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

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

Այնուհետև կրկնեք փորձարկումը ճիշտ տեղից։ Դարպասի վրա ստեղծված հարցումն օգտագործում է դարպասի սեփական աղբյուրի հասցեն, ինչը կարող է թաքցնել բացակայող վերադարձի երթուղին կամ քաղաքականություն, որը թույլատրում է միայն որոշակի աղբյուրներ։ ip-route ձեռնարկը առանձնացնում է նպատակակետը, դարպասը և onlink շրջանցումը, և արժե հասկանալ շրջանցումը նախքան այն օգտագործելը։

Մի օգտագործեք onlink-ը հասանելիությունը կեղծելու համար

onlink-ը միջուկին ասում է բաց թողնել դարպասի հասանելիության ստուգումը և միևնույն է ուղարկել այնտեղ։ Այն ուղի չի ստեղծում, ARP չի լուծում այն հասցեի համար, որը չկա, և չի ստիպում հեռավոր երթուղիչին պատասխանել ձեր Ethernet սեգմենտում։ Այն օրինական է դարպասների համար, որոնք պատասխանում են, բայց չեն գտնվում միացված ենթացանցում, և թակարդ է, երբ օգտագործվում է ձեր չբացատրած սխալը լռեցնելու համար։

Եթե երթուղին տեղադրվում է միայն onlink-ով, հաջորդ հարցն այն է, թե ինչու դարպասը այնտեղ չէ, որտեղ դուք կարծում եք։ Սխալ VLAN, երկրորդ հասցե սխալ ինտերֆեյսում կամ վերջին օկտետում տառասխալ՝ այս ամենը ստեղծում են դա, և դրանցից յուրաքանչյուրը նաև կոտրում է վերադարձի ուղին, հենց որ թրաֆիկը սկսում է հոսել։

Կետ-կետ թունելները Ethernet չեն

Թունելային սարքը ARP չի անում և հաճախ չունի հարևանների իմաստալից ենթացանց։ Նրա երթուղիները հաճախ նման են 10.70.0.0/24 dev tun0-ի, ընդհանրապես առանց via-ի, որովհետև գործընկերը միակ այլ վերջնակետն է։ LAN ոճի via-ը այդ աղյուսակում պատճենելը ստեղծում է երթուղի, որը միջուկը կարող է մերժել կամ, ավելի վատ, մեկը, որը մատնանշում է հասցե, որին գործընկերը երբեք չի պատասխանում։

Ուղեցույցում երկու մոդելները առանձին պահեք՝ LAN երթուղին ունի հասանելի դարպաս, թունելային երթուղին ունի ինտերֆեյս և գործընկեր։ WireGuard-ը, OpenVPN-ը և IPsec-ը բոլորը ցուցադրում են մի փոքր տարբեր ձևեր, ուստի գրանցեք այն ձևը, որը դուք իսկապես օգտագործել եք, փոխարենը մեկ հոսթից ընդհանրացնելու։

Ավելացրեք, հաստատեք, հետ շրջեք

Ամբողջ փոփոխությունը երեք հրաման և մեկ ստուգում է, և այն պետք է գրի առնվի հենց այդ հերթականությամբ:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

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