Ինչպես ուղարկել մեկ IPv4 նպատակակետ OpenVPN թունելից դուրս

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

Տողը անվնաս է թվում և հաճախ այդպես էլ կա, բայց այն լուծում է միայն մեկ հարց՝ թե այդ ճշգրիտ IPv4 հասցեի փաթեթները ուր են գնում։ Այն չի փոխում DNS-ը, IPv6-ը, հրապարակախցիկի քաղաքականությունը կամ այն, թե որ գործընթացն է բացել կապը, և դրանցից յուրաքանչյուրը կարող է լուռ չեղարկել բացառությունը։

Ինչ է իրականում անվանում net_gateway

Այդ բացառության պրոֆիլի գրառումը մեկ տող է՝ route 198.51.100.77 255.255.255.255 net_gateway։ Առաջին հասցեն նպատակակետի փաստաթղթային տեղապահն է, դիմակը այն դարձնում է մեկ հոսթի երթուղի, իսկ վերջին նշանը անվանում է դարպասի տեղապահը։ OpenVPN-ը լուծում է դարպասի տեղապահները, երբ տեղադրում է երթուղիներ։ vpn_gateway-ը նշանակում է թունելի սեփական դարպասը, VPN կապի հեռավոր կողմը։ net_gateway-ը նշանակում է այն լռելյայն դարպասը, որ հոսթն ուներ նախքան VPN-ը որևէ բան փոխելը, որը սովորաբար ֆիզիկական ցանցի տեղական երթուղիչն է։

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

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

Ինչու հոսթ-երթուղին հաղթում է թունելի լռելյայն երթուղուն

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

255.255.255.255 դիմակով մեկ հասցեի երթուղին /32 է, ինչը IPv4-ի հասանելի առավելագույն ճշգրտությունն է։ Երբ գնահատվում է այդ հասցեի փաթեթը, /32-ը համընկնում է և հաղթում անկախ այն բանից, թե որ երթուղին է առաջինը տեղադրվել։ Սա է բացառության հետևում ընկած մեխանիզմը, և այն նույն կերպ աշխատում է Linux-ում, macOS-ում և Windows-ում, քանի դեռ երթուղին իրոք առկա է։

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

Ինչ չի ծածկում բացառությունը

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

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

Ծրագրի շրջանակը երրորդն է։ Կանոնը հիմնված է նպատակակետի վրա, ուստի այդ հասցեին միացող յուրաքանչյուր գործընթաց օգտագործում է ուղիղ ուղին, լինի դա ձեր մտքում եղածը, թե ոչ։ Ընդհակառակը, կայքը կարող է պատասխանել մի քանի հասցեներից, ուստի մեկ /32-ի բացառումը չի բացառում կայքը։ Եթե իրական պահանջը ծրագրով երթուղավորումն է, ապա Community հաճախորդի երթուղիների աղյուսակը սխալ գործիք է։

Բացառության ստուգումն առանց ինքնախաբեության

Սկսեք տեղադրված երթուղուց, ոչ թե զննարկիչից։ Linux-ում հարցրեք միջուկին, թե որ երթուղին և հաջորդ ցատկն է այն օգտագործելու կոնկրետ հասցեի համար. Windows-ում կարդացեք երթուղիների աղյուսակը այդ /32-ի համար։ Համոզվեք, որ դարպասը ֆիզիկականն է, ոչ թե թունելը։ Եթե գրառումը բացակայում է, պրոֆիլը չի կիրառվել կամ հաճախորդը չի ունեցել երթուղիները փոխելու իրավունք։

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

Վերջում ստուգեք այն կառավարիչները, որոնք կարող են գերազանցել երթուղուն։ Հաճախորդի կողմի kill switch-ը կամ Windows-ի block-outside-dns կարգավորումը կարող են արգելել ուղիղ երթևեկությունը, ինչը երևում է որպես կապի ձախողում, թեև երթուղին ճիշտ է։ Չանջատեք այդ կառավարիչները, որպեսզի բացառությունը թվա աշխատող. եթե քաղաքականությունն արգելում է ուղիղ ուղին, ապա բացառությունը դիզայնի խնդիր է VPN ծառայության տիրոջ համար։

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