Nextcloud nur per VPN: unue listigu ĉiun enirejon

Plano pri Nextcloud nur per VPN malsukcesas, kiam ĝi protektas la retumilon kaj forgesas la sinkronigan klienton. La retejo, la labortabla sinkroniga motoro, movilaj alŝutoj, WebDAV-iloj kaj ricevantoj de dividitaj ligiloj ĉiuj bezonas vojon al la sama servo, kaj ĉiu el ili povas malkaŝi alian enirejon. Listigu ilin antaŭ ol fermi ion ajn. Tiu listo estas la reala perimetro.

Trairu la kontrol-liston laŭorde. La unua punkto difinas, kion privata signifas por tiu ĉi disfaldiĝo; la postaj punktoj testas, ĉu la disfaldiĝo vere kongruas kun tiu difino.

Difinu privatan antaŭ ol ŝanĝi la perimetron

Skribu la postulon en unu frazo: ĉiu uzanto devas aliĝi al la VPN antaŭ ol atingi la aplikaĵon, aŭ la aplikaĵo povas resti publika dum ĝia origino restas privata. Tiuj estas malsamaj projektoj, kaj publika inversa prokseo, kiu plusendas en privatan tunelon, plenumas nur la duan.

Privata malantaŭa adreso ne igas la aplikaĵon privata. Se publika mapado, dua gastigantnomo aŭ IPv6-auskultanto ankoraŭ atingas la saman Nextcloud-ekzempleron, la enirejo ekzistas sendepende de kie troviĝas la malantaŭaĵo. Testu ĉiun nomon de ekstere antaŭ ol deklari la servon privata. Mankanta DNS-rikordo ne samas kiel fermita pordo.

Interkonsentu ankaŭ pri la celita publiko: dungitoj, domanaro, partnera organizo aŭ subaro de kontoj. La respondo decidas, ĉu publika kunhaviga ligilo estas funkcio aŭ kontraŭdiro. Skribu tiun publikon en la alirplanon. Ĝi estas la testo por ĉiu escepto, kiu sekvas.

Listigu ĉiun enirejon kaj ĉiun nomon

Listigu publikajn adresmapadojn, inversajn prokseojn, alternativajn gastigantnomojn, IPv6-auskultantojn kaj ĉiun tunelan aŭ maŝan adreson, kiu atingas la servon. Inkluzivu la nomojn, kiuj solviĝas al tiuj adresoj, ĉar forgesita DNS-rikordo estas enirejo kun afabla etikedo.

Kontrolu la proksean agordon por plusenditaj kaplinioj kaj alternativaj servilblokoj. Prokseo aldonita por alia aplikaĵo povas malkaŝi la saman upstream per vojo aŭ per resta virtuala gastiganto. Legu la faktan agordon anstataŭ la intencitan diagramon. La du plej ofte diverĝas post kiam aplikaĵo estas movita.

Poste bloku la enirejojn, kiujn vi ne elektis. Privata malantaŭaĵo kun publika fasado ne estas projekto nur per VPN, kaj fajroŝirma regulo, kiu kovras nur IPv4, lasas la IPv6-auskultanton malfermita. Fermu ambaŭ familiojn kaj ambaŭ nomojn en la sama ŝanĝo.

Donu al ĉiu kliento unu servan nomon

Direktu privatan DNS al la servo, enkursigu tiun nomon tra la VPN kaj eldonu la atestilon por ĝi. La nomo devas solviĝi tra la privata vojo kaj validiĝi sen averto. Kliento, kiu atingas la IP-on rekte, ankoraŭ bezonas funkciantan nomon.

Klientoj, kiuj konektiĝas per neserilata IP-adreso, ne devus devi forigi atestilajn erarojn por ke la projekto funkciu. Stabila nomo ankaŭ malhelpas sinkronigajn klientojn krei duoblajn servilajn enskribojn, kiam adreso ŝanĝiĝas. Tio estas la diferenco inter privata servo kaj privata IP.

