Nextcloud berre via VPN: kartlegg kvar inngang først

Ein Nextcloud-plan berre via VPN feilar når han vernar nettlesaren og gløymer synkroniseringsklienten. Nettsida, synkroniseringsmotoren for skrivebordet, mobilopplastingar, WebDAV-verktøy og mottakarar av delte lenkjer treng alle ein veg til den same tenesta, og kvar av dei kan avdekkje ein annan inngang. Kartlegg dei før du lukkar noko. Den lista er den verkelege perimeters.

Gå gjennom sjekklista i rekkefølgje. Det første punktet definerer kva privat tyder for denne utrullinga; dei seinare punkta testar om utrullinga faktisk samsvarer med den definisjonen.

Definer privat før du endrar perimeters

Skriv ned kravet i éi setning: kvar brukar må bli med i VPN før hen når applikasjonen, eller applikasjonen kan halde fram som offentleg medan opphavet blir privat. Dette er ulike design, og ein offentleg omvend proxy som videresender inn i ein privat tunnel oppfyller berre det andre.

Ei privat backend-adresse gjer ikkje applikasjonen privat. Viss ein offentleg mapping, eit andre vertsnamn eller ein IPv6-lyttar framleis når same Nextcloud-førekomst, finst inngangen uansett kvar backend er. Test kvart namn utanfrå før du erklærer tenesta privat. Ein manglande DNS-post er ikkje det same som ein lukka port.

Bli også samde om den tiltenkte målgruppa: tilsette, ein husstand, ein partnarorganisasjon eller eit delsett av kontoar. Svaret avgjer om ei offentleg delelenkje er ein funksjon eller ei motsetning. Skriv den målgruppa inn i tilgangsplanen. Det er testen for kvar unntak som følgjer.

Kartlegg kvar inngang og kvart namn

List opp offentlege adressemappingar, omvende proxyar, alternative vertsnamn, IPv6-lyttarar og kvar tunnel- eller mesh-adresse som når tenesta. Ta med namna som løyser til desse adressene, fordi ein gløymd DNS-post er ein inngang med ei venleg etikett.

Kontroller proxy-konfigurasjonen for vidaresende headarar og alternative serverblokker. Ein proxy som vart lagt til for ein annan applikasjon, kan avdekkje same upstream via ein sti eller ein attverande virtuell vert. Les den faktiske konfigurasjonen i staden for det planlagde diagrammet. Dei to avvik oftast etter at ein applikasjon er flytta.

Blokker deretter inngangane du ikkje valde. Ein privat backend med ein offentleg front er ikkje eit design berre via VPN, og ein brannmurregel som berre dekkjer IPv4 lèt IPv6-lyttaren stå open. Lukk begge familiar og begge namn i same endring.

Gi kvar klient eitt tenestenamn

Pek privat DNS mot tenesta, rut namnet gjennom VPN, og utsted sertifikatet for det. Namnet må løysast gjennom den private vegen og validerast utan åtvaring. Ein klient som når IP-en direkte, treng framleis at namnet verkar.

Klientar som koplar til via ei urelatert IP-adresse, bør ikkje måtte avvise sertifikatfeil for at designet skal verke. Eit stabilt namn hindrar også synkroniseringsklientar i å lage dupliserte serveroppføringar når ei adresse blir endra. Det er skilnaden mellom ei privat teneste og ein privat IP.

La sertifikatvalidering vere slått på. Eit privat nettverk reduserer eksponeringa, men gjer ikkje ei uvalidert TLS-tilkopling akseptabel, og ein klient som er van med å ignorere åtvaringar, vil også ignorere dei på andre nettverk.

Avgrens nettverkstilgang, ikkje heile LAN-et

La registrerte brukarar nå Nextcloud-tenesta og dei naudsynte avhengnadene, og hald serveradministrasjon på ein eigen sti. Eit VPN som slepp ein klient inn i heile heime- eller kontornettverket gir den klienten langt meir enn applikasjonen krev.

VPN-tilgang erstattar ikkje Nextcloud-kontoar, løyve eller ekstra autentisering. Applikasjonen avgjer framleis kva brukar som kan lese kva fil, og nettverkslaget bør ikkje vere den einaste kontrollen.

Noter det godkjende kjeldeområdet og tenesteportane. Eigaren av målet treng den observerte kjelda, og NAT eller proxy kan skrive ho om før førespurnaden når applikasjonen.

Gå gjennom kvar arbeidsflyt utanfor nettlesaren

Skrivebordssynkronisering og mobilopplastingar opnar eigne tilkoplingar til eigne tider. Dei treng den godkjende private vegen når dei koplar til, og dei kan oppføre seg annleis når VPN-et manglar: prøve på nytt, pause eller vise ein feil. Test kvar av dei, ikkje berre nettlesaren.

WebDAV-verktøy og kalender- eller kontaktklientar er separate integrasjonar med eigen konfigurasjon. Ein klient som bufrer ein offentleg URL, held fram med å prøve den URL-en etter perimeterendringa, og feilen ser ut som eit applikasjonsproblem.

Delte lenkjer fortener ei uttrykkeleg avgjerd. Ei lenkje gir ikkje mottakaren VPN-tilgang, så i eit genuint berre-VPN-design kan ein ekstern mottakar ikkje bruke ho sjølv om lenkja er gyldig. Viss deling utover er påkravd, er det eit medvite unntak med sin eigen tilgangsveg, ikkje ei gløymsle som blir oppdaga seinare.

Føderasjon og server-til-server-integrasjonar treng same handsaming. Dei er tilgjengelege-tilhøve mellom installasjonar, og ei utrulling som berre er privat, må seie om dei er støtta.

Godta både det tillatne og det avviste tilfellet

Frå ein godkjend klient, kontroller webgrensesnittet og ei vanleg filopplasting eller -nedlasting. Kontroller deretter ein synkroniseringsklient og éin arbeidsflyt utanfor nettlesaren. Suksess berre i nettlesaren er ikkje godkjenning.

Frå ein ikkje-godkjend veg, stadfest at applikasjonen er utilgjengeleg gjennom kvar inngang på lista. Test det alternative vertsnamnet og IPv6-adressa, ikkje berre den primære URL-en.

Til slutt, gå gjennom applikasjonsinnstillingane som lett blir forveksla med nettverkspolicy. trusted_domains viser namn som førekomsten godtar; det er ikkje ei tillatingsliste for klient-IP-ar. Viss ein omvend proxy leverer adresseinformasjon, trusted_proxies må namngje den faktiske proxyen, og vidaresende headarar bør berre godtakast frå den.

Hald fram med det vanlege herdingsarbeidet saman med nettverksendringa: hald data og tryggingskopiar utanfor utilsikta webstiar, oppdater applikasjonen, vern administrator-tilgang og hald gjenoppretting brukbar. Eit VPN fjernar éin inngangsflate; det gjer ikkje ein registrert klient påliteleg.