Nextcloud csak VPN-en át: először minden belépési pontot térképezze fel
A weboldal védelme nem elég: a szinkronizációs klienseknek, a WebDAV-nak, a megosztott hivatkozásoknak és a proxy útvonalaknak ugyanarra a privát belépésre van szükségük. Térképezze fel őket, mielőtt bezárja.
A csak VPN-en át működő Nextcloud-terv akkor vall kudarcot, amikor a böngészőt védi, de megfeledkezik a szinkronizációs kliensről. A weboldalnak, az asztali szinkronizációs motornak, a mobil feltöltéseknek, a WebDAV-eszközöknek és a megosztott hivatkozások címzettjeinek mind ugyanahhoz a szolgáltatáshoz vezető útra van szükségük, és mindegyik más belépési pontot tárhat fel. Térképezze fel őket, mielőtt bármit bezár. Ez a lista a valódi peremterület.
Haladjon végig az ellenőrzőlistán sorrendben. Az első pont meghatározza, mit jelent a privát ebben a telepítésben; a későbbi pontok azt vizsgálják, hogy a telepítés valóban megfelel-e ennek a meghatározásnak.
Határozza meg a privátot, mielőtt megváltoztatja a peremterületet
Írja le a követelményt egy mondatban: minden felhasználónak csatlakoznia kell a VPN-hez, mielőtt eléri az alkalmazást, vagy az alkalmazás nyilvános maradhat, miközben a forrása privát marad. Ezek különböző tervek, és a nyilvános fordított proxy, amely privát alagútba továbbít, csak a másodikat teljesíti.
A privát backend-cím nem teszi priváttá az alkalmazást. Ha egy nyilvános leképezés, egy második hosztnév vagy egy IPv6-figyelő továbbra is eléri ugyanazt a Nextcloud-példányt, a belépési pont létezik, függetlenül attól, hol van a backend. Teszteljen minden nevet kívülről, mielőtt privátnak nyilvánítja a szolgáltatást. A hiányzó DNS-rekord nem ugyanaz, mint a zárt port.
A szándékolt közönségben is egyezzenek meg: munkavállalók, egy háztartás, egy partner szervezet vagy a fiókok egy részhalmaza. A válasz dönti el, hogy egy nyilvános megosztási hivatkozás funkció-e vagy ellentmondás. Írja be ezt a közönséget a hozzáférési tervbe. Ez a próba minden következő kivételre.
Térképezze fel az összes belépési pontot és minden nevet
Sorolja fel a nyilvános címleképezéseket, a fordított proxykat, az alternatív hosztneveket, az IPv6-figyelőket és minden alagút- vagy mesh-címet, amely eléri a szolgáltatást. Vegye fel azokat a neveket is, amelyek ezekre a címekre oldódnak fel, mert az elfelejtett DNS-rekord egy barátságos címkéjű belépési pont.
Ellenőrizze a proxy konfigurációját a továbbított fejlécekre és az alternatív szerverblokkokra. Egy másik alkalmazáshoz hozzáadott proxy ugyanazt az upstreamet teheti elérhetővé egy útvonalon vagy egy maradék virtuális hoszton keresztül. A tényleges konfigurációt olvassa, ne a tervezett diagramot. A kettő leggyakrabban azután tér el, hogy egy alkalmazást áthelyeztek.
Ezután blokkolja azokat a belépési pontokat, amelyeket nem választott. A nyilvános fronttal rendelkező privát backend nem csak VPN-es terv, és a csak IPv4-et lefedő tűzfalszabály nyitva hagyja az IPv6-figyelőt. Mindkét családot és mindkét nevet ugyanabban a változtatásban zárja le.
Adjon minden kliensnek egyetlen szolgáltatásnevet
Irányítsa a privát DNS-t a szolgáltatásra, vezesse át ezt a nevet a VPN-en, és állítsa ki hozzá a tanúsítványt. A névnek a privát útvonalon keresztül kell feloldódnia, és figyelmeztetés nélkül érvényesülnie. Egy kliens, amely közvetlenül az IP-t éri el, még mindig igényli a működő nevet.
A nem összefüggő IP-címen kapcsolódó klienseknek nem kellene a tanúsítványhibákat elutasítaniuk ahhoz, hogy a terv működjön. A stabil név azt is megakadályozza, hogy a szinkronizációs kliensek duplikált szerverbejegyzéseket hozzanak létre, amikor egy cím megváltozik. Ez a különbség a privát szolgáltatás és a privát IP között.
Tartsa bekapcsolva a tanúsítványok ellenőrzését. A privát hálózat csökkenti a kitettséget, de nem teszi elfogadhatóvá az ellenőrizetlen TLS-kapcsolatot, és az a kliens, amely megtanulta figyelmen kívül hagyni a figyelmeztetéseket, más hálózatokon is figyelmen kívül fogja hagyni őket.
Korlátozza a hálózati hozzáférést, ne az egész LAN-t
Engedje, hogy a regisztrált felhasználók elérjék a Nextcloud-szolgáltatást és szükséges függőségeit, a szerveradminisztrációt pedig tartsa külön útvonalon. Egy VPN, amely egy klienst az egész otthoni vagy irodai hálózatba beenged sokkal többet ad annak a kliensnek, mint amit az alkalmazás megkövetel.
A VPN-belépés nem helyettesíti a Nextcloud-fiókokat, a jogosultságokat vagy a további hitelesítést. Az alkalmazás továbbra is eldönti, melyik felhasználó melyik fájlt olvashatja, és a hálózati réteg nem lehet az egyetlen kontroll.
Jegyezze fel a jóváhagyott forrástartományt és a szolgáltatás portjait. A cél tulajdonosának a megfigyelt forrásra van szüksége, és egy NAT vagy proxy átírhatja, mielőtt a kérés eléri az alkalmazást.
Tekintse át a böngészőn kívüli munkafolyamatokat
Az asztali szinkronizáció és a mobil feltöltések saját időpontjukban nyitják saját kapcsolataikat. Szükségük van a jóváhagyott privát útvonalra, amikor kapcsolódnak, és másképp viselkedhetnek, ha nincs VPN: újrapróbálkozás, szüneteltetés vagy hiba megjelenítése. Tesztelje mindegyiket, ne csak a böngészőt.
A WebDAV-eszközök és a naptár- vagy névjegykliens külön integrációk saját konfigurációval. Egy nyilvános URL-t gyorsítótárazó kliens a peremterület változása után is próbálja azt az URL-t, és a hiba alkalmazáshibának tűnik.
A megosztott hivatkozások kifejezett döntést érdemelnek. Egy hivatkozás nem ad VPN-hozzáférést a címzettjének, ezért egy valóban csak VPN-es tervben külső címzett nem használhatja, még ha a hivatkozás érvényes is. Ha a kifelé megosztás szükséges, az egy szándékos kivétel saját hozzáférési útvonallal, nem egy később felfedezendő mulasztás.
A föderáció és a szerver-szerver integrációk ugyanazt a kezelést igénylik. Ezek telepítések közötti elérhetőségi kapcsolatok, és a csak privát telepítésnek meg kell mondania, hogy támogatottak-e.
Fogadja el az engedélyezett és a megtagadott esetet is
Egy jóváhagyott kliensről ellenőrizze a webes felületet és egy szokásos fájlfeltöltést vagy -letöltést. Ezután ellenőrizzen egy szinkronizációs klienst és egy böngészőn kívüli munkafolyamatot. A csak böngészős siker nem elfogadás.
Egy nem jóváhagyott útvonalról erősítse meg, hogy az alkalmazás a leltár egyetlen belépési pontján keresztül sem érhető el. Tesztelje az alternatív hosztnevet és az IPv6-címet, ne csak az elsődleges URL-t.
Végül tekintse át azokat az alkalmazásbeállításokat, amelyeket könnyű összetéveszteni a hálózati szabályzattal. trusted_domains azokat a neveket sorolja fel, amelyeket a példány elfogad; ez nem a kliens IP-k engedélyezési listája. Ha egy fordított proxy címadatokat szolgáltat, trusted_proxies a tényleges proxyt kell megneveznie, és a továbbított fejléceket csak tőle szabad elfogadni.
Folytassa a szokásos megerősítési munkát a hálózati változtatás mellett: tartsa az adatokat és a biztonsági mentéseket a nem szándékolt webes útvonalakon kívül, javítsa az alkalmazást, védje az adminisztrátori hozzáférést, és tartsa használhatónak a helyreállítást. A VPN eltávolít egy belépési felületet; nem teszi megbízhatóvá a regisztrált klienst.