Jump to content

Mainfrezzer

Members
  • Posts

    378
  • Joined

  • Last visited

Posts posted by Mainfrezzer

  1. 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.

  2. 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

  3. 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 :D

  4. 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.

  5. 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

  6. 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

  7. On 9/6/2023 at 3:29 PM, ich777 said:

    Please do the following:

     

    Enable Host access in the Docker Settings:
    grafik.png.d49273679dd276a599a92744383beea2.png

     

    On the LXC Settings page set the network to eth0, click the Box "Change network from existing container" and then hit Apply:grafik.thumb.png.fa197af30b0cf525a03ce626ba471fb2.png

     

    This should do the trick.

    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 ❤️

    • Like 2
  8. 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.

  9. So, ive set it up on my end for visual guidance.

    Binhex

     

    binhex1.thumb.PNG.291405c4526fdfa0689ddb53bfea30b1.PNGbinhex2.thumb.PNG.6088b6988fa1e14fb49c4705b88a8ace.PNGbinhex3.thumb.PNG.7b711c6182a8dc3be50abb34931d4134.PNG


    Chrome:
    701697669_chrome1.thumb.PNG.e80d2d898ea4fc3e3fdf6bdf4847653d.PNG


    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
    tada.thumb.PNG.1054149d5cd089b259ed1ebd708043e8.PNG


    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.

  10. 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 xD (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)

  11. 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 container

    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

    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.

  12. Okay, ive spend too much time with that influxdb stuff xD

    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
     

  13. 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

     

×
×
  • Create New...