Հանրային նախածանց OpenVPN-ի միջով. վերականգնել վերադարձի ուղին

Դիտեք, թե ինչպես է թունելը բարձրանում, և հաճախորդը պինգ է անում հակառակ կողմին, և հետո VPN-ի հետևում գտնվող հանրային հասցեն պատասխանում է այլ տեղից, կամ ընդհանրապես չի պատասխանում։ Այս ախտանիշը սովորաբար ոչ մի կապ չունի գաղտնագրման կամ վկայագրերի հետ։ Մատակարարի կողմից երթուղավորված նախածանցը հանձնվում է որպես IP երթուղի, և այն OpenVPN-ի միջով տանելը նշանակում է վերարտադրել այդ երթուղին երկու մակարդակում և պահպանել աղբյուրի հասցեն վերադարձի ուղու վրա։ WAN-ը կամրջել պետք չէ, և հասցեն ինտերֆեյսին ավելացնելը չի ստեղծում վերին երթուղին։

Նախածանցը նախ պետք է երթուղավորվի ձեզ մոտ

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

Եթե մատակարարը 198.51.100.64/28-ը երթուղավորում է ձեր մուտքի սերվերին, այդ տիրույթի փաթեթները հասնում են սերվերին և կանգ են առնում այնտեղ, եթե դուք դրանք չփոխանցեք։ Եթե մատակարարը փոխարենը տիրույթը կամրջում է ձեր uplink-ին, սերվերը պետք է ARP-ով պատասխանի դրա համար, ինչը այլ խնդիր է։

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

Երթուղավորման երկու մակարդակ: միջուկի երթուղի և iroute

OpenVPN-ին նախածանցը պետք է երկու տեղում։ Միջուկը պետք է իմանա, որ նախածանցը պատկանում է թունելի սարքին, որպեսզի փոխանցվող փաթեթները մտնեն OpenVPN՝ լռելյայն երթուղու փոխարեն։ OpenVPN-ը նույնպես պետք է իմանա, թե որ նույնականացված հաճախորդն է տիրապետում նախածանցին, և դա iroute գրառումն է հաճախորդին հատուկ գրացուցակում։

Սերվերի կողմի երթուղին այսպիսի տեսք ունի, ընդ որում նախածանցը և դիմակը պետք է համապատասխանեն հատկացմանը:

ip route add 198.51.100.64/28 dev tun0

Հաճախորդին հատուկ կարգավորումը սահմանում է սեփականությունը։ Տեղադրեք այն CCD ֆայլում, որը կոչվում է հաճախորդի վկայագրի ընդհանուր անունով, և հաստատեք, որ հենց այդ գրացուցակն է, որ սերվերն իրականում կարդում է:

iroute 198.51.100.64 255.255.255.240

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

Որտեղ է ապրում ծառայության հասցեն

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

Linux հաճախորդի վրա, որը ծառայությունը տեղում է ավարտում, բավարար է մեկ հոսթի հասցե:

ip address add 198.51.100.70/32 dev lo

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

Պահպանեք հանրային աղբյուրը վերադարձի ուղու վրա

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

Մուտքի սերվերի վրա լայն masquerade կանոնը սովորական մեղավորն է։ Այն վերագրում է հանրային աղբյուրը սերվերի հիմնական հասցեին, և հաճախորդը երբեք չի տեսնում իրականը:

iptables -t nat -S POSTROUTING

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

Ստուգեք երկու ուղղությունները նախքան վստահելը

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

Հարցրեք միջուկին, թե որ ուղին է վերցնում պատվիրազատված հասցեն, և դիտեք թունելը, մինչ հարցումն ընթանում է:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Հակադարձ ուղու զտումը կարող է չեղարկել ճիշտ երթուղին։ Ստուգեք արդյունավետ կարգավորումը թունելի և uplink-ի վրա, և հիշեք, որ խիստ ռեժիմը մերժում է այն երթևեկությունը, որի աղբյուրը չի համապատասխանում այն ինտերֆեյսին, որով այն եկել է:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

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