Ո՞ր փաթեթին պետք է համապատասխանի երկու WAN-ով VPN քաղաքականությունը։

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

Անվանեք երկու զրույցները

Պատկերացրեք գրասենյակային դարպասին միացած հեռավոր աշխատակցի, որը HTTPS է բացում դեպի ներքին հավելվածային սերվեր։ Լարի վրա երկու անկախ զրույց կա, և դրանք յուրաքանչյուր ծայրում տարբեր հասցեներ ունեն։ Արտաքին զրույցը ընթանում է VPN-ի երկու վերջնակետերի միջև՝ դարպասի հասցեից դեպի զուգընկերոջ հասցե, այն արձանագրությամբ և պորտով, ինչ շահագործումը բանակցել է։ Ներքին զրույցը ընթանում է հաճախորդին տրված հասցեից դեպի հավելվածային սերվերի հասցեն 443 պորտում։

Հավելվածի նպատակակետ պորտը VPN-ի փոխադրման պորտը չէ, և TCP 443-ի վրա ցանկացած քանակի քաղաքականություն թունելը չի տեղաշարժի։ Նույն կերպ, զուգընկերոջ փոխադրման հասցեն վերահասցեավորող կանոնը ոչինչ չի ասում այն մասին, թե ուր է գնում այդ օգտատիրոջ HTTP հարցումը ապակոդավորումից հետո։ Գրի առեք երկու զրույցներն էլ իրենց իրական հասցեներով նախքան որևէ կանոնի դիպչելը, որովհետև այս ոլորտում խառնաշփոթի մեծ մասը գալիս է մեկին անվանելուց և մյուսը կարգավորելուց։

Գտեք, թե որտեղ է ձեր քաղաքականությունը իրականում տեսնում փաթեթը

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

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

Հաստատեք այն փոխադրումը, ինչի շուրջ բանակցել եք

UDP-ում ինկապսուլացված IPsec-ի համար RFC 3948 ESP-ն տեղադրում է UDP-ի ներսում և օգտագործում է ոչ ESP նշիչ, որպեսզի IKE-ն տարբերելի մնա ընդհանուր պորտում։ Սովորական ESP-ն IP արձանագրություն է, ոչ TCP կամ UDP պորտ, ուստի պորտի համարի վրա գրված հրապարակային պատնեշի կանոնը բոլորովին չի համապատասխանի դրան։ Այս տարբերությունը որոշում է, թե ձեր WAN քաղաքականությանը պետք է UDP կանոն, արձանագրության կանոն, թե երկուսը։

Բանակցված արժեքները հաղթում են հիշված արժեքներին։ Կարդացեք միավորման ընթացիկ պորտերը և հասցեները սարքից՝ TCP 4500 կամ հին վաճառողի պորտ ավելացնելու փոխարեն ամեն դեպքի համար, ինչը բռնում է անկապ երթևեկություն և թաքցնում իրական դասակարգման խնդիրը։

Ստուգեք վերադարձի ուղին նախքան պարտավորվելը

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

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

Ստուգեք երկու շերտերն էլ երկու գրառումով

Մեկ գրառում WAN ինտերֆեյսում և մեկը թունելի ներսում լուծում են հարցը ավելի արագ, քան ցանկացած կազմաձևման համեմատություն։ Գործարկեք դրանք դարպասից, մինչ հաստատված հաճախորդը մեկ հարցում է կատարում, և պահպանեք երկու ֆայլերը։

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

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