Nextcloud planas tik per VPN žlunga, kai apsaugo naršyklę ir pamiršta sinchronizavimo klientą. Interneto puslapiui, darbalaukio sinchronizavimo varikliui, mobiliems įkėlimams, WebDAV įrankiams ir bendrinamų nuorodų gavėjams visiems reikia kelio į tą pačią paslaugą, ir kiekvienas gali atskleisti skirtingą įėjimą. Surašykite juos prieš ką nors uždarydami. Tas sąrašas yra tikroji perimetras.

Eikite per kontrolinį sąrašą iš eilės. Pirmas punktas apibrėžia, ką privatu reiškia šiam diegimui; vėlesni punktai tikrina, ar diegimas tikrai atitinka tą apibrėžimą.

Apibrėžkite privatų prieš keisdami perimetrą

Užrašykite reikalavimą vienu sakiniu: kiekvienas naudotojas turi prisijungti prie VPN, kol pasieks programą, arba programa gali likti vieša, o jos kilmė lieka privati. Tai skirtingi sprendimai, o viešas atvirkštinis proxy, perduodantis į privatų tunelį, atitinka tik antrąjį.

Privatus backend adresas nepadaro programos privačios. Jei viešas susiejimas, antras pagrindinio kompiuterio vardas ar IPv6 klausytojas vis dar pasiekia tą pačią Nextcloud instanciją, įėjimas egzistuoja nepriklausomai nuo to, kur yra backend. Išbandykite kiekvieną vardą iš išorės prieš skelbdami paslaugą privačia. Trūkstamas DNS įrašas nėra tas pats kaip uždarytas prievadas.

Sutarkite ir dėl numatomos auditorijos: darbuotojai, namų ūkis, partnerių organizacija ar paskyrų poaibis. Atsakymas nusprendžia, ar vieša bendrinimo nuoroda yra funkcija, ar prieštaravimas. Įrašykite tą auditoriją į prieigos planą. Tai kiekvienos išimties, kuri bus toliau, testas.

Surašykite kiekvieną įėjimą ir kiekvieną vardą

Išvardykite viešus adresų susiejimus, atvirkštinius proxy, alternatyvius pagrindinio kompiuterio vardus, IPv6 klausytojus ir bet kokį tunelio ar mesh adresą, kuris pasiekia paslaugą. Įtraukite vardus, kurie sprendžiasi į tuos adresus, nes pamirštas DNS įrašas yra įėjimas su draugiška etikete.

Patikrinkite proxy konfigūraciją dėl persiunčiamų antraščių ir alternatyvių serverio blokų. Proxy, pridėtas kitai programai, gali atskleisti tą patį upstream per kelią arba likusį virtualųjį serverį. Skaitykite tikrąją konfigūraciją, o ne numatytą diagramą. Abu dažniausiai išsiskiria po to, kai programa perkeliama.

Tada užblokuokite įėjimus, kurių nepasirinkote. Privatus backend su viešu frontu nėra sprendimas tik per VPN, o ugniasienės taisyklė, apimanti tik IPv4, palieka IPv6 klausytoją atvirą. Uždarykite abi šeimas ir abu vardus tame pačiame pakeitime.

Duokite kiekvienam klientui vieną paslaugos vardą

Nukreipkite privatų DNS į paslaugą, perduokite tą vardą per VPN ir išduokite jam sertifikatą. Vardas turi išsispręsti per privatų kelią ir būti patvirtintas be įspėjimo. Klientas, kuris pasiekia IP tiesiogiai, vis tiek turi turėti veikiantį vardą.

Klientai, kurie jungiasi per nesusijusį IP adresą, neturėtų turėti atsisakyti sertifikato klaidų, kad sprendimas veiktų. Stabilus vardas taip pat neleidžia sinchronizavimo klientams kurti dubliuotų serverio įrašų, kai adresas keičiasi. Tai skirtumas tarp privačios paslaugos ir privataus IP.

