Ինչու ամբողջական թունելի երթուղին կտրում է այն տեղափոխող սերվերը

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

Երթուղի, որը ուտում է իր իսկ տրանսպորտը

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

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

Ամենաերկար նախածանցի համընկնումը որոշում է որոնումը նախքան որևէ մետրիկայի նայելը, ուստի մեկ հասցեի երթուղին գերազանցում է մեքենայի բոլոր լռելյայն երթուղիներին։ Սա է վերանորոգման ամբողջ մեխանիզմը։

Տեղադրեք բացառությունը լռելյայնից առաջ

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

Հաճախորդների մեծ մասը դա անում է առանց խնդրանքի։ OpenVPN որոնում է հեռավոր հասցեն և ամրացնում այն նախքան լռելյայն դարպասը վերաշարադրելը, և դրա route-delay ընտրանքը գոյություն ունի այն հարթակների համար, որտեղ այդ հաջորդականությունը մրցում է։ wg-quick-ը գնում է բոլորովին այլ ճանապարհով, նշելով փաթեթները և խորհրդակցելով քաղաքականության կանոնի հետ բացառություն ավելացնելու փոխարեն։ Տարբեր մեխանիզմներ, նույն պահանջը՝ արտաքին փաթեթը պետք է փախչի իր ստեղծած թունելից։

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

Որոնման ելքը ընդունման թեստն է։ Այն պետք է նշի ֆիզիկական սարքը և ֆիզիկական հաջորդ ցատկը։ Այդ պատասխանում թունելային սարքը նշանակում է, որ բացառությունը բացակայում է կամ տեղադրվել է մի բանից հետո, որը վերացնում է այն։

Հայելային պատկերը սերվերի վրա

Նույն թակարդը սպասում է մյուս կողմում՝ հակադարձված։ Տվեք սերվերին լռելյայն երթուղի մեկ այլ թունելով, կամ հրեք նրան երթուղի, որը ծածկում է հաճախորդների հանրային հասցեները, և նրա պատասխանները կձեռք բերեն սխալ ուղղության սովորություն։

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

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

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

Բացառություններ, որոնք թունելը շարունակ գողանում է

Մի բուռ առաջադրանքներ պետք է բաց ինտերնետ, նույնիսկ երբ թունելը տիրապետում է լռելյայն երթուղուն, և յուրաքանչյուրին պետք է իր սեփական բացառությունը։ Դինամիկ DNS թարմացնողը սովորաբար առաջինն է, որ կոտրվում է։

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

Բացառությունը, որը ոչ ոք չի գրել, այն բացառությունն է, որը հաջորդ վերակառուցումը լուռ կթողնի։

Ապացուցեք դա վերամիացումից հետո, ոչ թե առաջ

Փորձարկեք երեք նպատակակետ, ոչ թե մեկը՝ վերջնակետը, թունելի հետևում գտնվող մասնավոր հասցե և դրանից այն կողմ գտնվող հանրային հասցե։ Մեկ հաջող որոնում գրեթե ոչինչ չի ասում մյուս երկուսի մասին։

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

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