Nextcloud толькі праз VPN: спачатку апішыце ўсе ўваходы

План Nextcloud толькі праз VPN правальваецца, калі абараняе браўзер і забывае кліент сінхранізацыі. Вэб-старонцы, рухавіку сінхранізацыі на камп'ютары, мабільным запампаванням, інструментам WebDAV і атрымальнікам агульных спасылак патрэбны шлях да таго самага сэрвісу, і кожны з іх можа адкрыць іншы ўваход. Апішыце іх, перш чым нешта зачыняць. Гэты спіс і ёсць сапраўдны перыметр.

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

Вызначце прыватнае, перш чым змяняць перыметр

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

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

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

Апішыце кожны ўваход і кожнае імя

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

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

Затым заблакуйце ўваходы, якія вы не выбралі. Прыватны backend з публічным фронтэндам гэта не схема толькі праз VPN, а правіла брандмаўэра, што ахоплівае толькі IPv4, пакідае IPv6-слухач адкрытым. Зачыніце абедзве сям'і і абедзве імёны ў адной змене.

Дайце кожнаму кліенту адно імя сэрвісу

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

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

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

Абмяжуйце сеткавы доступ, а не ўсю лакальную сетку

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

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

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

Разгледзьце кожны працоўны працэс па-за браўзерам

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

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

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

Федэрацыя і інтэграцыі сервер-сервер патрабуюць такога ж падыходу. Гэта адносіны дасягальнасці паміж усталёўкамі, і разгортванне толькі прыватнае павінна сказаць, ці яны падтрымліваюцца.

Прыміце і дазволены, і адхілены выпадак

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

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

Нарэшце, разгледзьце налады праграмы, якія лёгка зблытаць з сеткавай палітыкай. trusted_domains пералічвае імёны, якія прымае экзэмпляр; гэта не спіс дазволеных IP-адрасоў кліентаў. Калі зваротны проксі падае інфармацыю пра адрас, trusted_proxies павінен назваць фактычны проксі, і перададзеныя загалоўкі трэба прымаць толькі ад яго.

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