Palikite sertifikatų tikrinimą įjungtą. Privatus tinklas sumažina poveikį, bet nepadaro nepatvirtinto TLS ryšio priimtinu, o klientas, įpratęs ignoruoti įspėjimus, ignoruos juos ir kituose tinkluose.

Apribokite tinklo prieigą, o ne visą LAN

Leiskite užsiregistravusiems naudotojams pasiekti Nextcloud paslaugą ir jos reikalingas priklausomybes, o serverio administravimą laikykite atskirame kelyje. VPN, kuris įleidžia klientą į visą namų ar biuro tinklą duoda tam klientui daug daugiau, nei programa reikalauja.

Prisijungimas prie VPN nepakeičia Nextcloud paskyrų, leidimų ar papildomo autentifikavimo. Programa vis dar sprendžia, kuris naudotojas gali skaityti kurį failą, o tinklo sluoksnis neturėtų būti vienintelė kontrolė.

Užrašykite patvirtintą šaltinio diapazoną ir paslaugos prievadus. Tikslo savininkui reikia stebimo šaltinio, o NAT ar proxy gali jį perrašyti, kol užklausa pasieks programą.

Peržiūrėkite kiekvieną darbo eigą ne naršyklėje

Darbalaukio sinchronizavimas ir mobilūs įkėlimai atidaro savo ryšius savo laiku. Jiems reikia patvirtinto privataus kelio, kai jie jungiasi, ir jie gali elgtis kitaip, kai VPN nėra: bandyti dar kartą, pristabdyti ar rodyti klaidą. Išbandykite kiekvieną, ne tik naršyklę.

WebDAV įrankiai ir kalendoriaus ar kontaktų klientai yra atskiros integracijos su sava konfigūracija. Klientas, kuris talpina viešą URL podėlyje, ir toliau bando tą URL po perimetro pakeitimo, o triktis atrodo kaip programos problema.

Bendrinamos nuorodos nusipelno aiškaus sprendimo. Nuoroda nesuteikia gavėjui VPN prieigos, todėl tikrai tik per VPN sprendime išorinis gavėjas negali jos naudoti, nors nuoroda galioja. Jei bendrinimas į išorę būtinas, tai sąmoninga išimtis su savo prieigos keliu, o ne vėliau aptinkamas apsileidimas.

Federacija ir serverio į serverį integracijos reikalauja to paties požiūrio. Tai pasiekiamumo ryšiai tarp diegimų, o tik privatus diegimas turi pasakyti, ar jie palaikomi.

Priimkite ir leidžiamą, ir atmestą atvejį

Iš patvirtinto kliento patikrinkite žiniatinklio sąsają ir įprastą failo įkėlimą ar atsisiuntimą. Tada patikrinkite sinchronizavimo klientą ir vieną darbo eigą ne naršyklėje. Sėkmė tik naršyklėje nėra priėmimas.

Iš nepatvirtinto kelio patvirtinkite, kad programa nepasiekiama per kiekvieną sąraše esantį įėjimą. Išbandykite alternatyvų pagrindinio kompiuterio vardą ir IPv6 adresą, ne tik pagrindinį URL.

Galiausiai peržiūrėkite programos nustatymus, kuriuos lengva supainioti su tinklo politika. trusted_domains išvardija vardus, kuriuos instancija priima; tai nėra klientų IP leidimų sąrašas. Jei atvirkštinis proxy teikia adreso informaciją, trusted_proxies turi nurodyti tikrąjį proxy, o persiunčiamos antraštės turėtų būti priimamos tik iš jo.

Tęskite įprastą stiprinimo darbą kartu su tinklo pakeitimu: laikykite duomenis ir atsargines kopijas už nepageidaujamų žiniatinklio kelių, diegkite programos naujinius, apsaugokite administratoriaus prieigą ir palikite atkūrimą naudingą. VPN pašalina vieną įėjimo paviršių; jis nepadaro užsiregistravusio kliento patikimu.

Susiję straipsniai