Вы падключаецеся па SSH да зборачнага хоста, запускаеце на ім VPN-кліент, і сесія перастае адказваць. Нічога не ўпала, і нішто не выглядае няправільна наладжаным у відавочным сэнсе. Кліент усталяваў маршрут па змаўчанні, таму адказы на вашу працоўную станцыю цяпер ідуць праз тунэль, дзе адрас вашай працоўнай станцыі не маршрутызуецца. Цікавае ў тым, што такі вынік быў прадказальным, а выпраўленне — гэта адзін маршрут, запісаны да запуску кліента. Выкажам здагадку: сервер з адным сеткавым адаптарам, шлюз 192.0.2.254 і адміністратар, які падключаецца з 203.0.113.9.

Запішыце шлях да запуску

ip route show default паказвае бягучы шлюз і інтэрфейс, а ip route get 203.0.113.9 паказвае, які інтэрфейс і адрас крыніцы ядро выкарыстае для вашай сесіі. Захавайце абодва вынікі. Пасля ўзняцця тунэля гэтыя дзве каманды павінны па-ранейшаму апісваць фізічны шлях, а калі яны апісваюць тунэль, сесія ўжо жыве ў пазычаным часе.

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

Замацуйце адрас у ўласнай канфігурацыі кліента

Маршрут, дададзены рукамі, знікае пасля перазагрузкі і спаборнічае з абнаўленнямі табліцы самога кліента, таму змясціце выключэнне туды, дзе табліцай кіруюць. У OpenVPN ключавое слова net_gateway разгортваецца ў шлюз, які існаваў да тунэля, таму route 203.0.113.9 255.255.255.255 net_gateway пакідае роўна адзін адрас па-за ім. WireGuard патрабуе іншага падыходу, бо wg-quick сам кіруе маршрутамі: усталюйце Table = off і дадайце выключэнне ў PostUp, з адпаведным PostDown, які яго выдаляе. Абедзве формы выражаюць адну і тую ж думку, і абедзве абмяжоўваюць выключэнне адным адрасам, а не паслабляюць тунэль для ўсяго.

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

Або прыбярыце галоўную табліцу з размовы

Калі некалькі службаў на хосце павінны захоўваць звычайны шлях, перастаньце рэдагаваць галоўную табліцу і дайце кліенту яго ўласную. Прастора імёнаў сеткі з парай veth робіць гэта чыста: маршрут па змаўчанні кліента жыве ў іншым стэку, і толькі працэсы, запушчаныя ўнутры яго, выкарыстоўваюць тунэль. Палітычная маршрутызацыя дасягае падобнага месца для аднаго пункта прызначэння, накіроўваючы адпаведны трафік у адмысловую табліцу, чый маршрут па змаўчанні ўсё яшчэ паказвае на фізічны шлюз. Любы з падыходаў пакідае галоўную табліцу хоста без новага маршруту па змаўчанні, і менавіта гэтая ўласцівасць трымае SSH адказным.

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

Меркавайце, што замацаванне можа не ўдацца

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

Дзве засцярогі каштуюць дзесяць хвілін. Вартавы, які спыняе кліент, калі пацвярджальны ўваход не з'яўляецца на працягу некалькіх хвілін, ператварае блакіроўку ў затрымку, а другая SSH-сесія, утрыманая адкрытай падчас змены, даказвае, што выключэнне працуе, пакуль тунэль узняты. Адны толькі keepalive тут не дапамагаюць, бо шлях знік, а не прастойвае; яны толькі робяць смерць больш прыкметнай.

Правярайце ў тым парадку, які мае значэнне

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

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

Падобныя артыкулы