SSH VPN-де әр минут сайын үзіледі? Себеп keepalive емес

Қайталанатын аралықта өлетін сессия әдетте firewall күйін жоғалтады, keepalive-тарды емес. MTU немесе таймерлерге тимес бұрын екі бағытты да бақылаңыз.

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

Бұлар мысал мекенжайлар. Келесі хоп сіздің LAN-да қолжетімді болуы керек, префикс көзделген қашықтағы желі болуы керек, ал екінші команда оған сенбес бұрын нәтижені көрсетеді. Егер gateway сіздің қосалқы желіңізде болмаса, бұл маршрут сіз қалаған түзету емес.

Егер firewall сол жүйелер арасындағы трафикті қадағалауға арналса, оны айналып өту дұрыс емес дизайн. Оның орнына екі бағытты да шекарадан өткізіп, қайтару жолы сәйкес келуі үшін әр жақтағы маршруттарды конфигурациялаңыз. Мақсат — бір әдейі таңдалған жол, күйді тексеруді азайту емес.

Netgate-тің асимметриялық маршруттау туралы жазбалар интерфейс деңгейіндегі сол асимметрияны және оның туғызатын күй мәселелерін сипаттайды, сондықтан күй өңдеуді жаһандық түрде босаңсытпас бұрын оларды оқыңыз. Бұл жағдайға ұқсас уақыттық ажыраулар өздігінен дәлел емес. Мақаланы бір сәтсіздік режимінің сипаттамасы ретінде қабылдаңыз, содан кейін жаһандық күй саясатын өзгерту алдында өз желіңіздің оған сәйкес келетінін дәлелдеңіз.

Екі ұшынан да тексеріңіз

Ноутбуктің мақсатқа қарай маршрутын және мақсаттың ноутбукке қарай қайтару маршрутын оқыңыз; бұл екі бөлек шешім және олардың тек біреуі ғана қате болуы мүмкін. Gateway-дің өзінен сәтті өткен ping мәселені толығымен жасыра алады, өйткені ол жолы әлдеқашан дұрыс машинадан басталады. Сізге нақты сессияның екі ұшы көретін екі бағыт қажет.

Түзетуден кейін SSH-ды қайта ашып, сессияны бұрын сәтсіз болған аралықтан әлдеқайда ұзақ ашық ұстаңыз. Содан кейін маршрутты бекітілген желі конфигурациясында тұрақты етіп жасаңыз, өйткені бір реттік команда қайта жүктеу жоспары емес және мәселе келесі қайта жүктеуде жаңа жұмбақпен қайтады.

Асимметрия қашан қалыпты

Асимметриялық маршруттау көптеген желілерде қалыпты және анықтама бойынша бұзылған емес. Ол күйді бақылау, трансляция немесе саясат өздері көрмейтін жолды көруге тәуелді болғанда мәселеге айналады, және олардың әрқайсысының өз емі бар. Оның айналасында қайта жобалау алдында ортаңғы құрылғының шын мәнінде не қажет ететінін тексеріңіз.

Тұрақты жауап екі жолды, екеуін де көруі керек құрылғыны және мұны мүмкін ететін маршрутты атайды. Егер құрылғыны атай алмасаңыз, себепті әлі таппадыңыз.

Қатысты мақалалар