Nextcloud bara via VPN: inventera varje ingång först

En Nextcloud-plan bara via VPN misslyckas när den skyddar webbläsaren och glömmer synkroniseringsklienten. Webbsidan, synkroniseringsmotorn för skrivbordet, mobiluppladdningar, WebDAV-verktyg och mottagare av delade länkar behöver alla en väg till samma tjänst, och var och en kan exponera en annan ingång. Inventera dem innan du stänger något. Den listan är den verkliga perimetern.

Gå igenom checklistan i ordning. Den första punkten definierar vad privat betyder för den här driftsättningen; de senare punkterna testar om driftsättningen verkligen matchar den definitionen.

Definiera privat innan du ändrar perimetern

Skriv ner kravet i en mening: varje användare måste ansluta till VPN innan hen når applikationen, eller så kan applikationen förbli offentlig medan dess ursprung förblir privat. Det är olika konstruktioner, och en offentlig omvänd proxy som vidarebefordrar in i en privat tunnel uppfyller bara den andra.

En privat backend-adress gör inte applikationen privat. Om en offentlig mappning, ett andra värdnamn eller en IPv6-lyssnare fortfarande når samma Nextcloud-instans finns ingången oavsett var backend ligger. Testa varje namn utifrån innan du förklarar tjänsten privat. En saknad DNS-post är inte samma sak som en stängd port.

Kom också överens om den avsedda målgruppen: anställda, ett hushåll, en partnerorganisation eller en delmängd konton. Svaret avgör om en offentlig dellänk är en funktion eller en motsägelse. Skriv in den målgruppen i åtkomstplanen. Det är testet för varje undantag som följer.

Inventera varje ingång och varje namn

Lista offentliga adressmappningar, omvända proxyservrar, alternativa värdnamn, IPv6-lyssnare och varje tunnel- eller mesh-adress som når tjänsten. Ta med namnen som löser till dessa adresser, eftersom en glömd DNS-post är en ingång med en vänlig etikett.

Kontrollera proxykonfigurationen för vidarebefordrade huvuden och alternativa serverblock. En proxy som lades till för en annan applikation kan exponera samma upstream via en sökväg eller en kvarvarande virtuell värd. Läs den faktiska konfigurationen i stället för det planerade diagrammet. De två skiljer sig oftast efter att en applikation flyttats.

Blockera sedan de ingångar du inte valde. En privat backend med en offentlig front är inte en konstruktion bara via VPN, och en brandväggsregel som bara täcker IPv4 lämnar IPv6-lyssnaren öppen. Stäng båda familjerna och båda namnen i samma ändring.

Ge varje klient ett enda tjänstenamn

Peka privat DNS mot tjänsten, routa namnet genom VPN och utfärda certifikatet för det. Namnet måste lösas via den privata vägen och valideras utan varning. En klient som når IP-adressen direkt behöver ändå att namnet fungerar.

Klienter som ansluter via en orelaterad IP-adress borde inte behöva avvisa certifikatfel för att konstruktionen ska fungera. Ett stabilt namn hindrar också synkroniseringsklienter från att skapa dubbla serverposter när en adress ändras. Det är skillnaden mellan en privat tjänst och en privat IP.

Låt certifikatvalideringen vara aktiverad. Ett privat nätverk minskar exponeringen men gör inte en ovaliderad TLS-anslutning acceptabel, och en klient som är van att ignorera varningar kommer att ignorera dem även på andra nätverk.

Begränsa nätverksåtkomsten, inte hela LAN

Tillåt registrerade användare att nå Nextcloud-tjänsten och dess nödvändiga beroenden, och håll serveradministration på en separat väg. En VPN som släpper in en klient i hela hem- eller kontorsnätverket ger den klienten långt mer än applikationen kräver.

VPN-åtkomst ersätter inte Nextcloud-konton, behörigheter eller extra autentisering. Applikationen avgör fortfarande vilken användare som får läsa vilken fil, och nätverkslagret bör inte vara den enda kontrollen.

Anteckna det godkända källområdet och tjänstens portar. Målets ägare behöver den observerade källan, och NAT eller proxy kan skriva om den innan begäran når applikationen.

Granska varje arbetsflöde utanför webbläsaren

Skrivbordssynkronisering och mobiluppladdningar öppnar egna anslutningar vid egna tidpunkter. De behöver den godkända privata vägen när de ansluter, och de kan bete sig annorlunda när VPN saknas: försöka igen, pausa eller visa ett fel. Testa varje, inte bara webbläsaren.

WebDAV-verktyg och kalender- eller kontaktklienter är separata integrationer med egen konfiguration. En klient som cachar en offentlig URL fortsätter att försöka med den URL:en efter perimeterändringen, och felet ser ut som ett applikationsproblem.

Delade länkar förtjänar ett uttryckligt beslut. En länk ger inte mottagaren VPN-åtkomst, så i en genuint bara-VPN-konstruktion kan en extern mottagare inte använda den även om länken är giltig. Om delning utåt krävs är det ett medvetet undantag med egen åtkomstväg, inte en försummelse som upptäcks senare.

Federation och server-till-server-integrationer behöver samma behandling. De är nåbarhetsrelationer mellan installationer, och en bara-privat driftsättning måste säga om de stöds.

Acceptera både det tillåtna och det nekade fallet

Från en godkänd klient, kontrollera webbgränssnittet och en vanlig filuppladdning eller -nedladdning. Kontrollera sedan en synkroniseringsklient och ett arbetsflöde utanför webbläsaren. Framgång bara i webbläsaren är inte acceptans.

Från en icke-godkänd väg, bekräfta att applikationen inte går att nå via varje ingång i inventariet. Testa det alternativa värdnamnet och IPv6-adressen, inte bara den primära URL:en.

Granska slutligen applikationsinställningarna som lätt förväxlas med nätverkspolicy. trusted_domains listar namn som instansen accepterar; det är inte en tillåtelselista för klient-IP. Om en omvänd proxy levererar adressinformation, trusted_proxies måste namnge den faktiska proxyn, och vidarebefordrade huvuden bör bara accepteras från den.

Fortsätt det vanliga härdningsarbetet tillsammans med nätverksändringen: håll data och säkerhetskopior utanför oavsiktliga webbvägar, uppdatera applikationen, skydda administratörsåtkomst och håll återställning användbar. En VPN tar bort en ingångsyta; den gör inte en registrerad klient pålitlig.