Nextcloud kun via VPN: kortlæg først alle indgange

En Nextcloud-plan, der kun kører via VPN, fejler, når den beskytter browseren og glemmer synkroniseringsklienten. Websiden, synkroniseringsmotoren til computeren, mobiluploads, WebDAV-værktøjer og modtagere af delte links har alle brug for en vej til den samme tjeneste, og hver af dem kan afsløre en forskellig indgang. Kortlæg dem, før du lukker noget. Den liste er den reelle perimeter.

Gå kontrollisten igennem i rækkefølge. Det første punkt definerer, hvad privat betyder for denne udrulning; de senere punkter tester, om udrulningen faktisk matcher den definition.

Definér privat, før du ændrer perimeteren

Skriv kravet ned i én sætning: hver bruger skal tilslutte sig VPN’et, før han når applikationen, eller applikationen kan forblive offentlig, mens dens oprindelse forbliver privat. Det er forskellige designs, og en offentlig reverse proxy, der videresender ind i en privat tunnel, opfylder kun det andet.

En privat backend-adresse gør ikke applikationen privat. Hvis en offentlig mapping, et andet værtsnavn eller en IPv6-lytter stadig når den samme Nextcloud-instans, findes indgangen uanset hvor backenden ligger. Test hvert navn udefra, før du erklærer tjenesten privat. En manglende DNS-post er ikke det samme som en lukket port.

Bliv også enige om den tilsigtede målgruppe: medarbejdere, en husstand, en partnerorganisation eller en delmængde af konti. Svaret afgør, om et offentligt delelink er en funktion eller en modsigelse. Skriv den målgruppe ind i adgangsplanen. Det er testen for hver undtagelse, der følger.

Kortlæg hver indgang og hvert navn

List offentlige adressemappinger, reverse proxies, alternative værtsnavne, IPv6-lyttere og enhver tunnel- eller mesh-adresse, der når tjenesten. Medtag de navne, der peger på disse adresser, fordi en glemt DNS-post er en indgang med et venligt navn.

Kontrollér proxy-konfigurationen for videresendte headere og alternative serverblokke. En proxy, der blev tilføjet til en anden applikation, kan afsløre samme upstream via en sti eller en efterladt virtuel vært. Læs den faktiske konfiguration i stedet for det planlagte diagram. De to afviger oftest, efter at en applikation er flyttet.

Blokér derefter de indgange, du ikke valgte. En privat backend med en offentlig frontend er ikke et design kun via VPN, og en firewallregel, der kun dækker IPv4, efterlader IPv6-lytteren åben. Luk begge familier og begge navne i samme ændring.

Giv hver klient ét tjenestenavn

Peg privat DNS på tjenesten, route navnet gennem VPN’et, og udsted certifikatet til det. Navnet skal slås op via den private vej og validere uden advarsel. En klient, der når IP’en direkte, har stadig brug for, at navnet virker.

Klienter, der forbinder via en urelateret IP-adresse, bør ikke skulle afvise certifikatfejl for at få designet til at virke. Et stabilt navn forhindrer også synkroniseringsklienter i at oprette dublerede serverposter, når en adresse ændres. Det er forskellen mellem en privat tjeneste og en privat IP.

Lad certifikatvalidering være slået til. Et privat netværk reducerer eksponeringen, men gør ikke en uvalideret TLS-forbindelse acceptabel, og en klient, der er vant til at ignorere advarsler, vil også ignorere dem på andre netværk.

Begræns netværksadgang, ikke hele LAN’et

Tillad tilmeldte brugere at nå Nextcloud-tjenesten og dens nødvendige afhængigheder, og hold serveradministration på en separat vej. Et VPN, der lukker en klient ind i hele hjemme- eller kontornetværket giver den klient langt mere, end applikationen kræver.

VPN-adgang erstatter ikke Nextcloud-konti, tilladelser eller ekstra godkendelse. Applikationen afgør stadig, hvilken bruger der må læse hvilken fil, og netværkslaget bør ikke være den eneste kontrol.

Notér det godkendte kildeområde og tjenestens porte. Den ansvarlige for målet har brug for den observerede kilde, og NAT eller proxy kan omskrive den, før anmodningen når applikationen.

Gennemgå hvert arbejdsflow uden for browseren

Skrivebordssynkronisering og mobiluploads åbner deres egne forbindelser på deres egne tidspunkter. De har brug for den godkendte private vej, når de forbinder, og de kan opføre sig anderledes, når VPN’et mangler: prøve igen, gå i pause eller vise en fejl. Test hver af dem, ikke kun browseren.

WebDAV-værktøjer og kalender- eller kontaktklienter er separate integrationer med deres egen konfiguration. En klient, der cacher en offentlig URL, bliver ved med at prøve den URL efter perimeterændringen, og fejlen ligner et applikationsproblem.

Delte links fortjener en udtrykkelig beslutning. Et link giver ikke modtageren VPN-adgang, så under et ægte design kun via VPN kan en ekstern modtager ikke bruge det, selv om linket er gyldigt. Hvis deling udad er påkrævet, er det en bevidst undtagelse med sin egen adgangsvej, ikke en forglemmelse, der opdages senere.

Federation og server-til-server-integrationer har brug for samme behandling. De er tilgængelighedsrelationer mellem installationer, og en udrulning, der kun er privat, skal sige, om de understøttes.

Accepter både det tilladte og det nægtede tilfælde

Fra en godkendt klient, kontrollér webgrænsefladen og en almindelig filupload eller -download. Kontrollér derefter en synkroniseringsklient og et arbejdsflow uden for browseren. Succes i browseren alene er ikke godkendelse.

Fra en ikke-godkendt vej, bekræft at applikationen er utilgængelig gennem hver indgang på listen. Test det alternative værtsnavn og IPv6-adressen, ikke kun den primære URL.

Gennemgå til sidst de applikationsindstillinger, der let forveksles med netværkspolitik. trusted_domains viser navne, som instansen accepterer; det er ikke en tilladelsesliste til klient-IP’er. Hvis en reverse proxy leverer adresseoplysninger, trusted_proxies skal navngive den faktiske proxy, og videresendte headere bør kun accepteres fra den.

Fortsæt det sædvanlige hærdningsarbejde sideløbende med netværksændringen: hold data og backups ude af utilsigtede webstier, patch applikationen, beskyt administratoradgang og hold gendannelse brugbar. Et VPN fjerner en indgangsflade; det gør ikke en tilmeldt klient troværdig.