Inlägg

Inlägg som Pitr- har skrivit i forumet
Av Pitr-
Skrivet av fastcat:

Omformulerar frågan, misslyckades i formuleringen Klarar Edgerouter ER-6P att driva den switchen (48V) via POE? Jag tror inte det. Min gamla Edgerouter POE som nu är sönder klarade detta.

Det är korrekt uppfattat, ER-6P stödjer endast deras egna passiva 24v PoE-matning och inte 802.3af/at aktiv PoE-förhandling. En annan nackdel med just den PoE-standarden är att risken är stor att man grillar diverse nätverksutrustning om man råkar koppla in nätverkskablar på portar som du har konfigurerat för passiv 24v utmatning vilket är direkt obra. :-S

Av Pitr-

GS108T stödjer 802.3af för PoE-PD, så ja du ska kunna strömsätta den med aktivt förhandlad 48v på port 1.

Av Pitr-

Ja det första du bör göra är att mäta av alla nätverksuttag. Om du inte får kontakt över alla 8 ledarna på alla portar, eller om någon v ledarna är felaktigt kopplade, så kommer ditt nätverk aldrig att bli bra. Grunderna måste vara på plats, sen kommer resten att falla tillrätta och fungera stabilt ska du se.

Av Pitr-
Skrivet av goodfidelity:

Anledningen att jag vill skilja på det med två WiFi nätverk är som jag tidigare nämnt. Att det är jättelätt att byta mellan näten.
Jag orkar inte logga mig in i en router och ändra inställningar, komma ihåg IP adresser till enheter och strula på varje gång.

Om man har två (eller flera) WiFi nät så går man bara till Wifi-menyn och väljer det nät man vill använda, som erbjuder de funktioner man vill ha. Inga klienter i maskinerna, inga lokala inställningar, inget probelm när man får en ny - tillfällig eller permanent - enhete på nätet. Det skall bara funka. På sin höjd skall man behöva komma ihåg lösenordet till nätet, thats it.

Med rätt utrustning så är det förstås inget problem att sätta upp en lösning likt den du beskriver. Utmaningen ligger i att få till en lösning likt nedanstående på konsument-utrustning.

https://picsur.rhz.se/i/a3940ad1-2ec4-4aaa-a751-75212e5318a2.jpg

Med min FortiGate-brandvägg och UniFi switchar och accesspunkter så kan jag fixa detta på 5 minuter om jag nu skulle vilja ha det på det sättet. Har motsvarande utrustning installerad hos alla mina nära och kära så bilden ovan är inte så krånglig att få till. Men jag ser inte riktigt vad det krångliga är att ha Synology NAS:en/seedboxen på samma nätverk som övriga klienterna, speciellt inte med konsument-utrustning då mer avancerad traffic shaping och smart queues inte är aktuella på sådan enklare hårdvara utan att det straffar sig på överföringshastigheterna.

Nu har jag förvisso min medialagring i separat VLAN kontra hemnät och gästnät av den anledningen att jag vill kunna begränsa åtkomst till olika tjänster på Synology NAS:en, och även för att begränsa extern åtkomst till denna alternativt endast tillåta åtkomst via IPSec GRE-tunnlarna som jag har uppkopplade mot föräldrarna, svärföräldrarna och polare. Men jag tillåter åtkomst direkt från deras respektive hem-nät så de inte behöver krångla med att växla mellan olika wifi-nätverk för att kunna komma åt bilder, dokument och dylikt som de har på filutdelningar på min Synology NAS.

Av Pitr-
Skrivet av enoch85:

Man kan också använda omvänd proxy om man bara har en extern IP, men vill köra flera tjänster i "backend". Du kan alltså ha flera servrar på port 80/443, vilket normalt sett inte är möjligt då man bara kan öppna en port mot en specifik tjänst.

Väl skrivet, kamrat enoch85, det är korrekt att omvänd proxy vanligtvis används för att exponera multipla webbapplikationer/backends bakom samma publika IP-adress. Alternativt för att erbjuda lastbalansering mot flera instanser av samma backend för att öka kapaciteten eller av redundansskäl.

