-
Posts
378 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by Mainfrezzer
-
-
Ist das einfachste Konstrukt um den externen Unraid Server zu dem hiesigen zu verbinden um sich gegenseitig Backupdaten zuzuschieben und Medien für Jellyfin jeweils zur Verfügung zu stellen. Ob ichs jetzt mit Wireguard mache oder die (aktuell) kaputte Tailscale variante ist am Ende egal^^
Selbstverständlich hab ich natürlich den Zugriff zum Unraid Webinterface untersagt, IPTables ist einfach wunderbar. Wobei das eigentlich nicht nötig gewesen wäre, ich vertraue der anderen Person doch schon sehr.(Anmerkend und nachträglich, ist ja nur Server zu Server, kein Nat, kein LAN zu LAN, einfach nur ne simple Verbindung. Ich denke das ist noch sehr verkraftbar in der Hinsicht auf den Sinn und Zweck der Verbindung. Für etliche TB an Daten die über meine externen Server geschaufelt werden möchte ich dann doch nicht den Traffic bezahlen^^)
Edit:
Ich möchte, falls jemand etwas ähnliches sucht, natürlich nicht vorenthalten wie das ganze funktioniert
Folgendes Beispiel blockiert alles bis auf das Unraid Gui, bzw was auch immer auf tcp 80 läuft. Das TCP 80 kann man sich ja anpassen wie man lustig ist, z.b. 445 für SMB mit UD Plugin. Die FORWARD Regel(n) sind für Dockercontainer da.
(Lustige Anmerkung, selbst im Tunnel benötigt man icmp, lol. Man kann es zwar deaktivieren muss aber manuell vom Server zum Client pingen um ne Verbindung aufzubauen)
PostUp=logger -t wireguard 'Tunnel WireGuard-wgX started' PreUp=iptables -I INPUT -s 10.12.12.2 -j DROP;iptables -I FORWARD -s 10.12.12.2 -j DROP;iptables -I INPUT -p icmp -s 10.12.12.2 -j ACCEPT;iptables -I INPUT -p tcp --dport 80 -s 10.12.12.2 -j ACCEPT PreUp=ip6tables -I INPUT -s fc00:12:12:0::2 -j DROP;ip6tables -I FORWARD -s fc00:12:12:0::2 -j DROP;ip6tables -I INPUT -p icmpv6 -s fc00:12:12:0::2 -j ACCEPT;ip6tables -I INPUT -p tcp --dport 80 -s fc00:12:12:0::2 -j ACCEPT PostDown=logger -t wireguard 'Tunnel WireGuard-wgX stopped' PostDown=iptables -D INPUT -s 10.12.12.2 -j DROP;iptables -D FORWARD -s 10.12.12.2 -j DROP;iptables -D INPUT -p icmp -s 10.12.12.2 -j ACCEPT;iptables -D INPUT -p tcp --dport 80 -s 10.12.12.2 -j ACCEPT PostDown=ip6tables -D INPUT -s fc00:12:12:0::2 -j DROP;ip6tables -D FORWARD -s fc00:12:12:0::2 -j DROP;ip6tables -D INPUT -p icmpv6 -s fc00:12:12:0::2 -j ACCEPT;ip6tables -D INPUT -p tcp --dport 80 -s fc00:12:12:0::2 -j ACCEPT
10.12.12.2 und fc00:12:12:0::2 ist die Wireguard-Netz-Client IP -
2 minutes ago, Ford Prefect said:
Wiregurad an sich braucht davon (icmp) nix um zu funktionieren/einen Tunnel aufzubauen, aber ich kenne die Implementierung im unraid Plugin/Docker nicht.
Ja das ist ja das, was mich auch verwundert hat. Die ganzen VPN-Docker, Telefone und PCs hier im Netz haben sich wunderbar verbunden, nur Unraid nicht.
Ich hab gestern deswegen noch nen Bugreport aufgemacht. Habs ja dann hier getestet.
Server 2 zu 1 ging wunderbar.
Modifizier ich meine Fritzbox damit die icmp blockiert funktioniert Server 2 zu 1 nicht mehr. Kann nur daran liegen. Weil sonst funktioniert ja alles -
Die ganze Konfiguration war schon richtig. Das Problem ist der Speedport bzw Unraids implementierung von Wireguard. Das ausbleiben von "Ping" antworten, ich hab nicht genau geguckt welche spezifische icmp Abfrage da gestartet wird, macht Unraids Wireguardclient unnutzbar. Wundert mich dass das nicht schon vorher bemerkt wurde. Die ollen Telekomrouter sind ja doch sehr verbreitet. Aber ich denke mal dass die Leute die sowas hier aufsetzen ne Fritzbox haben und die hat, solange man nicht die Box manipuliert, keine möglichkeit ipv4 icmp anfragen zu blocken.
Achja:
Ich habs jetzt einfach so gelassen dass sich Server 2 zu Server 1 verbindet. Ist ja im Endeffekt egal und wahrscheinlich auch besser weil so Server 1 nicht warten muss dass die öffentliche IP von Server 2 geupdated wird. -
Delete the offending wg2 files on the usb in /config/wireguard. (If there's a remenant in the peer subfolder, that too).
Then try again. If that doesn't work again I would try another browser.
-
9 minutes ago, julianmueller95 said:
Is there anything majorly wrong configured?
Yes, indeed.
https://docs.unraid.net/unraid-os/release-notes/6.12.4/#fix-for-macvlan-call-traces-
1
-
-
You can fix your issue simply by changing the "Repository:" entry from from
"oznu/homebridge:ubuntu" to "homebridge/homebridge:latest"
I reckon the settings should be the same since they moved the repository. That would be all. -
Ich habe hier ein sehr komisches Phänomen welches mich so langsam den Verstand kostet.
Ich versuche, ich verrate nicht wie lange schon, Server 2 Server access via Wireguard aufzusetzen. Gut, in der Theorie sollte das ja recht simpel sein.
Ich habe nen Tunnled Access auf Server 2 erstellt.
Ich kann auf den Server 2 zugreifen via mein Telefon, via Laptop und Wireguard Software, via VPN-Dockercontainer. Das funktioniert alles wunderbar. Unraid auf Server 1 will ums verrecken sich nicht sich mit den Server verbinden.
Wenn ich das Spiel umdrehe, Server 1 wie Server 2 einrichte, dann verbindet sich Server 2 zu 1 ohne Probleme. Ich hab das ganze auch mal versucht mit einem 3. Server und dort Verbindet sich Server 1 hin. Selbst zu meinen ganzen Servern bei externen Hostern funktioniert das ganze.
Server 2 steht hinter nem Speedport "Smart" 3 und ich denke das Stück macht Unraid aus irgendeinem Grund Probleme, ich hab nur keine Ahnung wieso. Hat da jemand ne Idee woran das liegen könnte?
Ich hatte kurzeitig Server 2 Server ans laufen bekommen, allerdings wollte das nur funktionieren wenn ich auf Server 2 den Server 1 via Wireguard-Netz-IP anpinge, sonst baute sich die Verbindung nicht auf.
Edit: Ich hab ja ganz ganz ganz stark die Vermutung dass die fehlende icmp response das Problem bei Unraid verursacht. Hab jetzt keine Lust zu gucken ob das so nun bei Unraid integriert ist, was anderes kann ich mir allerdings nicht erklären.
Edit #2: Hab gerade meine Fritzbox modifiziert und jap. Ohne icmp reponse funktioniert Unraids Wireguard nicht. FUCK -
3 minutes ago, J_Dub said:
Oh Geez....That was an easy fix, didnt realize that function created the br. It appeared when i looked in that, that it just linked existing interfaces. Thank you alot for the assistance.
you can link multiple nics together so that a vm on eth0 can talk to a container on eth1 but you can also just run 1 nic as bridge so they, docker and vms, can talk with each other.
Glad i could help -
-
if youre already that far, you should have the option to create a bridge by simply going to Settings/NetworkSettings.
-
The easiest way to is use a secondary nic. USB or Onboard (granted the usb one works on the current build)
Otherwise youre left over with a virtual nic and thats pain on unraid, unless you get static ips. -
On 9/6/2023 at 3:29 PM, ich777 said:
should have looked here before figuring that out for myself. I was baffled earlier today when i couldnt use the lxc container anymore to use the reverse proxy i set up on it to access my dockers to circumvent the host access requirement. i could have sworn that was working before.
Since i have to activate it now for it to work, i can scap the lxc plugin completely. thank you for the plugin, served me very well ❤️-
2
-
-
xfs is only available for single disk pools. your option would be zfs mirror in that case.
-
Just now, sbeex said:
Ok if that helps I didn't do any kind of optimization for the power usage.
huh, if thats the case, diagnostics certainly would be needed, once that issue occurs. given that youll need physical access to the server once it happens or you trigger a reboot, syslog server needs to be setup beforehand
That behavior is usually pretty common with powertop. it just simply turns the nic of, once theres no more network activity and never turns it back on. -
Sound highly like a powertop --auto-tune issue
-
Ich weiß ja nicht welche Influxdb 1.8 probiert wurde, die im Appstore ist definitiv nicht Alpine und hat apt als Paketmanager
-
So, ive set it up on my end for visual guidance.
Binhex
Chrome:
What you need to enter into the binhex console
iptables -A OUTPUT -s 172.17.0.0/16 -d 10.0.0.0/24 -o eth0 -p tcp -m tcp --sport 8080 -j ACCEPT && iptables -A INPUT -s 10.0.0.0/24 -d 172.17.0.0/16 -i eth0 -p tcp -m tcp --dport 8080 -j ACCEPT
Change the 10.0.0.0/24 to whatever your network is. 192.168.0.0/24 for example.
Now you can access your Binhex Interface on UNRAID-IP:8181 and your chrome docker is UNRAID-IP:8080
From the chrome docker you can just access the rest from the 172.17.0.X:PORT
As mentioned before, if you go the privoxy route, which i highly recommend, it looks like this:
You change in binhex the Key 8: (ENABLE_PRIVOXY) to "yes"
you open your firefox, chrome, edge, whatever. Go to setting and search for "Proxy"
You set the http proxy to your unraidip:8118
now your browser gets routed through the vpn container and can access 172.17.0.X natively and you dont need to use the iptables command on every binhex-container start. -
thats because if you funnel a container through another container, it ignores the mappings from the template. 8080 is the port that chrome would have on the qbittorrentvpn.
Depending on how you connect it changes following:
Scenario 1: You connect through privoxy
You would just enter 172.17.0.6:8080 or whatever your binhex ip is
Scenario 2: you still try to reach the chrome vnc without privoxy
If 8080 is already used on your server, you would map the container port in binhex from 8080 and "translate" it to port 8222 on the host side. You would need to enter and also change the iptable rules for that and then you could connect via the unraid ip + port
Edit:
I just saw the 8080 is being used by the binhexcontainer. Thats unfortunate^^ i would highly recommend you take the delugevpn in this case because that another can of tuna i dont wanna open now(although, it seems like you can just move it. So do that, put binhex WEBUI_PORT on something else than 8080 or any of the other ports the "passthrough" container will use. 8181 or something)
-
12 minutes ago, mike_2246 said:
and this will work with Chromium? really don't wanna deal with the pain of influx either lol.
just want to do a simple speedtest
the http proxy work with any browser. (dont ask me for anything about phones xD)
Unless you wanna connect to the browser within the vpn connection to use the vpn connection. that wouldnt work and you need to run following code in the binhexvpn containeriptables -A OUTPUT -s 172.17.0.0/16 -d YOUR.LOCAL.NET.WORK/24 -o eth0 -p tcp -m tcp --sport 8080 -j ACCEPT iptables -A INPUT -s YOUR.LOCAL.NET.WORK/24 -d 172.17.0.0/16 -i eth0 -p tcp -m tcp --dport 8080 -j ACCEPT
so that you can connect from your browser, to the browser. But thats a bit unnecessary since you can just tell your browser to use the privoxy http proxy and type in the adress:port of the services you want to reach.
-
Okay, ive spend too much time with that influxdb stuff
Quick work around is to enable and use privoxy in the binhex container and use that to access the container that are tunnled through the binhexvpn
172.17.0.X ip for the binhexcontainer :port for the service, that works. and doesnt require messing around with the docker image.
(If you wanna mess with the docker image, you have to use iptables to allow the connections, but that is not persistent unless you modify the whole docker image for that)
iptables -A OUTPUT -s 172.17.0.0/16 -d YOUR.LOCAL.NET.WORK/24 -o eth0 -p tcp -m tcp --sport 8080 -j ACCEPT iptables -A INPUT -s YOUR.LOCAL.NET.WORK/24 -d 172.17.0.0/16 -i eth0 -p tcp -m tcp --dport 8080 -j ACCEPT
for chrome, for example
-
Which particular containers are you using? So i can have a look at it.
-
Well, did you "forward" the port(s) in Binhexvpn? Meaning adding the portmappings from the speedtest container to the binhex container?
-
Set the speedtest container to networktype = none and add this to the extra parameter
--net=container:binhex-delugevpn
(replace "binhex-delugevpn" with any container you want, i.e. "binhexvpn")
-
Habe mir jetzt gerade mal die Zeit genommen das auf 6.12.4 zu testen. Scheint wohl ein bisschen "funky" zu sein. vhost0 wird zwar vor Wireguard erstellt, startet wohl den Tunnel fürn kurzen Moment und dann isser wieder aus. Da müsst man sich wohl nen script zusammen schustern dass den Tunnel nochmals neu startet oder über nen 2. Tunnel rein & dann nochmals starten.
( sleep 60 ; wg-quick up wg0) &
(ggf. wg0 gegen den Tunnel auswechseln der dafür benutzt wird)
Das in der go Datei sollte das Problem beheben. Vhost scheint wohl wie shim-br0 an Docker gebunden zu sein. Das heißt aber auch dass man noch den 2. "Notfallzugang" benötigt falls mal das Array nicht startet, obwohl vhost0 immer da ist.
Edit: Bemerke gerade, die schöne Umgehung funktioniert nicht so dufte wie früher. Mit vhost0 kommt man zwar wunderbar überall ins Lan und auf Unraid, allerdings nicht mehr ins Internet (Abgesehen man lässt ipv6 auf eth0). Im Endeffekt muss man dann halt wählen. Zugang zum lokalen Netzwerk und Unraid oder Zugang zu Unraid und dem Internet. Is ja aber auch nun wieder die 2 - Tunnel Lösung.
Update:
Die Funktionalität kann herstellt werden mit
PostUp=logger -t wireguard 'Tunnel WireGuard-wg4 started';/usr/local/emhttp/webGui/scripts/update_services PostUp=iptables -t nat -A POSTROUTING -s 10.253.4.0/24 -o eth0 -j MASQUERADE;ip6tables -t nat -A POSTROUTING -s fc00:253:4:0::/64 -o eth0 -j MASQUERADE PostUp=iptables -t nat -A POSTROUTING -s 10.253.4.0/24 -o vhost0 -j MASQUERADE;ip6tables -t nat -A POSTROUTING -s fc00:253:4:0::/64 -o vhost0 -j MASQUERADE PostDown=logger -t wireguard 'Tunnel WireGuard-wg4 stopped';/usr/local/emhttp/webGui/scripts/update_services PostDown=iptables -t nat -D POSTROUTING -s 10.253.4.0/24 -o eth0 -j MASQUERADE;ip6tables -t nat -D POSTROUTING -s fc00:253:4:0::/64 -o eth0 -j MASQUERADE PostDown=iptables -t nat -D POSTROUTING -s 10.253.4.0/24 -o vhost0 -j MASQUERADE;ip6tables -t nat -D POSTROUTING -s fc00:253:4:0::/64 -o vhost0 -j MASQUERADE
[6.12.4] Multiple network related issues and crashes after latest update
in General Support
Posted
Its currently impossible (theres probably a work around but i have not spend the time or efford into figuring that out yet) to have Internet and Lan Access while Host Access is enabled and youre running the Macvtap.
You would need two tunnel for that. One where its possible to reach unraid and the internet and one where you can only reach unraid, the lan and the docker container.
Cant comment on your normal networking issue.