Wireguard verständnisfrage

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Moin.

    Habe es endlich geschafft mich mal mit Wireguard zu beschäftigen.
    Soweit so gut.

    Zur Info : Ich mach kein NAT, ich route.

    Was ich nicht verstehe ich das Ding mit dem AllowedIPs.

    Ich hätte jetzt vermutet das man auf dem Server in der Config unter [peer] in die AllowedIPs die Netze rein schreibt in die der Client zugreifen darf.
    Anscheinend kommt das aber in die Client config.

    Das ist schon ziemlich blöd, da dann der User selber Netze dort hinzufügen kann, oder gar 0.0.0.0/0 und sich lustig im Netz umsieht.

    Oder ich baue fleissig Regeln mit dem Netfilter um das zu verhindern.

    Ist dem tatsächlich so ?

    Offizieller Schmier und Schmutzfink des Forum.
    Warum einfach wenn's auch schwer geht ?

    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.

  • Das ist schon ziemlich blöd, da dann der User selber Netze dort hinzufügen kann, oder gar 0.0.0.0/0 und sich lustig im Netz umsieht.

    Ist dem tatsächlich so ?

    Nein, das ist nicht so, denn In der WG-Server-config kannst Du ja festlegen welche source-IP der WG-Client hat (bzw. haben muss) und abhängig davon, kann er sich im Netz umsehen oder nicht umsehen.

    Z. B.:

    Code
    :~$ ping -c 1 -I wg1 192.168.178.13
    PING 192.168.178.13 (192.168.178.13) from 192.168.22.14 wg1: 56(84) bytes of data.
    From 192.168.22.14 icmp_seq=1 Destination Host Unreachable
    
    --- 192.168.178.13 ping statistics ---
    0 packets transmitted, 0 received, +1 errors
    Code
    Mar  8 14:59:52 xxxxxx user.debug kernel: [21418.122340] wireguard: wg1: No peer has allowed IPs matching 192.168.178.13

    ... denn:

    Zitat

    In other words, when sending packets, the list of allowed IPs behaves as a sort of routing table, and when receiving packets, the list of allowed IPs behaves as a sort of access control list.

    Quelle: https://www.wireguard.com/#cryptokey-routing

    EDIT:

    BTW: Für mich ist "AllowedIPs = 0.0.0.0/0" ein Tabu (ein No-Go). Denn damit kann auf dem Peer (Client/Server) sein "default Routing" & Co. auch so ändern, dass man das erstmal gar nicht merkt.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    2 Mal editiert, zuletzt von rpi444 (8. März 2021 um 15:35)

  • ... einem Client von Außerhalb nur zugriff auf bestimmte Teile deines internen Netzes gewähren?

    Was ja auch kein Problem ist, ... und Netfilter für dafür nicht benötigt:

    Zitat

    Because all packets sent on the WireGuard interface are encrypted and authenticated, and because there is such a tight coupling between the identity of a peer and the allowed IP address of a peer, system administrators do not need complicated firewall extensions, such as in the case of IPsec, but rather they can simply match on "is it from this IP? on this interface?", and be assured that it is a secure and authentic packet. This greatly simplifies network management and access control, and provides a great deal more assurance that your iptables rules are actually doing what you intended for them to do.

    Quelle: siehe oben.

    Wer es nicht glaubt, der kann es selber testen mit z. B. tcpdump und ping (oder gleichwertig).

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • OK, zur Klärung das berümte Netzwerkbeispiel:

    Ich habe drei VLAN:
    Vlan 10, Finance, 10.0.10.0/24
    Vlan 20, HR, 10.0.20.0/24

    Vlan 30, Server/Printer, 10.0.20.0/24.

    Und ein WG Netz, 10.0.255.0/24

    Jetzt habe ich zwei Mitarbeiter.
    Peter, Controlling, Zugriff auf VLAN 10 und 30
    Mary, Personalerin, Zugriff auf Vlan 20 und 30

    Jetzt lege ich zwei Peer an, einen für Peter und einen für Mary.

    Wenn ich jetzt, auf dem Server die Configs habe und dort das Routing kann ich auf dem Server klären das Peter nur in seine Netze kommt und Mary nur in ihre. Egal was die auf dem Clienten sonst noch so einstellen.

    Bei WG mach eich das nur auf dem Clienten, hier benötige ich eine zusätzliche Instanz welche die Zugriffe regelt, entweder eine Firewall zwischen dem WG und VLAN 10,20,30 oder eben den Netfilter auf dem WG.

    Die Clienten bestimmen was in den Tunnel geroutet wird und das statische Routing auf dem Server leitet weiter.

    Geht auch in Klein, wenn mein Kumpel auf den SMB-Share bei mir zugreifen darf, mein Sohn aber auch auf den Drucker und das NAS.

    Dem Kumpel gebe ich in AllowedIP nur den Samba als /32 mit, meinem Sohn das ganze /24.
    Wenn der Kumpel jetzt in seiner Config das /32 in das /24 ändert hat er auch vollen Zugriff.

    In meinen Augen Broken by Design.
    Die erlaubten IPs gehören in die Server Config nicht in die vom Client.

    EDIT : oder in beide, jedenfalls sollte der Server noch mal prüfen ob die DST IP erlaubt ist.

    Noch ein EDIT :

    OK, nach der lektüre des Link von rpi444 geht es wohl auf dem Server ?
    Bei Peter [peer]:
    allowedIPs = 10.0.255.3/32,10.0.10.0/24,10.0.30.0/24

    Bei Mary [peer] dann :
    allowedIPs = 10.0.255.4/32,10.0.20.0/24,10.0.30.0/24


    Richtig verstanden ?

    Offizieller Schmier und Schmutzfink des Forum.
    Warum einfach wenn's auch schwer geht ?

    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.

    4 Mal editiert, zuletzt von Der_Imperator (8. März 2021 um 17:34)

  • Wie ist jetzt auf den zwei Peers (Clients), die Zeile mit "AllowedIPs" und die Ausgabe von:

    Code
    route -n

    ?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • OK, grade mal getestet.

    AllowedIPs hat mit allowed mal gar nix zu tun.

    Das setzt nur die Einträge für das Routing.

    Auf dem Server :

     AllowedIPs = 10.9.254.100/32,10.9.9.100/32,10.9.9.110/32


    Also brauche ich in meinem Fall noch etwas was Anhand der src.addr den Traffic erlaubt.
    Ich konfiguriere nachher mal einen zweiten Peer und schaue mir das Routing an.
    Vielleicht wird ein zweites Interface wg1 erstellt, dann könnte man mit den Einträgen wenigstens die Routen so verbiegen das ein zugriff auf ein Netz nicht möglich ist, also aus den "AllowedIPs" ein "DeniedIPs" machen.


    EDIT :

    Pustekuchen :)

    Code
    [Peer]
    PublicKey = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=
    AllowedIPs = 10.9.254.100/32,10.9.9.200/32
    
    
    [Peer]
    PublicKey = bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb=
    AllowedIPs = 10.9.254.101/32,10.9.9.100/32

    In dem Fall würde beiden Clients der Zugriff auf 10.9.9.100 und .200 unmöglich gemacht.
    AllowedIPs ist also nichts weiter wie ein Parameter für das Routing.
    Push-Route wäre eigentlich richtig.

    Offizieller Schmier und Schmutzfink des Forum.
    Warum einfach wenn's auch schwer geht ?

    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.

    4 Mal editiert, zuletzt von Der_Imperator (9. März 2021 um 06:26)

  • AllowedIPs ist also nichts weiter wie ein Parameter für das Routing.

    Das stimmt aber nur, wenn es um das Senden der Daten-Pakete geht. Dort wo die Daten-Pakete empfangen werden, wirkt AllowedIPs wie eine Firewall. Und es ist ja nicht so, dass Daten-Pakete immer nur gesendet bzw. immer nur empfangen werden. D. h. der Eintrag für AllowedIPs ist abwechselnd für routing und für firewalling (Access-Control List) zuständig.

    Die durch den WG-Tunnel gesendeten Daten-Pakete sind nicht nur verschlüsselt, sie sind auch schon authentifiziert mit Hilfe des Eintrags bei "AllowedIPs" (... die IP-Adressen von Sender und Empfänger sind festgelegt und an Hand dieser Festlegung wird entschieden ob die Daten-Pakete in den WG-Tunnel rein dürfen bzw. aus dem WG-Tunnel raus dürfen). Ob man das "AllowedIPs" oder "Push-Route" nennt, ist m. E. egal.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Schon richtig.
    Nützt nur nix wenn der Client das selber ändern kann und somit Zugriff auf Ressourcen bekommt wo er nicht hin soll.
    Ändert der Client z.B. die 10.0.0.100/32 zu 10.0.0.0/8 wird das ganze 10/8 in den Tunnel geroutet.
    Er hat somit nicht nur Zugriff auf den einen Server sondern auf alle 10.x.x.x Netze dahinter.
    Und das mit einer Änderung auf dem Client !!!
    Mag für ein Site2Site OK sein wo der Admin zugriff auf beide Peers hat, bei einem VPN für Roadwarrior nicht.


    Die Allowed IPs auf dem Server setzen auch nur Routen in den Tunnel. Also nix mit ACL.
    Siehe mein Beispiel oben.
    Du kannst nicht den einen Peer die 10.10.10.0/24 erlauben und dem anderen nicht.
    Die ACL ist einfach eine Route welche seinerseits wieder auf das wg0 zeigt.

    Offizieller Schmier und Schmutzfink des Forum.
    Warum einfach wenn's auch schwer geht ?

    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.

    Einmal editiert, zuletzt von Der_Imperator (9. März 2021 um 13:01)

  • Nochmal, für in den Tunnel gehende Pakete ist es Routing, für aus dem Tunnel kommende Pakete ist es ACL und das gilt für alle Konstellationen (Point-to-Point, Site-to-Site, Point-to-Site, Site-to-Point).

    Es nutzt dem Client gar nichts, wenn er bei seinen Allowed-IPs 10.0.0.0/8 einträgt, wenn die andere Seite (Client und/oder Server) mit Hilfe von AllowedIPs, den Client mit 10.0.0.0/8 ausgeschlossen/ausgesperrt hat. Wenn es eine Konstellation mit Server (statt peer-to-peer) ist, muss der Server diesen Client auch nur mit seiner wg-IP-Adresse (und seinem pub-Key) zulassen, damit alle anderen Clients am Server (die das wollen), den "Angreifer" via AllowedIPs aussperren können.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Also, ich habe dem Clienten nur diese 3 Adressen erlaubt.

    Im Client habe ich Manuel AllowedIPs auf 0.0.0.0/0 geändert.

    Warum kann er dann den Server pingen wenn ihm der gar nicht erlaubt ist ?

    Und nein, ich bin nicht zu Hause in meinem WLAN, ich sitze auf der Arbeit im Gästenetz.

    Server config:


    Client :

    Offizieller Schmier und Schmutzfink des Forum.
    Warum einfach wenn's auch schwer geht ?

    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.

  • Also, ich habe dem Clienten nur diese 3 Adressen erlaubt.

    Im Client habe ich Manuel AllowedIPs auf 0.0.0.0/0 geändert.

    Warum kann er dann den Server pingen wenn ihm der gar nicht erlaubt ist ?

    Und nein, ich bin nicht zu Hause in meinem WLAN, ich sitze auf der Arbeit im Gästenetz.

    Server config:

    Nein, ... dem Client hast Du mit 0.0.0.0/0, Alles (d. h. nicht nur ausgehend, sondern auch ankommend) erlaubt. In der Server-config hast Du festgelegt, dass der Client den Server (und weitere IP-Adressen, wenn der Server forwarding/Weiterleitung macht) mit einer der Source-IP-Adressen 10.9.254.100 oder 10.9.9.1 oder 10.9.9.10 erreichen kann. Deshalb die Frage, warum soll der Client (peer) den Server (& Co.) auf einer IP-Adresse 10.9.9.9 nicht erreichen können?

    Konfiguriere mal im Server für den Peer (Client):

    Code
    AllowedIPs = 10.9.254.100/32

    und mach dann erneut den Ping.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (9. März 2021 um 15:03)

  • OK, das habe ich jetzt soweit verstanden.

    AllowedIPs beziehen sich nur auf die IP Adressen im Tunnel.

    Ich habe jetzt auf dem Server :

    Code
    [Peer]
    # NB TEST
    PublicKey = <key>
    AllowedIPs = 10.9.254.101/32

    und auf dem Client

    Code
    [Interface]
    PrivateKey = 
    Address = 10.9.254.101/32
    DNS = 10.9.9.1
    
    [Peer]
    PublicKey = 
    AllowedIPs = 0.0.0.0/0
    Endpoint = 

    Ich habe Zugriff auf alle Subnetze hinter dem WG Server.

    Fazit :
    Die AllowedIPs sind für den Tunnel und keine ACL was der Remote-Peer darf und was nicht.
    Das geht definitiv nur über eine Externe Firewall oder mit dem Netfilter.

    Dazu kommt das der Wireguard auf meinem WIn10 Notebook sich nicht als User starten lässt sondern nur von Mitgliedern der Admin Gruppe.

    Ein weiteres No-Go für mich.

    Danke für deine Hilfe.

    Offizieller Schmier und Schmutzfink des Forum.
    Warum einfach wenn's auch schwer geht ?

    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.

  • Ich habe Zugriff auf alle Subnetze hinter dem WG Server.

    Fazit :
    Die AllowedIPs sind für den Tunnel und keine ACL was der Remote-Peer darf und was nicht.

    Hast Du mit _dieser Konfiguration_, Zugriff via WG-Tunnel auf alle Subnetze hinter der WG-Server?

    BTW: Wir sprechen von Anfang an, hier nur über den WG-Tunnel. Denn was soll eine WG-Konfiguration mit einem weiteren/anderen/zusätzlichen/parallelem Routing (andere Interfaces/gateways) zu tun haben?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Ja, ich hatte einen Denkfehler.

    Ich hatte tatsächlich die wage Hoffnung das "AllowedIPs" auf dem Server die Netze des Clienten einschränkt auf welche er Zugriff hat.

    Thema ist erledigt.

    Danke.

    Offizieller Schmier und Schmutzfink des Forum.
    Warum einfach wenn's auch schwer geht ?

    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!