För den som är nyfiken kan man läsa mer om detta i RFC 6066 där det beskrivs hur SNI, eller Server Name Indication, används av TLS-klienten för att kunna urskilja flera webbadresser som huserar in under en och samma IP-adress, denna standard inom TLS-protokollet är relativt nytt då de kom till så sent som 2003. Innan dess var det inte möjligt att husera flera SSL/TLS-skyddade webbapplikationer under samma IP-adress (åtminstone inte mig veterligen, men jag höll inte på så mycket med webbapplikationer och omvända proxy-servrar där 2003).
https://datatracker.ietf.org/doc/html/rfc6066 (punkt 3)

Helt klart överkurs, men kunskap är guld.

Av Pitr-
Skrivet av goodfidelity:

(ser att det finns både Emby och Jelly för KODI, men osäker på vad som är bäst att använda eller vad som fungerar på NAS eller om man måste ha en fristående maskin med LINUX/WIN/OSX på vilket jag gärna undviker, speciellt windows)

Så länge du har en Synology NAS som är intel-baserad och har absolut minimum 2GB minne (helst 4GB) så är det fullt möjligt att köra antingen Emby eller Jellyfin via docker-appen, guide för detta finner du på nedan länk.

https://mariushosting.com/how-to-install-jellyfin-on-your-syn...
https://mariushosting.com/how-to-install-emby-on-your-synolog...

Båda alternativen är bra, skillnaden är att Jellyfin är open source och erbjuder i princip alla funktioner från Emby Premium utan kostnad. Vissa som kör Emby påstår att den lösningen är lite stabilare i utvecklingen och lite lika benägen att lägga till nya funktioner lika snabbt. Det finns insticksprogram till KODI för båda "gafflarna" (bättre översättning på forks? Förgreningar?).
https://emby.media/support/articles/Premiere-Feature-Matrix.h...

För anslutning så skulle jag råda till att använda antingen MagicDNS i Tailscale eller publik DNS-namn såsom en DynDNS-adress för enkel anslutning så inte användarna måste ha koll på unika Tailscale IP-adressen för Tailscale-agenten på Synology NAS:en. För installation av Tailscale på Synology DSM kan du kolla in länken nedan.
https://tailscale.com/kb/1131/synology
https://tailscale.com/kb/1054/dns

Om du skapar upp ett konto på https://nsupdate.info så kan du där skapa en statisk DynDNS-pekare exempel valfritt.nsupdate.info och ange Tailscale IP-adressen på Synology NAS:en. När detta är på plats så bjuder du bara in de övriga till Tailscale-nätverket och ber dem därefter att ansluta in mot http://<valfritt>.nsupdate.info:8096 för åtkomst till Jellyfin eller Emby vad du nu valde för lösning. Observera att trafiken går över oskyddad http, men eftersom detta endast är nåbart inom Tailscale VPN-mesh nätverket så är det ingen direkt fara med detta. Du kan förstås använda IP-adressen också så de ansluter mot http://IP:8096, men det kan ju uppfattas lättare att komma ihåg http://goodfidelity.nsupdate.info:8096 över http://10.252.173.14:8096. ;-D

Av Pitr-

Som tearzyo skriver här ovan, så gör du klokt i att göra lösningen så enkel som möjligt. Det var ju bra att han påpekade just avsaknaden av multicast/broadcast med lösningar såsom Tailscale och Headscale.

En annan har ju passerat 40-årsstrecket nu och får numera stå ut med att bli kallad senior konsult, vad man nu sätter för värderingar i det. När man varit med så här länge, och älskar att hänga med i race:et, så vet man att man aldrig kan bli "fullärd" utan det är en konstant jakt på nya fiffiga lösningar på alla upplevda användar-"problem".

Om det inte vore för att så många hemma-uppkopplingar numera hamnar bakom CG-NAT och därmed delad IP-adress, så hade det gått att filtrera accessen utifrån namnuppslag på DynDNS-pekare för att begränsa vilka som får nå interna tjänster via port forwarding/per-port destinations-NAT. Det är dock inte många konsument-routrar som stödjer brandväggsfilter utifrån DNS-namnuppslag (mig veterligen ingen jag har råkat över).

