Nextcloud bare via VPN: kartlegg hver inngang først

En Nextcloud-plan kun via VPN feiler når den beskytter nettleseren og glemmer synkroniseringsklienten. Nettsiden, synkroniseringsmotoren for skrivebordet, mobilopplastinger, WebDAV-verktøy og mottakere av delte lenker trenger alle en vei til den samme tjenesten, og hver av dem kan avdekke en annen inngang. Kartlegg dem før du lukker noe. Den listen er den virkelige perimeteren.

Gå gjennom sjekklisten i rekkefølge. Det første punktet definerer hva privat betyr for denne utrullingen; de senere punktene tester om utrullingen faktisk samsvarer med den definisjonen.

Definer privat før du endrer perimeteren

Skriv ned kravet i én setning: hver bruker må bli med i VPN før hen når applikasjonen, eller applikasjonen kan forbli offentlig mens opprinnelsen forblir privat. Dette er forskjellige design, og en offentlig omvendt proxy som videresender inn i en privat tunnel oppfyller bare det andre.

En privat backend-adresse gjør ikke applikasjonen privat. Hvis en offentlig mapping, et andre vertsnavn eller en IPv6-lytter fortsatt når samme Nextcloud-forekomst, finnes inngangen uansett hvor backend befinner seg. Test hvert navn utenfra før du erklærer tjenesten privat. En manglende DNS-post er ikke det samme som en lukket port.

Bli også enige om den tiltenkte målgruppen: ansatte, en husstand, en partnerorganisasjon eller et delsett av kontoer. Svaret avgjør om en offentlig delelenke er en funksjon eller en motsetning. Skriv den målgruppen inn i tilgangsplanen. Det er testen for hvert unntak som følger.

Kartlegg hver inngang og hvert navn

List offentlige adressemappinger, omvendte proxyer, alternative vertsnavn, IPv6-lyttere og enhver tunnel- eller mesh-adresse som når tjenesten. Ta med navnene som løser til disse adressene, fordi en glemt DNS-post er en inngang med en vennlig etikett.

Kontroller proxy-konfigurasjonen for videresendte headere og alternative serverblokker. En proxy som ble lagt til for en annen applikasjon, kan avdekke samme upstream via en sti eller en gjenværende virtuell vert. Les den faktiske konfigurasjonen i stedet for det planlagte diagrammet. De to avviker oftest etter at en applikasjon er flyttet.

Blokker deretter inngangene du ikke valgte. En privat backend med en offentlig front er ikke et design kun via VPN, og en brannmurregel som bare dekker IPv4 lar IPv6-lytteren stå åpen. Lukk begge familier og begge navn i samme endring.

Gi hver klient ett tjenestenavn

Pek privat DNS mot tjenesten, rut navnet gjennom VPN, og utsted sertifikatet for det. Navnet må løses gjennom den private veien og valideres uten advarsel. En klient som når IP-en direkte, trenger fortsatt at navnet virker.

Klienter som kobler til via en urelatert IP-adresse, bør ikke måtte avvise sertifikatfeil for at designet skal virke. Et stabilt navn hindrer også synkroniseringsklienter i å lage dupliserte serveroppføringer når en adresse endres. Det er forskjellen mellom en privat tjeneste og en privat IP.

La sertifikatvalidering være slått på. Et privat nettverk reduserer eksponeringen, men gjør ikke en uvalidert TLS-tilkobling akseptabel, og en klient som er vant til å ignorere advarsler, vil også ignorere dem på andre nettverk.

Begrens nettverkstilgangen, ikke hele LAN-et

La registrerte brukere nå Nextcloud-tjenesten og dens nødvendige avhengigheter, og hold serveradministrasjon på en egen sti. Et VPN som slipper en klient inn i hele hjemme- eller kontornettverket gir den klienten langt mer enn applikasjonen krever.

VPN-tilgang erstatter ikke Nextcloud-kontoer, tillatelser eller ekstra autentisering. Applikasjonen avgjør fortsatt hvilken bruker som kan lese hvilken fil, og nettverkslaget bør ikke være den eneste kontrollen.

Noter det godkjente kildeområdet og tjenesteportene. Eieren av målet trenger den observerte kilden, og NAT eller proxy kan skrive den om før forespørselen når applikasjonen.

Gå gjennom hver arbeidsflyt utenfor nettleseren

Skrivebordssynkronisering og mobilopplastinger åpner egne tilkoblinger til egne tider. De trenger den godkjente private veien når de kobler til, og de kan oppføre seg annerledes når VPN-et mangler: prøve på nytt, pause eller vise en feil. Test hver av dem, ikke bare nettleseren.

WebDAV-verktøy og kalender- eller kontaktklienter er separate integrasjoner med egen konfigurasjon. En klient som bufrer en offentlig URL, fortsetter å prøve den URL-en etter perimeterendringen, og feilen ser ut som et applikasjonsproblem.

Delte lenker fortjener en uttrykkelig beslutning. En lenke gir ikke mottakeren VPN-tilgang, så i et genuint kun-VPN-design kan en ekstern mottaker ikke bruke den selv om lenken er gyldig. Hvis deling utad er påkrevd, er det et bevisst unntak med sin egen tilgangsvei, ikke en forglemmelse som oppdages senere.

Federasjon og server-til-server-integrasjoner trenger samme behandling. De er tilgjengelighetsrelasjoner mellom installasjoner, og en utrulling som bare er privat, må si om de støttes.

Godta både det tillatte og det avviste tilfellet

Fra en godkjent klient, kontroller webgrensesnittet og en vanlig filopplasting eller -nedlasting. Kontroller deretter en synkroniseringsklient og én arbeidsflyt utenfor nettleseren. Suksess bare i nettleseren er ikke godkjenning.

Fra en ikke-godkjent vei, bekreft at applikasjonen er utilgjengelig gjennom hver inngang på listen. Test det alternative vertsnavnet og IPv6-adressen, ikke bare den primære URL-en.

Til slutt, gå gjennom applikasjonsinnstillingene som lett forveksles med nettverkspolicy. trusted_domains viser navn som forekomsten godtar; det er ikke en tillatelsesliste for klient-IP-er. Hvis en omvendt proxy leverer adresseinformasjon, trusted_proxies må navngi den faktiske proxyen, og videresendte headere bør bare godtas fra den.

Fortsett det vanlige herdingsarbeidet sammen med nettverksendringen: hold data og sikkerhetskopier utenfor utilsiktede webstier, oppdater applikasjonen, beskytt administrator tilgang og hold gjenoppretting brukbar. Et VPN fjerner én inngangsflate; det gjør ikke en registrert klient pålitelig.