OpenVPN redirect-gateway. ինչ է անում յուրաքանչյուր դրոշը երթուղիների հետ

Միացեք պրոֆիլում redirect-gateway-ով, և ձեր մեքենայի լռելյայն երթուղին կարող է անհետանալ, երկուսի բաժանվել կամ մնալ հենց այնտեղ, որտեղ եղել է՝ կախված դրոշներից, որոնք ոչ ոք երկու անգամ չի կարդում։ Տարբերակը փոխում է միայն երթուղայնացման վիճակը և ուրիշ ոչինչ, ուստի դրա արածի միակ վստահելի ապացույցը այն աղյուսակն է, որը հաճախորդը տեղադրել է դրանից հետո։ Հետևում է միացումից հետո աղյուսակը, երթուղին, որը կենդանի է պահում հենց թունելը, և IPv6 երթևեկությունը, որը հրահանգը երբեք չի պնդում ծածկել։ Յուրաքանչյուր քայլ հրաման է, որը կարող եք կատարել հաճախորդի վրա, քանի դեռ թունելը միացված է։

Ինչ է անում յուրաքանչյուր դրոշը լռելյայն երթուղու հետ

Առանց որևէ դրոշի, տարբերակը հեռացնում է սովորական լռելյայն երթուղին և դրա փոխարեն դնում թունելը, այնպես որ հին դարպասը անհետանում է աղյուսակից, քանի դեռ միացումը կա։ Ավելացրեք def1 և այդ լռելյայնը մնում է ցանկում, աշխատանքը կատարում են երկու ավելի նեղ երթուղիներ։ Ավելացրեք bypass-dhcp և DHCP երթուղին նույնպես գոյատևում է, ինչը կարևոր է ցանցում, որտեղ հաճախորդը դեռ պետք է հասնի տեղական DHCP սերվերին։ Դրոշների ցանկը OpenVPN 2.6 ձեռնարկի էջում բավական կարճ է մեկ անգամ կարդալու համար, և յուրաքանչյուր գրառում փոխում է, թե որ երթուղիներն են հայտնվում աղյուսակում։

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

def1-ը հաղթում է հստակությամբ՝ չդիպչելով ձեր լռելյայնին

Երկու կիսալռելյայն երթուղիներ միասին ծածկում են IPv4 տարածությունը՝ 0.0.0.0/1 և 128.0.0.0/1։ Յուրաքանչյուրը ավելի հստակ է, քան 0.0.0.0/0-ն, ուստի որոնումը նախընտրում է նրանց, մինչ իրական լռելյայնը մնում է աղյուսակում այն ամենի համար, ինչ պահանջում է ամենաքիչ հստակ համընկնումը։

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

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

Ուշադրություն դարձրեք յուրաքանչյուր տողի ինտերֆեյսին և չափիչին, ոչ միայն նպատակակետին։ Դեպի թունելն ուղղված լռելյայնը և դեպի թունելն ուղղված կիսալռելյայնների զույգը նկարագրում են նույն մտադրությունը և տարբեր կերպ են ձախողվում, երբ թունելն ընկնում է, որովհետև մի դեպքում պահուստը դեռ գոյություն ունի։ Գրանցեք երկու դաշտերն էլ փոփոխության նշումում։ Փրկված պահուստը երբեմն այն է, ինչը հեռավոր նստաշրջանը բավական երկար է կենդանի պահում թունելը վերանորոգելու համար, և հենց այն է, ինչը արտահոսում է երթևեկությունը, երբ մտադրությունը լրիվ թունել էր։

Թողեք թունելի վերջնակետը հասանելի

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

Հարցրեք միջուկին, թե որ ինտերֆեյսը կօգտագործի ծայրակետի հասցեի համար, քանի դեռ թունելը միացված է։ Պատասխանը պետք է նշի ֆիզիկական ինտերֆեյսը և դրա դարպասը, երբեք tun0՝

ip route get 198.51.100.20

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

IPv6 երթևեկությունը շարունակում է օգտագործել իր աղյուսակը

IPv4-ի վերաուղղորդումը թողնում է IPv6-ին հանգիստ, և երկու ընտանիքները փոխվում են տարբեր դրոշներով։ Երկակի կույտով հոսթում, որտեղ աշխատում է v6 լռելյայնը, v4 երթևեկությունը կարող է ամբողջությամբ նստել թունելի ներսում, մինչ յուրաքանչյուր v6-ընդունակ նպատակակետ դուրս է գալիս ֆիզիկական կապով։ Հոսթը, որը մեկ աղյուսակում ճիշտ է թվում, արտահոսում է մյուսում։

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

ip -6 route show default
ip -6 route get 2001:db8::10

Ապացուցեք, թե որ ինտերֆեյսն է օգտագործում հավելվածը

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

Փորձարկեք այն ուղին, որն իսկապես անցնում է հավելվածը, ոչ թե այն ուղին, որը նկարագրում է պրոֆիլը։ Նախ հարցրեք երթուղին, ապա հերթով կապեք հարցումը յուրաքանչյուր ինտերֆեյսին և համեմատեք, ինչ է հայտնում հեռավոր կողմը՝

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

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