Jeg har for nylig opsat et Homelab, og jeg er ret ny til det, så tilgiv min uvidenhed.
Jeg har endnu ikke eksponeret mit Homelab for internettet (tilsyneladende), derfor bruger jeg Tailscale til fjernadgang. Mit spørgsmål er, hvad formålet med at bruge Omvendte Proxyer (RP) som Nginx, Traefik osv. er. Mit forståelsesgrundlag er, at det sikkert eksponerer dig (sikkert) for internettet, men der er stadig risici…
Alle på YT og Reddit synes at bruge RP, og jeg forstår ikke hvorfor. Så er der en god grund til at bruge det, eller skal jeg bare stole på Tailscale? Er der andre fordele ved at bruge en RP, som jeg gerne vil blive oplyst om. Tak på forhånd.
Den største funktion af RPs er at hoste flere (web)tjenester på den samme port.
En port kan kun knyttes til én kørende proces. Du kan køre flere webtjenester på en enkelt vært (=en IP-adresse), men så skal du bruge en anden port til hver tjeneste. Typisk vil disse porte være 8080, 3000 osv. Selv med statiske værtindgange eller DNS for hver af dine tjenester, skal du stadig bruge portnummeret i URL’er, f.eks. grafana.mydomain.com:3000.
En RP kører en klientvendt webserver og bruger TLS SNI til at vide, hvilken “backend”-tjeneste der tilgås. URL’erne behøver derfor ikke bruge portnummeret og er bare grafana.mydomain.com.
Der er nogle sikkerhedsfordele ved at bruge RPs (de er typisk veltestede modne tjenester, i modsætning til hvad hver enkelt tjeneste måtte bruge til sit webinterface), men de er irrelevante for små interne miljøer, der ikke er eksponeret for det offentlige internet.
En omvendt proxy udstiller ikke tjenester for internettet som standard. Du skal stadig konfigurere, at tjenester er tilgængelige udefra. Fordelen og grunden til, at de fleste bruger en omvendt proxy, er, at de ikke behøver at huske flere IP-adresser og porte. For eksempel: Hvis jeg har en tjeneste som Portainer, kan jeg indtaste denne tjeneste med IP’en lad os sige 192.168.10.20 og porten til Portainer, som er 9443. Så jeg skal indtaste 192.168.10.20:9443 for at få adgang til Portainer. Det er svært at huske. Med en omvendt proxy kan du opsætte et domæne eksempel.com og måske en underdomæne til din tjeneste. Hvis vi holder os til eksemplet med Portainer, kan du kalde URL’en portainer.example.com. Det er meget lettere at huske, fordi hvis du vil få adgang til Portainer, skal du blot skrive portainer i stedet for et nummer, du forbinder med portnummeret. Den omvendte proxy er forbindelsen mellem URL’en og IP’en.
Jeg ville bare bruge cloudflare tunnels.
Hvis du vil starte let, vil jeg anbefale at bruge Caddy. Det er super simpelt at opsætte til de enkle brugssager. Det håndterer endda certifikathåndtering, hvis du har et domæne.
Hvis du er helt ny, vil jeg anbefale Caddy som den nemmeste omvendte proxy at opsætte.
Nginx er meget kraftfuldt, men ret komplekst og overkill til hjemmebrug.
Tænk på det som at få dagligvarer leveret. Du kan gå til butikken med kendskab til den specifikke hylde (port #), hvor varen er, og vælge varen selv. Alternativt kan du få varerne klar til afhentning. Du siger bare, at du vil have en banan. Du behøver ikke vide, hvilke Aisles bananer er i. Nogen andre ved, hvor de er, og de vil hente den til dig.
Hvis du er butiksindehaver, giver dette dig nogle fordele. Du kan flytte bananerne til et andet sted i butikken uden at skulle informere hver kunde om, at de er et nyt sted. Hvis du har mange kunder, kan du skaffe bananer fra flere steder… måske endda en anden butik - kunderne er ligeglade, de vil bare have deres banan, hvordan du har fået den, er ikke vigtigt for dem.
Det er enkelt: Skal du give adgang til “ukendte” personer? Proxy!
Skal kun du (og måske folk, der bor i huset) have adgang? VPN!
At bruge en omvendt proxy er fordelagtigt i flere scenarier. Primært fra et sikkerhedssynspunkt, sidder en omvendt proxy bag en firewall foran dine webservere. En omvendt proxy afskærmer trafikken og adskiller din server fra frontend-adgang. Du kan deployere en dedikeret proxy-server på Linux (nginx, haproxy osv.), men du kan også bruge din firewall (pfsense, opnsense osv.) til at fungere som proxy. Dette giver dig yderligere sikkerhed, da du kan bruge IPs/ids-mekanismer til at kigge ind i den krypterede trafik, automatisere certifikatoprettelse (acme) osv. Sekundært hjælper en omvendt proxy dig med at organisere dine webeksponerede tjenester.
Som en tommelfingerregel: eksponer så lidt som muligt af tjenesterne til internettet og brug VPN, hvor det er muligt.
Håber det hjælper.
Fordele:
- køre flere “websteder” (=tjenester) på den samme port og den samme IP
- TLS-afslutning. Lad en dedikeret software håndtere det i stedet for det indbyggede TLS-bibliotek i billedet. +Effektivitet. +Tidsrigtige sikkerhedsopdateringer.
- autentificering. Fra helt enkelt HTTP Basic til mTLS og/eller SSO
- fuld kontrol over dine HTTP-anmodninger. Skal du URL-omskrivning eller tilføje en ekstra HTTP-header/cookie? Bare tilføj et par linjer i konfigurationen
Tailscale/VPN er fantastisk, men det løser kun ét problem (tillader udenfor adgang kun til dig, og ikke fremmede), mens alle andre problemer forbliver uløste. Hej, kan du lide at se “usikre websteder”-advarsler for dit http://192.168.1.100:8080? Personligt foretrækker jeg at arbejde med https://cloud.home.arpa eller https://cloud.example.com
Omvendte proxyer har flere hovedfordele.
-
De tillader dig at bruge virtuelle værter (forskellige værtnavne) for den samme IP/port-kombination. Så du kan pege “servicea.domain.tld” og “serviceb.domain.tld” på den samme omvendte proxy, men lade proxy’en dirigere dem til deres respektive backend. Dette kan hjælpe med at undgå at skulle bruge irriterende portnumre, især hvis du skal ændre nogle på grund af konflikter. De fleste kan også gøre nogle rigtig avancerede bevægelser, f.eks. regex-matches på URL’er, for at sende klienter præcis hvor du vil have dem.
-
De kan forenkle SSL-afslutning, autentificering osv. i et centralt sted. Forskellige tjenester håndterer SSL, autentificering osv. på forskellige måder, nogle irriterende. En omvendt proxy kan lade dig bruge, f.eks. et enkelt SSL-certifikat ét sted til forskellige tjenester og ved udskiftning (f.eks. med Let’s Encrypt automatisk) genindlæse kun én tjeneste for minimal afbrydelse. Eller lade dig sætte en SSO-udbyder op til forskellige apps i et centralt sted og derefter godkende al trafik gennem den.
-
De kan effektivt skjule teknologien og manglerne hos backend fra klienter. For eksempel, Node.JS-applikationer lytter ofte på 3000; hvis en angriber ser en tjeneste lytte på 3000, kan de konkludere, at det er Node.JS og angribe det med den viden. Men hvis det bare er noget andet bag NGiNX, der lytter på 443, er det sværere at finde ud af den slags information. Det gælder også for forskellige andre data i HTTP-headere, som SSL-versioner, HTTP-versioner osv. Det er som at sætte en flot stærk metalport foran din skrøbelige hoveddør.
-
De mere almindelige omvendte proxy-apps er designet til - og derfor rigtig gode til - at betjene HTTP-trafik. Derfor har de en tendens til at være mere sikre, i den forstand af sårbarheder, fejlrettelser, ydeevne osv. end mange enkeltstående apps, ofte med solo-udviklere. For eksempel kan en sårbarhed i, hvordan software håndterer HTTP/2-forespørgsler, lade din direkte-eksponerede app være sårbar, mens NGiNX sandsynligvis har en rettelse, før den endda er frigivet, eller meget snart efter. Så du får grundlæggende den ekstra sikkerhed fra værktøjets popularitet og udbredelse. De kan også fremskynde ved at cache statiske assets for backend’en og dermed spare arbejdskraft, især hvis backend-appen er ineffektiv.
-
De kan lade dig load-balance blandt flere backend-forekomster. For små selfhosters og homelabbers er dette normalt ikke et stort problem, men for redundans eller skalering kan det være nyttigt at køre flere backend-forekomster af en (relativt langsom) app bag en enkelt (relativt hurtig) omvendt proxy, der dirigerer klienter til den mindst-busy backend, gemmer assets som nævnt ovenfor osv. Dette er meget almindeligt for produktionssystemer, hvor du måske har for eksempel 10 worker VMs/kontainere bag en proxy, der håndterer belastningen. Fordi, som med 4, er dette, de er designet primært til, de er meget bedre til det. For eksempel kan en enkelt HAProxy håndtere over 10 Gbps webtrafik på en relativt gammel quad-core CPU uden at svede.
Af alle disse grunde er omvendte proxyer nu en slags bedste praksis, som alle bør følge, selvom du aldrig udsætter tjenesten for Internettet. Opsætningen er generelt trivial i forhold til de fleste faktiske backend-apper, og fordelene, selvom de er små, opvejer den ekstra kompleksitet.
Jeg gætter på, at et godt spørgsmål ville være, planlægger du at have nogle tjenester, hvor du ønsker, at andre uden for din VPN skal bruge dem? Eller er det her kun brugt af dig og ingen anden?