Працоўны VPN на Raspberry Pi: спачатку задайце гэтыя пытанні

Чатыры адказы ад працадаўцы вырашаюць, ці можа Pi далучыцца да працоўнага VPN: які пратакол шлюза ён выкарыстоўвае, якія аперацыйныя сістэмы і архітэктуры падтрымлівае, як павінна адбывацца аўтэнтыфікацыя і ці дазволены кліент, адрозны ад афіцыйнага. URL партала і слова Linux не вырашаюць нічога з гэтага. Спытайце перад спампоўкай чаго-небудзь, бо адказы змяняюць, які пакет вы ўсталюеце і ці ўвогуле жыццяздольная наладка без графічнай абалонкі.

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

Пратакол шлюза вызначае кліент

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

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

Архітэктура — не дробязь

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

64-бітная прастора карыстальніка на 64-бітным ядры — гэта просты выпадак; 32-бітная прастора карыстальніка на 64-бітнай плаце — гэта месца, дзе людзі ўсталёўваюць не той пакет. dpkg --print-architecture і uname -m адказваюць на абедзве часткі па адным радку.

Аўтэнтыфікацыя вызначае працэс

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

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

Захавайце межы працадаўцы

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

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

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