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

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

Дзве межы падтрымкі, а не два ўсталёўшчыкі

Прачытайце актуальную старонку ўсталявання пастаўшчыка для патрэбнай праграмы і супастаўце яе з платай: выпуск дыстрыбутыва, архітэктура пакета і любыя патрабаванні да працоўнага стала або сеанса. Тое, што Pi падтрымлівае 64-бітную працу, не гаворыць, якая прастора карыстальніка ўсталявана зараз, а менавіта гэта правярае менеджар пакетаў. dpkg --print-architecture і uname -m адказваюць на гэта па адным радку кожны. Калі выпуск або архітэктура выходзяць за межы дакументаванага набору, праграма там не падтрымліваецца, нават калі ўсталёўваецца.

Падтрымка таксама залежыць ад спосабу пакавання. Абмежаванне, задокументаванае для аднаго фармату пакета, не распаўсюджваецца аўтаматычна на зборку з рэпазіторыя, а дыстрыбутыў на аснове Debian не з’яўляецца аўтаматычна падтрыманым асяроддзем. Супольныя пакеты і старыя рэцэпты ўсталявання прыносяць уласную мадэль абслугоўвання, якую можна свядома прыняць, але не варта прымаць выпадкова.

Што праграма дае, а профіль не

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

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

WireGuard уручную: крокі, якія маюць значэнне

Пастаўшчык дакументуе стварэнне канфігурацыі WireGuard для сумяшчальнага са стандартам кліента і рэкамендуе гэты шлях для ручной налады, пакідаючы OpenVPN для старых прылад. Стварыце профіль у панэлі акаўнта, перанясіце яго на Pi і змясціце туды, дзе яго можа прачытаць толькі ўладальнік. Ніколі не ўстаўляйце файл у тэму падтрымкі, бо прыязная назва файла не робіць убудаваны прыватны ключ прыдатным да публікацыі. Затым праверце тунель адным запытам, перш чым падключаць да яго што-небудзь яшчэ.

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

Вырашыце, ці з’яўляецца Pi таксама шлюзам

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

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

Міф, які варта адкінуць, — што ўсталёўшчык Linux і файл WireGuard уяўляюць адно і тое ж рашэнне. Гэта дзве мадэлі працы з двума рознымі ўладальнікамі.

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