VPN-ի հաճախորդները հասնում են սերվերին, բայց ոչ LAN-ին. ո՞ր լուծումը

Հաճախորդը ping է անում OpenVPN սերվերի թունելի հասցեին և ստանում պատասխան, ապա փորձում է հոսթ սերվերի LAN-ում և ոչինչ չի ստանում։ Այս տարբերությունը զգալիորեն նեղացնում է խափանումը՝ թունելը բարձրացված է, փոխանցումը հավանաբար աշխատում է, իսկ պատասխանը դուրս է գալիս դռնով, որը հետ չի տանում։ Կան երեք լուծում, և ճիշտը կախված է նրանից, թե ինչ եք վերահսկում և ինչից եք պատրաստ հրաժարվել։ Պատասխանեք ստորև տրված երեք հարցերին հերթականությամբ, և ընտրությունը այլևս ճաշակի հարց չի լինի։

Նախ պարզեք, թե որ ուղղությունն է կոտրված

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

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

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Եթե LAN-ի հոսթն արդեն ցույց է տալիս VPN սերվերին, ձեր խնդիրը հրապատի կանոնն է կամ MTU-ի սահմանը, այլ ոչ թե բացակայող վերադարձի ուղին։ Մի ավելացրեք երթուղի ֆիլտրը ուղղելու համար։

Առաջին հարցը՝ կարո՞ղ եք խմբագրել հեռավոր LAN-ի երթուղիչը։

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

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

NAS-ը կամ Layer 3 կոմուտատորը, որը հոսթում է ծառայությունը, նույն երթուղին է պահանջում, եթե ամեն ինչ չի ուղարկում այդ երթուղին ունեցող երթուղիչով։ Ստուգեք այն սարքը, որը վերջացնում է ենթացանցը, և ոչ միայն դեպի ինտերնետ նայողը։ Փոքր ցանցերում հաճախ երեք սարք կա՝ երթուղավորման մասին սեփական կարծիքով։

Երկրորդ հարցը՝ կարո՞ղ է LAN-ը դադարել տեսնել հաճախորդների հասցեները։

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

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

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

Երրորդ հարցը՝ սերվերն ինքը հանդիսանում է այլ թունելի հաճախորդ։

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

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Բազմաինտերֆեյս հոսթերը ավելացնում են հարակից խափանում, որը հաճախորդի կողմից նույնն է թվում։ Պատասխանը դուրս է գալիս ավելի ցածր մետրիկայի ինտերֆեյսով, քանի որ աղբյուրի հասցեն ընտրվել է այլ աղյուսակից։ Ստուգեք վերադարձի ուղին որոնումով, այլ ոչ թե ենթադրեք, որ առաջընթաց ուղին դա ենթադրում է։

Այնուհետև ստուգեք երկու ուղղություններն ու երկու չափերը

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

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

Վերջապես, կրկին փորձարկեք վերագործարկումից հետո։ Աշխատանքի ընթացքում տրված երթուղու և հրապատի հրամանները դա չեն վերապրում, և ուղղումը, որն անհետանում է հաջորդ մեկնարկին, նորից կախտորոշվի ավելի քիչ կոնտեքստ ունեցողի կողմից։ Դարձրեք փոփոխությունը մշտական այնպես, ինչպես ձեր համակարգն արդեն անում է, ապա մեկ անգամ դիտավորյալ վերագործարկեք։