Поўны тунэль забіў вашу SSH-сесію: замацуйце зваротны маршрут
Поўны тунэль перахоплівае і адказы на вашу ўласную 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. Калі правіла ўжо пакрывае трафік кіравання, вынятак належыць хутчэй табліцы гэтага правіла.
Трымайце адкрытую пазапалосную кансоль падчас тэставання і пераправерце з другога ўваходу, перш чым адключыць той, якім карыстаецеся. Маршрут, які адпраўляе ваш уласны трафік кіравання ў тунэль, пераразае злучэнне, праз якое вы яго рамантуеце. Вярнуцца тады давядзецца праз серыйную кансоль або выратавальную загрузку, што дрэнны абмен за пропуск аднаго кроку праверкі.