Նույն սերվերի IP-ն, երկու ուղի՝ OpenVPN-ի արտաքին հոսքի նշումը

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

Սկսեք երկու հոսքերից, որոնք ուզում եք բաժանել

Մի հոսքը գաղտնագրված OpenVPN տրանսպորտն է ինքը, որը պետք է դուրս գա uplink-ով, այլապես թունելը կկրեր իր իսկ արտաքին կապը։ Մյուսը սովորական HTTPS հարցումն է նույն հանրային հասցեին, որը ցանկանում եք թունելի ներսում, որպեսզի այն ծառայությանը հասնի թունելի աղբյուրից։ Նույն նպատակակետը, շատ դեպքերում նույն պորտի համարը, այլ պահանջվող ուղի։

Այս քննության համար ենթադրենք 10.90.0.10 հասցեով հաճախորդ tun1-ով, սերվերի 198.51.100.25 հանրային հասցե և անձեռնմխելի հիմնական աղյուսակ, որի լռելյայն երթուղին ուղղված է սովորական uplink-ին։ Սերվերի կողմը նույնպես պետք է ընդունի վեբ ծառայությունը ներքին ուղու վրա և երթևեկությունը վերադարձնի թունելի աղբյուրին՝ հանրային հասցեին փաթեթ ուղարկելը չի վերացնում սերվերի լսողին կամ firewall-ի քաղաքականությունը։

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

Նշեք այն socket-ը, որը կրում է ծրարը

Հաճախորդի կարգավորումը նշան է ստանում իր գաղտնագրված ելքային փաթեթների համար և դադարում է ինքը տեղադրել երթուղիներ, որպեսզի փոխարինող քաղաքականությունը լինի ուղիները որոշող միակ բանը՝

mark 42
route-noexec
disable-dco

Տասնորդական 42-ը տասնվեցական 0x2a-ն է, և հենց տասնվեցական ձևին են համապատասխանելու երթուղման կանոնները։ link-options-ի հղումը mark-ը նկարագրում է որպես Linux-ում գաղտնագրված ելքային փաթեթներին կիրառվող բան, այսինքն հենց այն socket-ը, որի ուղին պետք է կառավարեք։ Տվյալների ալիքի բեռնաթափումն անջատելը այս օրինակը պահում է օգտվողի տարածության ուղու վրա, որտեղ նշանի վարքը նկարագրվածն է։

route-noexec-ը ճնշում է OpenVPN-ի երթուղիների ավտոմատ ավելացումն ու հեռացումը։ Դրանց փոխարեն այն ոչինչ չի տեղադրում, ուստի այս պահից երթուղիների տերը պետք է պահպանի թունելին անհրաժեշտ յուրաքանչյուր երթուղի։ Եթե փոփոխությունից հետո մասնավոր նպատակակետը անհետանում է, դա բացակայող փոխարինող քաղաքականությունն է, ոչ թե նշանի թերություն։

Մի պահեք host երթուղի հիմնական աղյուսակում 198.51.100.25-ի համար, քանի դեռ սա անում եք։ Նման երթուղին վերստին ներմուծում է հենց այն բացառությունը, որը դիզայնը փորձում է նեղացնել, և կհաղթի HTTPS հոսքի համար նախքան ներքևի քաղաքականություններից որևէ մեկին հարցնելը։

Մնացած ամեն ինչ ուղարկեք թունելի աղյուսակ

Երբ թունելի ինտերֆեյսը գոյություն ունի և պահում է իր հասցեն, քաղաքականությունն այսպիսի տեսք ունի՝

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

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

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

Պահեք այդ պահակը տեղում կապերի ընդհատումների միջև և տեղադրեք այն քաղաքականության մնացած մասի հետ, ոչ թե ձեռքով։ Կանոնը, որ անհետանում է ինտերֆեյսի հետ, քաղաքականություն չէ, այլ պատահականություն։ Քաղաքականությունը ջնջելը, երբ թունելն ընկնում է, փոխում է ձախողման ռեժիմը «արգելափակված»-ից «արտահոսած»-ի, և ուշացած ժամկետանց թունելի երթուղին շատ ավելի հեշտ բացատրվող խնդիր է, քան սխալ ինտերֆեյսով դուրս եկած երթևեկությունը։

Թող վերադարձի ուղին տեսնի նույն նշանը

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

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

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

Ապացուցեք դա երկու երթուղու որոնումով

Համեմատեք, թե ինչ է որոշում միջուկը երկու համատեքստերի համար, և կարդացեք dev և src դաշտերը, ոչ թե ելքի կարգավիճակը՝

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

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

Գրեք, թե ինչ չի ընդգրկում դիզայնը, նախքան այն ավարտված հայտարարելը։ DNS-ը, IPv6-ը և կանոնների կյանքի ցիկլը յուրաքանչյուրը պահանջում է իր որոշումը, և սա IPv4 երթուղման օրինակ է, ոչ թե ամբողջական գաղտնիության կարգավորում։ Դրա արժեքը ընտրիչն է՝ ծրարը ստանում է uplink-ի բացառությունը, և նույն հասցեում գտնվող սովորական ծառայությունը պարտավոր չէ այն ժառանգել։