Wireguard Allowed-IPs

Wenn es "irgentwie" nicht geht wird wohl irgentwie was anderes kaputt sein.
Funzen die Regeln auf einem "normalen" Interface?

Wenn man auf einem bestimmten Interface Adressen filtern will ist es ziemlich unschlau Regeln zu bauen die das Interface nicht als Bedingung drin haben.

Und warum reicht dir RPF nicht?
 
entest schrieb:
Geht nur irgendwie nicht. Hab das Interface auch weggelassen:

iptables --append FORWARD --src 10.252.1.0 --dst 192.168.1.2 --jump DROP
iptables --append INPUT--src 10.252.1.0 --dst 192.168.1.2 --jump DROP
Hast du denn mittels tcpdump mal geprüft ob diese Regeln überhaupt etwas zu regeln haben? Es ist höchst unwahrscheinlich, dass diese Regeln "nicht funktionieren", sondern eher so, dass sie mutmaßlich falsch sind und sie gar nicht erst getriggert werden. Mach zum Beispiel einen Dauerping und schau dir an was tcpdump dazu sagt.
 
@foofoobar . Ehrlich gesagt weiß ich nicht was RPF (hier) tun soll. Ich möchte nach den Wireguard-IPs filtern ggfls. nach Ports ("User" x darf auf 192.168.1.1 nur mit 3389 TCP, "User" 2 auf 192.168.1.2 nur SSH usw.). Sorry, hab wenig direkte Erfahrung mit Linux an sich, das machen die Firewallboxen meist unten drunter. Da setze ich PolicyRoutes und Zonen und gut ist.

Ich habe die Regel natürlich auch mit dem Wireguardinterface gesetzt, ändert aber nix das der Ping einfach durchgeht. Ich habe es probiert in dem ich direkt auf dem WG-Server mal das HTTPS für die WG-UI geblockt hatte und es klappte für die lokalen Rechner in dem Netz. Ob ich es per ufw oder direkt über iptables mache ist egal.

@Raijin

Ich sehe im tcpdump nur die öffentliche IP des "Clients" der zugreift, die Wireguard-Ips sehe ich gar nicht. Das ist ja das merkwürdige. KA wie Linux hier dieses Zwischennetz routet.

Firewall mit Portforwarding > Debian mit Wireguard (192.168.1.10) > Server (192.168.1.1) .

Danke trotzdem an alle, ich weiß sowas kann man nicht "mal so" lösen, meine Fragen bezüglich der Allowed IPs ist aber beantwortet. Schade das Wireguard hier keine direkte Einschränkung "serverseitig" implementiert aber sie bieten ja auch keine User-Authentifizierung als solches an, wie es zb OVPN oder so macht. Vielleicht versuche ich hier wirklich eine Clientlösung zu basteln wofür WG nicht gedacht war.

Danke und schöne Grüße!
 
Zeig mal die die komplette Konfig und auch die Counter von iptables vor und nach deinen Tests, die Tests bitte auch nachvollziehbar beschreiben. Und ein Bild vom Netz sagt mehr als tausend Worte.

Bzgl. RPF: Das du auch Ports filtern willst hast du bisher nicht erwähnt.
Und schau dir mal die Option "-i" von tcpdump an.
 
Hmm, ich habs nochmal mit ufw probiert:

Code:
 ufw status numbered
Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22                         ALLOW IN    Anywhere
[ 2] 51820                      ALLOW IN    Anywhere
[ 3] 443                        ALLOW IN    Anywhere
[ 4] 192.168.1.2               DENY IN     10.252.1.1
[ 5] 192.168.1.2               DENY OUT    10.252.1.1                 (out)
[ 6] 22 (v6)                    ALLOW IN    Anywhere (v6)
[ 7] 51820 (v6)                 ALLOW IN    Anywhere (v6)
[ 8] 443 (v6)                   ALLOW IN    Anywhere (v6)
Pinge ich von meinem Client sehe ich die Antworten.
Code:
 tcpdump -i wg0
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
13:37:08.879344 IP 10.252.1.1 > 192.168.1.2: ICMP echo request, id 1, seq 18, length 40
13:37:08.879724 IP 192.168.1.2 > 10.252.1.1: ICMP echo reply, id 1, seq 18, length 40

geht einfach durch. Bei iptables auch, mit oder ohne wg0 Interface.

edit: die VM hat nur eine Netzwerkkarte, sollte aber kein Problem sein, oder?
 
Vergiss ufw.
Du musst wissen welche Regeln tatsächlich aktiv sind, ohne dieses Wissen wirst du nur Bullshit erzeugen.
Und mit den Countern kann auch in Grenzen "debuggen".

iptables -v -L -n
iptables -v -L -n -t nat
man iptables
 
Zuletzt bearbeitet:
Zurück
Oben