Men så länge den exponerade tjänsten i fråga är skyddad av någon form av autentisering och då helst där svaga lösenord inte tillåts samt att du tvingar på två-faktor autentisering, vilket båda är möjligt med Synology och DSM om du använder dig utav exempelvis Synology Video Station och Photos-tjänsterna/apparna. Då skulle jag säga att det är acceptabelt så länge du tillåter DSM och applikationerna på Synology-enheten att auto-uppdatera sig själva för att minimera exponering av eventuellt upptäckta sårbarheter, men detta sköter Synology bra om man aktiverar auto-update funktionaliteten.

Av Pitr-
Skrivet av ElFeo2:

Ok, försöker läsa på lite för förstår nada :(. "route -n" på min RPI ger:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0

Vet inte hur man tolkar detta...

Ja det där säger inte mer än att du har en route ut mot internet (0.0.0.0/0) som går genom routerns IP-adress 192.168.1.1 som nästa hopp, samt att det lokala nätet är 192.168.1.0/24. Om OpenVPN är uppkopplat på RPi:en så borde du ha en rutt aktiv även över denna. För en överskådligare vy över rutterna kan du i stället köra kommandot "ip route list".

Vad menar du förresten med att du kör OpenVPN via Wireguard? Jag känner mig lite ringrostig på sådana hobby VPN-lösningar då jag normalt sett bara kör hårdvaruaccelererad IPSec. Jag läste lite på hur Wireguard sätter upp routing:en, tydligen sätter den upp en egen fristående tabell, därefter styr "rules" (ip rule) över vilken väg trafiken kommer gå. Att det fungerar att nå RPi:en när du sitter lokalt är ju ingen förvåning eftersom den trafiken inte ruttas utan switchas, problemet blir som sagt när du kommer in via VPN och troligtvis får en IP-adress i 172.16.x.x någonting som av en eller annan anledning leds någon annanstans i stället för att returneras tillbaks över VPN-förbindelsen till UniFi gateway:en. En masquerade av inkommande VPN-trafik mot 192.168.1.5 bör således lösa problemet då RPi:en då kommer se trafiken som att den kommer från 192.168.1.1 och sköter adressöversättning som en mellanhand.

Av Pitr-

Ja skulle gissa på att svaret kanske gömmer sig i routing-tabellen på routern kontra vilka IP-adresser som används på RPi:en kontra VPN där. Säg om du får B-klass nät (172.16.0.0/16) när du kopplar upp via Wireguard eller UniFi Teleport, och kolliderande nät används i VPN-tunneln på RPi:en. En potentiell lösning där skulle vara att du masquerade:ar inkommande trafiken från Wireguard in mot IP-adressen på RPi:en, då kommer det troligtvis fungera då den IP-adress RPi:en ser blir gateway IP:t på UniFi-routern, dvs C-klass nät (192.168.0.0/16) och således ingen krock. Eller om du konfigurerar om Wireguard-konfigurationen så du kör med ett C-klass nät även för detta.

Av Pitr-
Skrivet av goodfidelity:

Vill inte ha någon PC ståendes, och jag har ingen kunskap för att sätta upp eller underhålla en sådan.
Den drar dessutom ström och blir en källa till ljud osv.

Tänkte du att de övriga individerna ska strömma video-materialet från lagringen as-is, dvs utan transcoding? Potentiell problematik med att strömma videomaterialet precis i original-format är att total bandbredds-utnyttjande rent teoretiskt kan bli rätt högt om flera skulle strömma samtidigt, lägg till mesh-VPN på det som troligtvis begränsar genomströmningskapaciteten.

Citat:

Ditt förslag med DD-WRT låter bra, det kan man väl lägga in på en bättre begagnad router som man köper på blocket typ?

Jag har läst att folk har lyckats få in Tailscale på WRT-baserade routrar genom Entware-tillägget, så det är i alla fall teoretiskt möjligt. Frågan är hur man löser brandväggsreglering för trafik som kommer in via Tailscale kontra de lokala nätverken i routern, det var för länge sedan jag höll på med WRT för att jag ska kunna svara. Som ett annat alternativ så såg jag däremot att det finns en guide för installation utav Tailscale på EdgeOS-enheter såsom Ubiquiti EdgeRouter X som är rätt billig och kompetent, där behövs dock kompletteras upp med trådlös accesspunkt för komplett upplevelse, om än mycket högre kvalité än nån gammal skruttig Netgear- eller Asus-router med *-WRT.
https://github.com/jamesog/tailscale-edgeos

Citat:

Klarar den att köra två olika SSID från samma router? En med tunnel till annat nät och en med den lokala uppkopplingen?

Det går absolut att skapa upp multipla VLAN/subnät med varsina virtuella SSID:n i DD-WRT, för att ha olika trådlösa nätverk som matchar VLAN/subnät som definieras på LAN-portarna på routern.

Citat:

Jag undrar lite hur de får kontakt med varandra? Om de inte har statisk IP. Kan de använda typ Tailscale eller något liknande?

Som nämnt ovan så sägs det vara möjligt att köra Tailscale på WRT via Entware, frågan är väl snarare om det på vettigt vis går att blockera inkommande trafiken över Tailscale så trafiken bara kan ta sig till det separata strömningsnätet hos dig. Jag kör hårdvara på ett helt annat plan där man snackar SD-WAN och IPSec Mesh VPN så jag har aldrig riktigt tittat på lösningar såsom Tailscale för egen räkning.

Hur som så kommer du behöva gräva ner dig en bit i nätverksträsket för att komma dit du vill.

Av Pitr-
Skrivet av marmeladov:

Det där låter ju super-intressant och jag tackar väldigt mycket för tips om att undvika de där korten du nämner. Vad jag läst i xpenology-forum och annat har det varit en bitvis skumpig resa för de som kör med de korten, men inte så många andra alternativ nämndes. Därför blir jag väldigt nyfiken på det där IBM-kortet du länkar till. Rimlig kostnad med!

Ja IBM-korten är väldigt prisvärda av någon anledning, men det är ju grund och botten samma LSI 9300-chipset som sitter på det, och när man dessutom programmerar in IT-firmware och stänger av alla hårdvaru-RAID-funktioner eftersom dessa är rätt dumt att använda sig utav när man kör Xpenology och SHR med BTRFS som ju är en smidig lösning vid byten till större hårddiskar då du kan få tillgång till det utökade diskutrymmet direkt redan efter första disk-bytet, i stället för som med RAID-5/6 där du inte får tillgång till mer diskutrymme förens alla diskarna är utbytta och RAID-volymen ombyggd.

Citat:

Det skulle alltså gå finemang att köra ett sådant kort på en hp microserver gen8 och kunna köra xpenology på den med två sas och två sata-diskar?

Ja utan problem, docks så kommer du behöva ha en SFF-8643 till SFF-8087 adapter eftersom disk-hållaren har SFF-8087 kontakt och SAS3-kontrollern har SFF-8643 mikro-kontakter. Du hittar exempel på rak och vinklad SFF-8643 till SFF-8087 här nedan beroende på hur trångt det är vid kontakten för disk-hållaren, jag hittade inga vettiga bilder på detta.

https://s.rhz.se/7OUXr
https://s.rhz.se/lQwTn

Av Pitr-

Ja man ju lösa detta på en hel uppsjö av sätt, mer eller mindre komplicerade. Jag skulle säga att enklaste lösningen är att helt enkelt installera Jellyfin eller motsvarighet till detta på en PC med lite kraft under huven och som sitter i samma nätverk som Synology NAS:en och som då mappar upp mediearkivet via NFS eller SMB, och därefter antingen exponera Jellyfin via omvänd proxy alternativt via mesh-VPN.

Utmaningen där kan förstås vara om någon utifrån vill chromecast:a filmmaterial från din NAS, om de kör mesh-VPN på deras telefoner så kommer du tyvärr att tappa kontakten så fort du försöker skicka över strömmen till chromecast-pucken eftersom dessa inte sitter ansluten mot mesh-VPN. Det går förstås att runda genom att cast:a hela skärmen från mobilen vilket dock slukar rätt gott om batteri.

Om vi skulle förutsätta att alla dina bekanta/vänner har åtminstone DD-WRT/EdgeRouter/Mikrotik eller motsvarande router som stödjer IPSec eller Wireguard, så kan du förstås ansluta in alla deras routrar in mot din centrala nod och sedan skapa upp brandväggsregler så att man från deras vanliga "hemma"-nät får åtkomst till nätet hos dig där Synology:n och/eller Jellyfin-servern står. Med den lösningen kommer det gå att cast:a material från telefoner till lokala chromecast-puckar överallt, och utan att du exponerar ditt material ut mot omvärlden.

Den enklaste vägen är förstås att direkt exponera exempelvis Jellyfin från ovan exempel ut mot omvärlden med ett Let's Encrypt SSL-certifikat med exempelvis en gratis nsupdate.info DynDNS-adress (minvideoserver.nsupdate.info) om du inte vill köpa dig ett domännamn för ändamålet. På så vis får du en publik krypterad ändpunkt för åtkomst till video-materialet. Och förnyelse/hantering av exponering kan med fördel göras exempelvis med NPM (Nginx Proxy Manager).
https://www.nsupdate.info
https://nginxproxymanager.com

Av Pitr-

Som ovan nämnt så är Nanoswitch fel produkt för ändamålet. Den switchen är specifikt avsedd för att strömföra Ubiquiti:s 24 volts utomhus-utrustningar såsom radiolänks-enheter och är även designad för att tåla för utomhus väder och vind.

Den minsta switchen i UniFi:s sortiment som kan förse dig med aktiv PoE är UniFi Switch Lite 8 PoE, på vilken du finner 4st 802.3at-kapabla portar som klarar upp till PoE+ eller 30 watt per port.

Av Pitr-
Skrivet av marmeladov:

Åh spännande!
Jag är total novis på hela SAS-grejen med separata controllers osv, så jag har en del att sätta mig in i.
Jag tänkte sätta kortet i en Hp Microserver Gen8, men det kanske borde gå med samma Dell Perc H330 som du kör med ändå? Ganska köttig prislapp såg jag dock.

Ja det är inga problem, eller egentligen vilket LSI 9300-kort som helst flashad med IT-firmware.

Citat:

Jag hade annars spanat in HP P222, HP P420 eller kanske LSI 9211-4i som samtliga verkar ska fungera skapligt för Xpenology. Nackdelen är att HP-korten verkar gå varma så in i helskotta och leva rövare, vilket jag inte är så sugen på att veta av. Men det är ett jäkla meck att läsa sin in i då man börjar på noll

Jag försökte mig på P420 och jag har haft LSI 9211-4i tidigare, men i och med att SAS2-drivrutinen slogs samman med SAS3-drivrutinen så fick jag gigantiska problem med att få igång kontrollern, så jag gav upp tillslut då det var så jobbigt när NAS:en alltid gick ner vid uppgraderingar och krävde handpåläggning för att komma igång igen trots TCRP friend-addonet. Så jag skulle inte råda dig att gå den vägen. Den bättre vägen är att köpa ett IBM M1215 som är ett LSI 9300-8i kort. Se länkar här nedan.

Ebay-listning IBM M1215
https://s.rhz.se/BfCkN

IT-mode flash guide på STH Forum
https://s.rhz.se/LIiUx

Av Pitr-
Skrivet av marmeladov:

Ska i dagarna försöka hitta en controller så jag kan köra med ett par SAS-diskar jag kommit över istället för vanliga SATA. En sådan sak kan bli meckigt just pga stöd för drivrutiner osv i Xpenology, men det är ju ett problem jag själv satt mig i.

Jag kör med Dell Perc H330 flashade till IT-mode i två Xpenology burkar, en som DS3617 och en som DS3622xs+ vilket fungerar klockrent även med uppdateringar eftersom SAS3-drivrutinerna finns i kerneln på dessa och inte kräver några extra moduler. Så jag kan rekommendera dessa.

Av Pitr-

Med tanke på att Safeland:s integration bygger på vanliga SMS-larmen som du köper i Verisure, så kan jag inte tänka mig att det skulle försvinna då det skulle innebära att de tar bort möjligheten att få larm via SMS. Det är verkligen en bananas-enkel integration som bygger på existerande bas-funktion i Verisure:s platform.

Om de nu skulle ta bort SMS-notifikationsfunktionen i Verisure så är det förstås för att eliminera konkurrensen från Safeland och liknande företag, men sådant beteende borde vara anmälningsbart till konkurrensverket. Just larm-branschen är ju lite speciell då de historiskt sett alltid har tjänat bra på försäljning av dyr larmutrustning inklusive installation, samt att det bara är godkänt utav dem själva att göra ändringar på installationen såsom att flytta bas-station osv. Så man kan ju förstå om Verisure blir lite sura om en konkurrent sveper in och återbrukar utrustningen för att vinna över kunden genom att denne slipper betala 10-20K på nytt för att köpa in deras larm-utrustning.

Av Pitr-
Skrivet av jope84:

Men när jag youtuba lite om reverse proxy så var det en som rekomendera använda 2 st reverse proxy. En intern och sen en extern hos cloudflare. Sen skulle man bara öppna portar mot cloudflare .

Jag skulle säga att det finns både för- och nackdelar med denna lösning. Till fördelarna hörs förstås att Cloudflare har ett stort intresse av att få till så bra peering som möjligt med alla operatörer, men å andra sidan så är peering mellan våra svenska operatörer och stadsnät redan så pass bra att du kanske inte vinner så mycket i prestanda på att låta Cloudflare agera mellanhand för routingen.

Nu har de iofs datacenter i Stockholm, men jag läst om folk som kör på gratis-planen där de råkat ut för att trafiken går mot annan POP än närmsta, exempelvis där servrar inom EU i stället har gått via Cloudflare datacenter i USA vilket resulterar i försämrad upplevelse då trafiken måste gå över atlantkablarna. Nu kanske inte är så längre, vad vet jag. Jag har alltid haft publik IPv4-adress så jag har alltid exponerat tjänsterna direkt via internet-operatören utan mellanhand men med geoip-blockering på allt utom webbtjänsterna (80/443) eftersom jag publicerar ut tjänster som används internationellt och som potentiellt skulle dra nytta av åtminstone CDN-tjänster för att cache:a i mitt fall lineageos builds närmare slutanvändarna.

När det väl är störningar i stadsnätet så hjälps det inte att använda sig utav Cloudflare:s tjänster, så jag ser ingen vinning i det för min del. Men om man nu har oturen att inte kunna få en publik IP-adress, och inte vill driva en egen omvänd proxy i valfri hosting-lösning, ja då kan det ju onekligen ett enkelt alternativ att komma igång med.

Av Pitr-
Skrivet av jope84:

Aha då kanske jag inte behöver va rädd för exponera portar, och de har inte standardportar.
Men låter nog bli att exponera truenas admin och kamera övervakning mot nätet.

Men jag skall nog läsa på lite om reverse proxy för att få det smidigt med adresser.

Ja det är klokt att inte exponera admin-gränssnitt ut mot omvärlden, såsom för din TrueNAS, och även kamera-övervakning såvida du inte har åtminstone 2-faktorinloggning in mot NVR-gränssnittet.

Tänk dock på att alla portar du publicerar ut mot omvärlden kommer att indexeras utav tjänster såsom Shodan så räkna med att dina minecraft-servrar är allmän kännedom om du inte geoip-blockerar trafiken. Min minecraft-server syns exempelvis inte på Shodan då jag geoip blockerar access endast till Sverige och Norge då jag har polare med barn i Norge som spelar på servern, vilket jag gör genom min brandvägg. Men det är möjligt att göra geoip-blockering direkt i Linux, se länken nedan för enkel geoip-blockering.
https://github.com/friendly-bits/geoip-shell

Av Pitr-

Ja enklaste sättet att snabbt komma igång med Roundcube IMAP-klient (stödjer förvisso även POP3, men rekommenderas inte över IMAP), är att snurra upp den med docker compose. Du hittar en compose-fil för alpine linux med nginx/postgres på denna länk.
https://github.com/roundcube/roundcubemail-docker/blob/master...

Lagring av e-post sker förstås postgres-databasen eftersom Roundcube är just en e-postklient och således behöver ladda ner e-post för att kunna visa dem.

När du väl har Roundcube igång så skapar du upp konto, loggar in och konfigurerar IMAP/SMTP-inställningar för den e-postleverantören där Mail eXchange ligger och sen är du igång och kan läsa och skicka e-post via Roundcube.

För SSL-åtkomst så behöver du bara fixa med Let's Encrypt och komplettera med de maskade raderna i compose-filen, om du inte redan har en omvänd proxy på plats på servern, i sådana fall ändrar du bara port för tjänsten för att undvika konflikt och lägger upp roundcube i omvända proxy:n.

Av Pitr-

Vad säkerheten beträffar, så är det gravt överdrivet. Många oroar sig som om de satt på flera terabyte vetenskaplig data om nya mediciner eller lokal krypto-plånbok som på något magiskt vis skulle kunna bli nåbar från internet bara för att du publicerar en apache/nginx webbserver ut mot omvärlden.

Det finns förstås korkade saker man kan göra, såsom att exponera en SMB filutdelning rakt ut mot internet, eller FTP-server pekat in mot din privata lagring med familjefoton och där anonym åtkomst är aktiverad. Gör man något så dumt så ja då får man faktiskt skylla sig själv.

Det också främst om du tänker dig att du vill publicera flera webbtjänster som det är aktuellt om du vill undvika att publicera tjänsterna på icke standardiserade portar, andra portar än 80/443 exempelvis, eftersom du vanligtvis endast kan ha en tjänst terminerad på en port, där kommer omvända proxy:n in och agerar dirigent utifrån SNI (Server Name Indicator) eller den webbadress som man utifrån försöker nå, och vidarebefordrar trafiken till motsvarande tjänst på insidan utifrån webbadressen besökaren anger i deras webbläsare eller klientprogramvara.

En annan vanligt förekommande orsak till att man använder en omvänd proxy, är för att förenkla hantering av certifikat för krypterad trafik, genom att du exempelvis kan förse dig med ett eller flera wildcard-certifikat för den eller de domännamn du äger och som då används per automatik när du publicerar en ny webbapplikation under sagda domännamn vilket är smidigt. Så på så vis kan man säga att en omvänd proxy kan bidra till ökad säkerhet genom att förenkla för dig att sköta och förnya certifikat och undvika att ha utgångna certifikat som resulterar i certifikatsvarningar för gästerna.

Om du vill säkerställa maximal säkerhet vad gäller dina publicerade webbapplikationer så skulle jag säga att följande punkter är viktiga
* Håll ner antalet webbapplikationer till en hanterbar nivå
* Säkerställ att dina webbapplikationer hålls uppdaterade så du inte exponerar webbapplikationer med kända sårbarheter
* För webbapplikationer där det finns kända sårbarheter, men som du trots detta vill publicera, bör du begränsa åtkomst till för endast utvalda IP-adresser alternativt DynDNS-adresser (antingen via nginx, lokal brandvägg eller i din routers brandvägg)
* Om möjligt, placera dina webbapplikationer i ett fysiskt separerat nätverk från ditt vanliga "hemma"-nätverk, så om någon mot förmodan skulle ta sig in så kan de bara komma åt data som ligger på just den maskinen, detta kräver förstås lite mer kunskap från ditt håll och hårdvaru-förutsättningar för att skapa upp VLAN i brandvägg och switch(ar)

Vad gäller att exponera minecraft-servrar så är det inget att fundera över, såvida du inte vill begränsa vem som faktiskt får spela på servern men det går ju att begränsa på flera vis. Någon omvänd proxy behöver du inte använda dig utav i det fallet, utan det är när du vill exponera en webbapplikation mot omvärlden med möjlighet att filtrera trafik och övervaka åtkomst, då kan det vara en idé att exponera sagda tjänst bakom nginx. Se bara till att du patchar upp din minecraft server-instans så den hålls a jour vilket är common sense. Det kan vara en bra idé att automatisera uppdatering, så har du åtminstone gjort vad du kan för att säkerställa att ingen förstör dina minecraft-världar.