Լրիվ թունելը սպանեց ձեր SSH սեսիան՝ ամրացրեք վերադարձի ուղին

Միացրեք OpenVPN հաճախորդը այն մեքենայի վրա, որտեղ աշխատում եք SSH-ով, և հրամանի կեսին սեսիան սառչում է։ Թունելը հայտնում է, որ միացած է, հոսթը դրա միջոցով հասնում է ինտերնետ, և ձեր ստեղնասեղմումները դեռ հասնում են, մինչդեռ ոչինչ չի վերադառնում։ Փոխվել է ոչ թե թունելը՝ դա ձեզ հասցեագրված փաթեթների վերադարձի ուղին է, որը հիմա համապատասխանում է նոր կանխադրված երթուղուն և մտնում է մի թունել, որը հեռավոր դարպասը չի օգտագործի ձեր սեղանին հասնելու համար։

Ինչ է իրականում տեղադրում redirect-gateway-ը

Իր def1 ձևով redirect-gateway ավելացնում է 0.0.0.0/1 և 128.0.0.0/1՝ կանխադրված երթուղին վերագրելու փոխարեն։ Այս երկու կեսերը ծածկում են ամբողջ հասցեային տարածությունը, և երկուսն էլ մնում են ավելի երկար նախածանցեր, քան 0.0.0.0/0, այնպես որ առանց ավելի կոնկրետ համընկնման ցանկացած նպատակակետ հիմա մտնում է թունել։ Սա այն մեխանիզմն է, որը պետք է հիշել, որովհետև ներքևի յուրաքանչյուր ուղղում աշխատում է ավելի կոնկրետ համընկնում տեղադրելով։

Ձեր ադմինիստրատիվ հասցեն այդ նպատակակետերից մեկն է։

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

ip route show table main | head -n 20
ip route get 198.51.100.23

Գտեք ձեր աղբյուրի հասցեն և թունելից առաջ ընկած ուղին

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

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

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

Ամրացրեք հոսթի երթուղի, որը գերազանցում է կիսականխադրվածներին

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

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

Ստուգեք որոնմամբ, ոչ թե աղյուսակը զննելով՝ պատասխանը պետք է eth0 և դարպասը նշի, երբեք՝ tun0։

OpenVPN-ն արդեն ավելացնում է հոսթի երթուղի հենց VPN սերվերի հասցեին նույն պատճառով, ուստի օրինաչափը ծանոթ է, և ադմինիստրատիվ հասցեն պարզապես ևս մեկ բացառություն է։ Մի՛ դիմեք route-nopull-ին այս ուղղման համար, որովհետև այն դեն է նետում թունելին անհրաժեշտ մղված երթուղիները, ներառյալ հեռավոր ցանցը և DNS ընտրանքները։

Դարձրեք այն դիմացկուն վերամիացման նկատմամբ

Ձեռքով ավելացված երթուղին անհետանում է, երբ հաճախորդը նորից միանում է և տեղադրում իր սեփականը, ինչը ուղղումը դարձնում է կրկնվող խափանում։ Կապեք հրամանը մի բանի հետ, որն աշխատում է երթուղիների տեղադրումից հետո։

Ե՛վ route-up սկրիպտը, և՛ ցանցի կառավարչի pre-up կեռը աշխատում են, և հուսալի ստուգումը վերամիացումն է, որին հետևում է նույն որոնումը։

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

Երբ ամրացված երթուղին դեռ բավարար չէ

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

Քաղաքականությամբ պայմանավորված երթուղավորում ունեցող հոսթները կանոնի կարիք ունեն ինչպես նաև երթուղու, որովհետև կանոնների բազան ընտրում է աղյուսակը նախքան դրա ներսի երթուղին դիտարկելը։ main աղյուսակի երթուղին անտեսանելի է այն հոսքի համար, որը համընկնում է մեկ այլ աղյուսակ մատնանշող կանոնի հետ։ Կարդացեք կանոնները նախքան main-ին որևէ բան ավելացնելը։ Եթե կանոնն արդեն ծածկում է կառավարման երթևեկությունը, բացառությունը պատկանում է այդ կանոնի աղյուսակին։

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