UDP-ով VPN-ը պարապ ժամանակ կանգ է առնում. firewall-ը մոռացել է ձեր հոսքը

VPN-ը միանում է, որոշ ժամանակ աշխատում և հետո դադարում է տրաֆիկ անցկացնել, մինչ client-ը դեռ ցույց է տալիս սեսիա։ Վերամիացումը շտկում է այն, ինչի պատճառով թվում է, թե client-ի սխալ է։ Սովորաբար դա firewall կամ NAT սարք է, որը գցել է պարապ UDP քարտեզագրումը և չգիտի, որ թունելը դեռ գոյություն ունի։

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

Ինչպիսին է պարապ կանգը

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

Երկուսն էլ կապված են անգործության հետ և տարբեր շտկումներ են պահանջում։

Գրի առեք ժամանակները, նախքան ինչ-որ բան փոխելը։ Հաղորդումը, որ այն կանգ է առնում մոտ տասը պարապ րոպեից հետո, ստուգելի է, մինչդեռ հաղորդումը, որ այն ընկնում է պատահականորեն, ստուգելի չէ։ Այդ տարբերությունը որոշում է՝ հետևու՞մ եք ժամանակաչափին, թե՞ երթուղու փոփոխությանը։

Գտեք սարքը, որը մոռացել է

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

Մի ենթադրեք, որ փաստաթղթավորված կանխադրվածը ձեր ուղու ժամկետն է։ Դա մեկ սարքի կանխադրվածն է։

• Տնային երթուղիչ. հաճախ րոպեներ, երբեմն՝ շատ ավելի քիչ։
• Ամպային NAT կամ բեռնվածքի հավասարակշռիչ. փնտրեք փաստաթղթավորված պարապ ժամկետը հատուկ UDP-ի համար։
• Host-ի firewall. netfilter-ի հետևման ժամանակաչափերը գործում են յուրաքանչյուր հոսքի համար։

Ստուգեք ժամանակաչափերը իրական ուղու վրա

Linux-ում netfilter-ի հետևման ժամանակաչափերը տեսանելի են և կարգավորելի. sysctl net.netfilter.nf_conntrack_udp_timeout և net.netfilter.nf_conntrack_udp_timeout_stream։ Երկրորդը գործում է, երբ տրաֆիկ արդեն տեսել են երկու ուղղություններով, ինչի պատճառով հաստատված թունելը կարող է ապրել սովորական փորձարկումից ավելի։

RFC 4787 սահմանում է UDP NAT-ի վարքը և առաջարկվող նվազագույնները։ Սա այն հղումն է, որին պետք է վկայակոչել, երբ մատակարարի կանխադրվածը անսովոր կարճ է թվում։

Keepalive-ը և վերամիացումը տարբեր գործիքներ են

Keepalive-ը քարտեզագրումը կենդանի է պահում. վերամիացումը նորից կառուցում է մեռած սեսիան։ Նրանք լուծում են տարբեր խափանումներ և փոխանակելի արագության կարգավորումներ չեն։ WireGuard-ի PersistentKeepalive տարբերակը ֆիքսված պարբերությամբ փաթեթ է ուղարկում՝ NAT կապը բաց պահելու համար։ OpenVPN-ի keepalive տարբերակը նույն աշխատանքն անում է իր ձևով։ Ոչ մեկը չի օգնում, եթե մեջտեղի սարքն արդեն մոռացել է հոսքը և գցում է երկու ուղղությունները։

Չափազանց հաճախակի փորձարկումները աշխատանք են ավելացնում՝ չուղղելով սխալ սահմանը։

Ստուգեք նոր հարցումով, ոչ էջի վերաբեռնմամբ

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

Եթե կանգը շարունակվում է, մեկ ցատկ շարժվեք դեպի դուրս և ստուգեք այդ սարքի վիճակների աղյուսակը։