Nextcloud jen přes VPN: nejprve zmapujte všechny vstupy

Plán pro Nextcloud jen přes VPN selže, když chrání prohlížeč a zapomene na synchronizačního klienta. Webová stránka, synchronizační engine pro počítač, mobilní nahrávání, nástroje WebDAV i příjemci sdílených odkazů všichni potřebují cestu ke stejné službě a každý z nich může odhalit jiný vstup. Zmapujte je, než cokoli zavřete. Ten seznam je skutečný obvod.

Projděte kontrolní seznam popořadě. První bod určuje, co pro toto nasazení znamená soukromé; další body ověřují, zda nasazení této definici skutečně odpovídá.

Definujte soukromé dříve, než změníte obvod

Zapište požadavek jednou větou: každý uživatel se musí připojit k VPN, než se dostane k aplikaci, nebo aplikace může zůstat veřejná, zatímco její původ zůstává soukromý. To jsou různé návrhy a veřejná reverzní proxy, která předává provoz do soukromého tunelu, splňuje jen druhý z nich.

Soukromá adresa backendu nedělá aplikaci soukromou. Pokud veřejné mapování, druhé jméno hostitele nebo IPv6 posluchač stále dosáhnou stejné instance Nextcloudu, vstup existuje bez ohledu na to, kde backend sídlí. Otestujte každé jméno zvenčí, než službu prohlásíte za soukromou. Chybějící DNS záznam není totéž co zavřený port.

Dohodněte se také na zamýšleném publiku: zaměstnanci, domácnost, partnerská organizace nebo podmnožina účtů. Odpověď rozhoduje o tom, zda je veřejný odkaz ke sdílení funkce, nebo protiklad. Zapište toto publikum do plánu přístupu. Je to zkouška pro každou výjimku, která přijde.

Zmapujte každý vstup a každé jméno

Vyjmenujte veřejná mapování adres, reverzní proxy, alternativní jména hostitelů, IPv6 posluchače a jakoukoli adresu tunelu či sítě, která dosáhne na službu. Zahrňte jména, která se na tyto adresy převádějí, protože zapomenutý DNS záznam je vstup s přátelskou etiketou.

Zkontrolujte konfiguraci proxy na předávané hlavičky a alternativní bloky serveru. Proxy přidaná pro jinou aplikaci může vystavit stejný upstream přes cestu nebo přes zbylý virtuální hostitel. Čtěte skutečnou konfiguraci, ne zamýšlený diagram. Ty dvě se nejčastěji rozcházejí poté, co se aplikace přesune.

Poté zablokujte vstupy, které jste nezvolili. Soukromý backend s veřejným frontendem není návrh jen přes VPN a pravidlo firewallu, které pokrývá jen IPv4, nechává IPv6 posluchač otevřený. Zavřete obě rodiny i obě jména v jedné změně.

Dejte každému klientovi jedno jméno služby

Nasměrujte soukromý DNS na službu, proveďte toto jméno přes VPN a vystavte pro něj certifikát. Jméno se musí přeložit přes soukromou cestu a ověřit bez varování. Klient, který se dostane přímo na IP adresu, stále potřebuje funkční jméno.

Klienti, kteří se připojují přes nesouvisející IP adresu, by neměli muset odbýt chyby certifikátu, aby návrh fungoval. Stabilní jméno také brání synchronizačním klientům vytvářet duplicitní položky serveru, když se adresa změní. To je rozdíl mezi soukromou službou a soukromou IP adresou.

Ponechte ověřování certifikátů zapnuté. Soukromá síť snižuje expozici, ale nedělá neověřené TLS spojení přijatelným, a klient zvyklý ignorovat varování je bude ignorovat i v jiných sítích.

Omezte síťový přístup, ne celou LAN

Umožněte zapsaným uživatelům dosáhnout na službu Nextcloud a její nezbytné závislosti a správu serveru držte na samostatné cestě. VPN, která vpustí klienta do celé domácí nebo kancelářské sítě dává tomuto klientovi mnohem víc, než aplikace vyžaduje.

Přístup do VPN nenahrazuje účty Nextcloudu, oprávnění ani dodatečné ověřování. Aplikace stále rozhoduje, který uživatel smí číst který soubor, a síťová vrstva by neměla být jedinou kontrolou.

Zaznamenejte schválený rozsah zdroje a porty služby. Vlastník cíle potřebuje pozorovaný zdroj, a NAT nebo proxy ji může přepsat, než požadavek dorazí do aplikace.

Projděte každý pracovní postup mimo prohlížeč

Synchronizace na počítači a mobilní nahrávání otevírají vlastní spojení ve vlastních časech. Při připojení potřebují schválenou soukromou cestu a mohou se chovat jinak, když VPN chybí: opakovat, pozastavit nebo zobrazit chybu. Otestujte každý z nich, ne jen prohlížeč.

Nástroje WebDAV a klienti kalendáře či kontaktů jsou samostatné integrace s vlastní konfigurací. Klient, který si uloží veřejnou URL do mezipaměti, se o ni po změně obvodu stále pokouší a selhání vypadá jako problém aplikace.

Sdílené odkazy si zaslouží výslovné rozhodnutí. Odkaz neuděluje příjemci přístup do VPN, takže v opravdu čistě VPN návrhu jej vnější příjemce nemůže použít, i když je odkaz platný. Pokud je sdílení ven nutné, je to záměrná výjimka s vlastní cestou přístupu, ne opomenutí, které objevíte později.

Federace a integrace server na server potřebují stejný přístup. Jsou to vztahy dosažitelnosti mezi instalacemi a čistě soukromé nasazení musí říct, zda jsou podporovány.

Přijměte povolený i zamítnutý případ

Z schváleného klienta zkontrolujte webové rozhraní a běžné nahrání nebo stažení souboru. Poté zkontrolujte synchronizačního klienta a jeden pracovní postup mimo prohlížeč. Úspěch jen v prohlížeči není přijetí.

Z neschválené cesty potvrďte, že aplikace není dostupná přes žádný vstup v soupisu. Otestujte alternativní jméno hostitele a IPv6 adresu, ne jen primární URL.

Nakonec projděte nastavení aplikace, které lze snadno zaměnit se síťovou politikou. trusted_domains uvádí jména, která instance přijímá; není to seznam povolených klientských IP adres. Pokud reverzní proxy poskytuje informace o adrese, trusted_proxies musí pojmenovat skutečnou proxy a předávané hlavičky by měly být přijímány jen z ní.

Pokračujte v běžném zpevňování souběžně se síťovou změnou: držte data a zálohy mimo nezamýšlené webové cesty, aktualizujte aplikaci, chraňte přístup správce a udržujte obnovu použitelnou. VPN odstraňuje jednu vstupní plochu; nedělá zapsaného klienta důvěryhodným.