Lasu atestilan validigon ŝaltita. Privata reto malpliigas eksponiĝon, sed ĝi ne igas nevalidigitan TLS-konekton akceptebla, kaj kliento lerninta ignori avertojn ankaŭ ignoros ilin en aliaj retoj.

Limigu retaliron, ne la tutan LAN-on

Permesu al enskribitaj uzantoj atingi la Nextcloud-servon kaj ĝiajn necesajn dependaĵojn, kaj tenu servilan administradon sur aparta vojo. VPN, kiu lasas klienton en la tutan hejman aŭ oficejan reton donas al tiu kliento multe pli ol la aplikaĵo postulas.

VPN-aliro ne anstataŭas Nextcloud-kontojn, permesojn aŭ plian aŭtentikigon. La aplikaĵo ankoraŭ decidas, kiu uzanto rajtas legi kiun dosieron, kaj la rettavolo ne devus esti la sola kontrolo.

Registru la aprobitan fontan intervalon kaj la servajn pordojn. La posedanto de la celo bezonas la observitan fonton, kaj NAT aŭ prokseo povas reskribi ĝin antaŭ ol la peto atingas la aplikaĵon.

Revizuu ĉiun laborfluon ekster la retumilo

Labortabla sinkronigo kaj movilaj alŝutoj malfermas siajn proprajn konektojn je siaj propraj tempoj. Ili bezonas la aprobitan privatan vojon, kiam ili konektiĝas, kaj ili povas konduti alie, kiam la VPN mankas: reprovi, paŭzi aŭ montri eraron. Testu ĉiun, ne nur la retumilon.

WebDAV-iloj kaj kalendaraj aŭ kontaktaj klientoj estas apartaj integriĝoj kun propra agordo. Kliento, kiu kaŝmemorigas publikan URL-on, daŭre provas tiun URL-on post la perimetra ŝanĝo, kaj la malsukceso aspektas kiel aplika problemo.

Dividitaj ligiloj meritas eksplicitan decidon. Ligilo ne donas al sia ricevanto VPN-aliron, do en vere nur-VPNa projekto ekstera ricevanto ne povas uzi ĝin, eĉ se la ligilo validas. Se ekstera kunhavigo necesas, tio estas intenca escepto kun propra alirvojo, ne malatento, kiun oni malkovros poste.

Federado kaj servilo-al-servilaj integriĝoj bezonas la saman traktadon. Ili estas atingeblaj rilatoj inter instalaĵoj, kaj nur-private disfaldiĝo devas diri, ĉu ili estas subtenataj.

Akceptu kaj la permesitan kaj la rifuzitan kazon

De aprobita kliento, kontrolu la retan interfacon kaj ordinaran dosieralŝuton aŭ -elŝuton. Poste kontrolu sinkronigan klienton kaj unu laborfluon ekster la retumilo. Sukceso nur en la retumilo ne estas akcepto.

De neaprobita vojo, konfirmu, ke la aplikaĵo estas neatingebla tra ĉiu enirejo en la listo. Testu la alternativan gastigantnomon kaj la IPv6-adreson, ne nur la ĉefan URL-on.

Fine revizuu la agordojn de la aplikaĵo, kiuj facile konfuziĝas kun reta politiko. trusted_domains listigas nomojn, kiujn la ekzemplero akceptas; ĝi ne estas permeslisto de klientaj IP-oj. Se inversa prokseo provizas adresinformojn, trusted_proxies devas nomi la faktan prokseon, kaj plusenditaj kaplinioj estu akceptataj nur de ĝi.

Daŭrigu la kutiman plifortigadon apud la reta ŝanĝo: tenu datumojn kaj sekurkopiojn ekster neintencitaj retaj vojoj, flikumu la aplikaĵon, protektu administran aliron kaj tenu restaŭradon uzebla. VPN forigas enirejan surfacon; ĝi ne igas enskribitan klienton fidinda.