Ці можа вандравальны кліент VPN размяшчаць службу для офіса?

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

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

Кірунак падключэння нічога не кажа пра кірунак службы

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

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

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

Прасачыце зваротны шлях, перш чым адкрываць порт

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

Добрая навіна ў тым, што ўнутраны шлях не патрабуе перасылкі порта на хатнім роўтары кліента. Менавіта ў гэтым сэнс публікацыі службы на адрасе тунеля, а не на хатнім адрасе WAN, дзе экспазіцыя і правілы NAT былі б зусім іншымі. Хатні роўтар можа таксама адмовіцца заганяць злучэнне, якое прыходзіць з офіса, таму маршрут праз WAN выходзіць з ладу па прычынах, не звязаных з вашым VPN. Захаванне трафіку ўнутры тунеля пазбаўляе ад абодвух праблем адразу.

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

Імёны і адрасы — гэта рашэнні дызайну

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

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

Узгадніце імя з тым, хто валодае ідэнтычнасцю VPN, каб запіс, прызначэнне адраса і палітыка доступу змяняліся разам, а не ў трох асобных заяўках.

Тэстуйце службу, а не членства

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

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

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

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

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

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