Хто павінен валодаць маршрутамі і DNS, калі openfortivpn падключаецца?

У працоўным сеансе openfortivpn чатыры этапы накладаюцца адзін на другі. Кліент аўтэнтыфікуецца на шлюзе і пачынае TLS-злучэнне, потым запускае PPP унутры гэтага злучэння, потым атрымлівае адрас і звесткі DNS, а ўрэшце ўжывае маршруты хаста і налады рэзалвера. Кожны этап можа быць жывым, пакуль наступны — не, і менавіта таму “падключана” — такое слізкае слова ў абмеркаваннях падтрымкі.

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

Чатыры этапы, якія выглядаюць як адно злучэнне

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

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

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

Хто рэдагуе табліцу маршрутызацыі

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

Выбірайце перадачу толькі тады, калі нешта іншае сапраўды валодае маршрутызацыяй. Інтэграцыя сеткавага менеджара, сеткавы прастора імёнаў кантэйнера або агент маршрутызацыі ўсяго сайта можа ўжо ведаць, як усталёўваць і прыбіраць тыя ж прэфіксы. Перадача опцыі no-routes тады перашкаджае двум пісьменнікам ваяваць за адну табліцу, а гэта гонка, якая выглядае як перарывістая страта адной падсеткі, а не як чысты збой.

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

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

Хто валодае DNS і файлам рэзалвера

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

На сучасным Linux-хасце рэзалверам можа кіраваць лакальны стуб, і перапісванне файла рэзалвера за спінай гэтага стуба стварае канфігурацыю, якая выглядае правільнай і паводзіць сябе непаслядоўна. Калі хаст ужо запускае менеджар рэзалвера, дайце яму валодаць DNS і падайце яму серверы тунэля праз яго падтрыманы інтэрфейс. Опцыя no-dns кліента — правільны выбар там, а не абыход.

Раздзелены DNS — асобнае пытанне ад таго, хто піша файл. Адпраўка кожнага запыту праз тунэль простая і павольная; адпраўка толькі ўнутраных зон праз яго патрабуе па-дамэнных налад, якіх большасць простых кліентаў не дае. Вырашыце, якія паводзіны патрэбныя хасту, перш чым уключаць змены рэзалвера кліента. Няправільны выбар тут выглядае як збой развязання імёнаў, нават калі сам тунэль у парадку.

Прывілеі, гатоўнасць і перадача

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

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

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