DarkMan83

Members
  • Posts

    88
  • Joined

  • Last visited

Converted

  • Gender
    Male

Recent Profile Visitors

585 profile views

DarkMan83's Achievements

Rookie

Rookie (2/14)

17

Reputation

  1. Könnte sein, dass das bei dir nicht funzt, weil du den swag CF Mod nicht installiert hast? und bei mir benutze ich die Hauptdomain nicht, weil ich noch einen normalen Server im rechenzentrum habe. Die Konfiguration hab ich bei mir auf jeden Fall laufen, wichtig ist bei SWAG das Zertifikat als wildcard erstellen zu lassen, dann funktioniert es auch. damit das Zertifikat in SWAG dann für *.deinedomain.de gilt, sonst akzeptiert der die anderen Subdomains nicht. aber wenn deine config für dich so okay ist, ist ja alles gut. Gruß Dark
  2. du machst eine Subdomain mit einem CNAME und kannst dann beliebig viele Subdomains per CNAME als Alias erstellen und als Ziel die erste Subdomain benutzen. deshalb ja in Cloudflared *.deinedomain.de und in SWAG wildcard. Also in CF z.B. erste Subdomain: CNAME cloud und Ziel der ARGO Tunnel. Subdomain 2: CNAME plex und Ziel cloud.deinedomain.de P.S. Bitte bedenkt, dass wir SWAG sozusagen als firewall benutzen, da wir hier einen VPN Tunnel aufbauen, geht der traffic vorbei an der Firewall in eurem router und direkt zum server. Glücklicherweise hat CF ja eine Firewall, dort hab ich z.B. diverse Länder geblockt und auch immer den Botfight modus an! Wollte ich nur mal gesagt haben. Gruß Dark
  3. ich habe in CloudFlare keine extra Zertifikate hinterlegt, nur das generelle aktiviert. Ich sage ja nicht, dass mein Weg der richtige ist, aber es funktioniert alles. Wenn es anders und beste Wege gibt, klärt mich gerne auf, bin für beste Lösungen offen.
  4. klar, wird alles geforwarded und als Verifizierung nehme ich ja Verifizierung über DNS und damit geht er über die CloudFlare API und das läuft nicht über den Tunnel kennt swag ja nicht... wenn man auf die Domain kommt, steht da eh das CF Zertifikat, also wayne... aber cloudflared leitet die Domain an swag weiter und damit kann swag sein eigenes Zertifikat für die Domain checken. Bei mir funktioniert es zumindest alles, siehe auch Screenshot für swag config. Nochmal angemerkt: Wenn man in swag Verifizierung über DNS (CF) am hat, dann braucht man keinen offenen Port 80 o.a., da alles per CF API gemacht wird.
  5. du brauchst eigentlich kein Zertifikat in CloudFlare erstellen und in nginx registrieren, wenn du swag benutzt, dort werden automatisch Zertifikate erstellt... Aber mach dir du meinst 😁
  6. Hab mich da auch an das Video von Ibracorp gehalten und lasse mein Plex über swag laufen... Cloudflare -> Cloudflared -> Swag -> Plex In Plex Fernzugriff deaktivieren und unter Netzwerk dann die url z.B. https://plex.deinedomain.de:443 eintragen. Im Router alle Portfreigaben deaktivieren, werden nicht mehr benötigt -> Ich lass alle Webanwendungen über den Argo-Tunnel laufen, dementsprechen hab ich kein Port 80 + 443 mehr offen, da alles dann über Cloudflared kommt und dann durch SWAG an den richtigen Docker geht. Zusätzlich ist der Vorteil, dass nun alles erst bei CF durch die Firewall muss. Die Rule bei Cloudflared sieht bei mir z.B. so aus: # forward all traffic to Reverse Proxy w/ SSL ingress: - service: https://192.168.1.25:443 originRequest: originServerName: "*.deinedomain.de" SWAG-Config: Die SSL-Einstellung bei CF sieht bei mir so aus: Ich habe heute einen Stream getestet und das sieht man auch an den verarbeiteten Daten -> 5 GB Wenn du die Weboberfläche deines Plex auch über die Subdomain erreichen möchtest, dann musst du bei Cloudflare noch im Dashboard unter Regeln eine Ausnahme für deine Plex-Subdomain einrichten und den Rocket-Loader deaktivieren. Gruß Dark
  7. Ich hebe bei mir gar keine Portfreigaben mehr eingerichtet, läuft alles über CF Argo Tunnel und da muss der gesamte traffic ja darüber gehen... Sonst könnte man ja von extern nix auf plex schauen. Und das dashboard zeigte auch so 20GB nach einem Film an. Gruß Dark
  8. New report here: Currently I'm on Unraid 6.9.3 and just added another drive. Including cache I'm having 12 drives. The problem is back for me, regardless if on mobile device or desktop pc and it's also regardless which browser i use (tested Edge which is chromium based, Chrome and firefox) and the problem is back. Had to write the config file by hand.
  9. Host access is disabled and no container rely on any other and each restart other Containers are online, so it seems to be random...
  10. Does anyone still have the docker problem after reboot/cold boot? each time only some dockers started (random and regardless of bridged or br0 etc.) after reboot and i have to disable and reenable the docker service?
  11. This should explain, why the panics doesn't occur after a crash/restart of the server, because setting the "Host Access" to yes does not persist a reboot for me. After reboot it shows still yes, but the host can't access the container. So i have to disable and than enable host access in the settings again. After that it works again but the kernel panic will occur at some time. Mybe i'm alone with this setting persitant bug, but if more ppl on the same boat and it' unknown untill now, than there could possibly much more ppl with kernel panics upcoming Could be easily verified, just ping the container from host after reboot. P.S. Sometimes i'm running for weeks until a panic occurs.
  12. okay, for me it only worked on my workstation. It's interesting, that it worked for you on pixel.
  13. Okay, verified... On my desktop pc with e.g. chrome all the settings working and nothing is overwritten. (verified 3 times) On my Tablet (Galaxy Tab S6 OS: Android) with Chrome the problem occurs. Holy shit, who could ever imagine thats the Client-Browser / OS combo...