SSH-ը VPN-ում ամեն րոպե ընկնում է՞

SSH-ը միանում է, աշխատում մոտ մեկ րոպե, ապա ամեն անգամ սառչում է մոտավորապես նույն միջակայքում։ Սովորական բացատրությունը idle timeout-ն է, այնպես որ մարդիկ իջեցնում են MTU-ն և կարգավորում հաճախորդի keepalive-ները։ WireGuard-ի այն կապը, որի վրա աշխատում էի, արդեն անցել էր այս ամենով՝ ավելի փոքր թունելի MTU, client-alive կարգավորումներ, կարգավորված թունելի keepalive։ Ընդհատումները շարունակվում էին անփոփոխ։ Պատճառը պարզվեց ասիմետրիկ LAN երթուղին, և այս օրինաչափությունն արժե ճանաչել, որովհետև այն հաղթում է ժամաչափերի վրա հիմնված ցանկացած ուղղում։

keepalive-ը ապացուցում է, որ ձեր հոսթը դեռ պատրաստ է ուղարկել։ Այն չի կարող ստիպել վիճակ պահող սարքին տեսնել պատասխան, որը երբեք չի անցնում դրա միջով։

Առասպելը՝ keepalive-ները շտկում են լուռ ընդհատումը

SSH-ի keepalive-ները գոյություն ունեն մեկ առաջադրանքի համար՝ թույլ չտալ, որ լռությունը հաշվող ինչ-որ բան մաքրի պարապ սեսիան։ Դա նրանք լավ են անում։ Նրանք չեն լուծում վիճակ պահող սարքի խնդիրը, որը տեսել է առաջին փաթեթը մեկ ուղղությամբ և հետո երբեք չի տեսել պատասխանը, որովհետև այն, ինչ հաճախորդն ուղարկում է, չի փոխում, թե պատասխանը որ ինտերֆեյսն է օգտագործում։

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

Նշանը կանոնավորությունն է՝ զուգորդված սեսիայի հետ, որը մնում է օգտագործելի այդ միջակայքի ընթացքում։ Պարապ timeout-ները հարվածում են, երբ ոչինչ չի լինում։ Այս մեկը հարվածում է, երբ դուք մուտքագրում եք։

Ինչ է իրականում անում լրացուցիչ gateway-ը

Տեղադրեք նոութբուքը և VPN-ի gateway-ը նույն LAN-ում՝ առանձին LAN firewall-ով որպես լռելյայն gateway։ Նոութբուքը VPN-ի ուղղված թրաֆիկն ուղարկում է firewall-ին, firewall-ը փոխանցում է այն gateway-ին, և gateway-ի պատասխանները ուղիղ վերադառնում են LAN-ով դեպի նոութբուքը։ Այդ երկրորդ ոտքը երբեք չի անցնում firewall-ով, ուստի նրա վիճակի աղյուսակը պահում է կիսով չափ կապ։

Ստորև բերված հասցեները արտացոլում են այդ դասավորությունը։

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

Վերահղումները և վիճակի կառավարումը այնուհետև աշխատող handshake-ը վերածում են կապի, որը մահանում է ավելի ուշ, ոչ թե անմիջապես։ Ուշացումը վիճակի գրառման հնացումն է կամ ավելի խիստ ստուգման ձախողումը, և ահա թե ինչու միջակայքը այդքան մեխանիկական է թվում։

Այս ամենից ոչինչ չի երևում հաճախորդի կարգավորումներում, և ահա թե ինչու դրա որոնումը սովորաբար սկսվում է սխալ ֆայլում։

Ընտրեք մեկ դիտավորյալ ուղի

Վերևի դասավորության համար հեռավոր ենթացանցը ուղղակիորեն VPN-ի gateway-ով երթուղելը վերացնում է կիսով չափ կապը։

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

Սրանք օրինակելի հասցեներ են։ Հաջորդ hop-ը պետք է հասանելի լինի ձեր LAN-ում, prefix-ը պետք է լինի նախատեսված հեռավոր ցանցը, և երկրորդ հրամանը ցույց է տալիս արդյունքը, նախքան դրա վրա հույս դնելը։ Եթե gateway-ը ձեր ենթացանցում չէ, այս երթուղին այն ուղղումը չէ, որը դուք ուզում եք։

Եթե firewall-ը պետք է վերահսկի այդ համակարգերի միջև թրաֆիկը, ապա դրա շուրջը երթուղելը սխալ ձևավորում է։ Փոխարենը թույլ տվեք, որ երկու ուղղություններն էլ անցնեն սահմանով, և կարգավորեք երթուղիները յուրաքանչյուր կողմում այնպես, որ վերադարձի ուղին համընկնի։ Նպատակը մեկ դիտավորյալ ուղի է, ոչ թե ավելի քիչ վիճակի ստուգում։

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

Փորձարկեք երկու ծայրերից

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

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

Երբ ասիմետրիան նորմալ է

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

Կայուն պատասխանը նշում է երկու ուղիները, այն սարքը, որը պետք է տեսնի երկուսն էլ, և այն երթուղին, որ դա հնարավոր է դարձնում։ Եթե չեք կարող անվանել սարքը, ուրեմն դեռ չեք գտել պատճառը։