SSH абрываецца ў VPN кожную хвіліну? Прычына не ў keepalive

SSH падключаецца, працуе каля хвіліны, потым замярзае прыкладна праз аднолькавы інтэрвал кожны раз. Звычайнае тлумачэнне — таймаўт прастою, таму людзі зніжаюць MTU і настроіўваюць кліенцкія keepalive. Спасылка WireGuard, над якой я працаваў, ужо прайшла праз усё гэта: меншы MTU тунеля, налады client-alive, наладжаны keepalive тунеля. Абрывы працягваліся без змен. Прычынай аказаўся асіметрычны маршрут у LAN, і гэты ўзор варта распазнаваць, бо ён перамагае любое выпраўленне на аснове таймераў.

Keepalive даказвае, што ваш хост яшчэ гатовы адпраўляць. Ён не можа прымусіць прыладу, якая вядзе стан, убачыць адказ, які ніколі праз яе не праходзіць.

Міф: keepalive выпраўляюць ціхі абрыў

Keepalive у SSH існуюць для адной задачы: каб нешта, што лічыць цішыню, не забіла прастойную сесію. З гэтым яны спраўляюцца добра. Яны не вырашаюць праблему прылады са станам, якая ўбачыла першы пакет у адным напрамку і больш ніколі не бачыла адказу, бо нішто з таго, што шле кліент, не змяняе інтэрфейс, праз які ідзе адказ.

Змяненне MTU — другое папулярнае выпраўленне, і яно мае такі ж рэжым адмовы. Зніжэнне MTU дапамагае з фрагментацыяй і праблемамі MTU шляху, і яно нічога не робіць для маршруту. Калі вашыя таймеры і MTU ужо разумныя, а абрыў усё яшчэ на паўтаральным інтэрвале, інтэрвал кажа вам пра таймаўт недзе, а не пра памер пакета. Запішыце інтэрвал і параўнайце яго з таймаўтамі стану на кожнай прыладзе ў шляху.

Прыкмета — рэгулярнасць у спалучэнні з сесіяй, якая застаецца прыдатнай унутры гэтага інтэрвалу. Таймаўты прастою ўдараюць, калі нічога не адбываецца; гэты — калі вы друкуеце.

Што насамрэч робіць дадатковы шлюз

Паставіце ноўтбук і VPN-шлюз у адну LAN, а асобны LAN-файрвол — як шлюз па змаўчанні. Ноўтбук шле трафік, накіраваны ў VPN, на файрвол, файрвол перадае яго шлюзу, і адказы шлюза вяртаюцца напрамкі праз LAN на ноўтбук. Гэтая другая нага ніколі не праходзіць праз файрвол, таму яго табліца стану трымае палову злучэння.

Адрасы ніжэй адлюстроўваюць гэтую схему:

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

Перанакіраванні і апрацоўка стану потым ператвараюць працоўнае рукапацісканне ў злучэнне, якое памірае пазней, а не адразу. Затрымка — гэта старэнне запісу стану або правал больш строгай праверкі, таму інтэрвал выглядае так механічна.

Нічога з гэтага не з'яўляецца ў канфігурацыі кліента, таму пошук звычайна пачынаецца не ў тым файле.

Абярыце адзін свядомы шлях

Для схемы вышэй маршрутызацыя аддаленай падсеткі напрамкі на VPN-шлюз прыбірае палову злучэння:

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

Гэта прыкладныя адрасы. Наступны хоп павінен быць дасяжным у вашай LAN, прэфікс павінен быць патрэбнай аддаленай сеткай, а другая каманда пакажа вам вынік, перш чым вы на яго паложыцеся. Калі шлюз не ў вашай падсетцы, гэты маршрут не тое выпраўленне, якое вам патрэбна.

Калі файрвол павінен кантраляваць трафік паміж гэтымі сістэмамі, маршрутызацыя вакол яго — няправільны дызайн. Замест гэтага прымусьце абодва напрамкі перасякаць мяжу і наладзьце маршруты з кожнага боку так, каб зваротны шлях супадаў. Мэта — адзін свядомы шлях, а не менш праверкі стану.

нататкі пра асіметрычную маршрутызацыю ад Netgate апісваюць тую ж асіметрыю на ўзроўні інтэрфейса і праблемы стану, якія яна стварае, таму прачытайце іх, перш чым паслабляць апрацоўку стану глабальна. Часавыя адключэнні, падобныя на гэты выпадак, самі па сабе не з'яўляюцца доказам. Разглядайце артыкул як апісанне аднаго рэжыму адмовы, затым дакажыце, што ваша ўласная сетка адпавядае яму, перш чым змяняць глабальную палітыку стану.

Праверце з абодвух бакоў

Прачытайце маршрут ноўтбука да прызначэння і маршрут прызначэння назад да ноўтбука; гэта два асобныя рашэнні, і, верагодна, толькі адно з іх няправільнае. Ping, які паспяхова ідзе з самога шлюза, можа цалкам схаваць праблему, бо ён пачынаецца на машыне, чый шлях ужо правільны. Вам патрэбны абодва напрамкі так, як іх бачаць два канцы рэальнай сесіі.

Пасля выпраўлення зноў адкрыйце SSH і трымайце сесію адкрытай значна даўжэй за інтэрвал, які раней падаў. Затым зрабіце маршрут пастаянным у зацверджанай канфігурацыі сеткі, бо разовая каманда — не план перазагрузкі, і праблема вернецца пры наступнай перазагрузцы з новай загадкай.

Калі асіметрыя нармальная

Асіметрычная маршрутызацыя нармальная ў многіх сетках і не з'яўляецца памылкай па вызначэнні. Яна становіцца праблемай, калі адсочванне стану, трансляцыя або палітыка залежаць ад бачання шляху, якога яна не бачыць, і ў кожнага з гэтага ёсць сваё лячэнне. Праверце, што насамрэч патрабуе сярэдняя прылада, перш чым перабудоўваць вакол яе.

Трывалы адказ называе два шляхі, прыладу, якой трэба бачыць абодва, і маршрут, які робіць гэта магчымым. Калі вы не можаце назваць прыладу, вы яшчэ не знайшлі прычыну.