☰

Ubuntu 22.04 Netns mit Veth, das mit der Bridge verbunden ist, kann das Gateway nicht anpingen

tag-icon • tag-icon networking vpn ethernet network-bridge systemd-networkd
Ubuntu 22.04 Netns mit Veth, das mit der Bridge verbunden ist, kann das Gateway nicht anpingen

Hey Leute, wahrscheinlich habe ich einfach nur etwas Dummes übersehen, aber ich habe Probleme, einen Net Namespace für mein VPN einzurichten. Das Seltsame ist, dass dieses Skript/Setup funktioniert hat und in den letzten Wochen plötzlich nicht mehr funktioniert hat.

Ich habe eine einzelne Ethernet-Schnittstelle auf dem Server mit einem statischen IP-Satz, den ich für meinen gesamten normalen Datenverkehr verwenden möchte. Ich verwende dann eine Bridge als Master und verbinde das VPN über ein virtuelles Ethernet mit derselben Bridge. Aus irgendeinem Grund kann die Schnittstelle meines VPN erfolgreich auf ARP-Anfragen antworten, scheint aber nicht in der Lage zu sein, mein Gateway anzupingen und kann daher keine Verbindung zum Internet herstellen. Ich habe das Gefühl, dass dies ein Routing-Problem sein könnte, aber ich kann es nicht herausfinden.

Netplan

# Let NetworkManager manage all devices on this system
network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      dhcp4: false
      addresses:
        - 192.168.0.54/24

  bridges:
    br0:
      interfaces:
        - enp3s0
      routes:
      - to: default
        via: 192.168.0.1
      - to: 192.168.0.0/24
      nameservers:
        addresses: [1.1.1.1, 8.8.8.8]

Skript zum Einrichten des VPN-Net-Namespace:

ip link add vpn0 type veth peer name vpn1

ip link set dev vpn0 master br0

ip netns add vpn

ip link set vpn1 netns vpn

ip link set dev vpn0 promisc on
ip link set vpn0 up

ip netns exec vpn ip link set lo up
ip netns exec vpn ip link set vpn1 up

ip netns exec vpn ip address add 192.168.0.53/24 dev vpn1
ip netns exec vpn ip route add default via 192.168.0.1 dev vpn1

VPN-Adresse/Routen

root@sam-server:~# ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
5: vpn1@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 06:9e:19:5a:a4:a5 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.0.53/24 scope global vpn1
       valid_lft forever preferred_lft forever
    inet6 fe80::49e:19ff:fe5a:a4a5/64 scope link
       valid_lft forever preferred_lft forever
root@sam-server:~# ip route
default via 192.168.0.1 dev vpn1
192.168.0.0/24 dev vpn1 proto kernel scope link src 192.168.0.53

Normale Adresse/Routen

root@sam-server:~# ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
    link/ether 88:d7:f6:78:91:72 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.54/24 brd 192.168.0.255 scope global enp3s0
       valid_lft forever preferred_lft forever
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether e6:3d:5a:ce:a9:fb brd ff:ff:ff:ff:ff:ff
    inet6 fe80::e43d:5aff:fece:a9fb/64 scope link
       valid_lft forever preferred_lft forever
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:19:80:3c:94 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
6: vpn0@if5: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP group default qlen 1000
    link/ether 66:2c:f9:35:3d:0e brd ff:ff:ff:ff:ff:ff link-netns vpn
    inet6 fe80::642c:f9ff:fe35:3d0e/64 scope link
       valid_lft forever preferred_lft forever
root@sam-server:~# ip route
default via 192.168.0.1 dev br0 proto static onlink
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.0.0/24 dev br0 proto static scope link
192.168.0.0/24 dev enp3s0 proto kernel scope link src 192.168.0.54

Pingen vom VPN-Namensraum(Arp scheint sich aufzulösen, aber ich kann das Gateway nicht anpingen)

root@sam-server:~# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
^C
--- 192.168.0.1 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3066ms

root@sam-server:~# ping 192.168.0.54
PING 192.168.0.54 (192.168.0.54) 56(84) bytes of data.
64 bytes from 192.168.0.54: icmp_seq=1 ttl=64 time=0.037 ms
64 bytes from 192.168.0.54: icmp_seq=2 ttl=64 time=0.052 ms
64 bytes from 192.168.0.54: icmp_seq=3 ttl=64 time=0.052 ms
^C
--- 192.168.0.54 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2031ms
rtt min/avg/max/mdev = 0.037/0.047/0.052/0.007 ms
root@sam-server:~# arp
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.0.1              ether   b0:95:75:8c:fe:80   C                     vpn1
192.168.0.54             ether   e6:3d:5a:ce:a9:fb   C                     vpn1
root@sam-server:~#

Hoffentlich sind das genug Informationen. Ich kann bei Bedarf mehr posten.

Antwort1

Versuchen Sie, die Mac-Adresse der Schnittstelle wie hier vorgeschlagen hinzuzufügenUbuntu 22.04 Bridging mit Netplan funktioniert nicht

   # Let NetworkManager manage all devices on this system
network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      dhcp4: false
      addresses:
        - 192.168.0.54/24

  bridges:
    br0:
      interfaces:
        - enp3s0
      routes:
      - to: default
        via: 192.168.0.1
      - to: 192.168.0.0/24
      nameservers:
        addresses: [1.1.1.1, 8.8.8.8]
      macaddress: 88:d7:f6:78:91:72

Antwort2

Ich habe eine Antwort auf mein Problem gefunden. Es stellte sich als etwas ganz Einfaches heraus. Im Grunde hatte ich vor zwei Wochen installiert Docker. Ich war mir dessen nicht bewusst, aber Docker bringt Dinge durcheinander iptables.

root@sam-server:~# iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy DROP) <----------- PROBLEM IS HERE
target     prot opt source               destination         
DOCKER-USER  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain DOCKER (1 references)
target     prot opt source               destination         

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination         
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            
RETURN     all  --  anywhere             anywhere            

Chain DOCKER-ISOLATION-STAGE-2 (1 references)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere            
RETURN     all  --  anywhere             anywhere            

Chain DOCKER-USER (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere

Da Docker automatisch einstellt, FORWARDwurden DROPmeine Pakete nicht an die Schnittstelle weitergeleitet. Ich gehe davon aus, dass ARPes funktionierte, da es nicht von iptables beeinflusst wird.

Die Lösung bestand lediglich darin, die Richtlinie so zurückzusetzen, dass sie Folgendes akzeptiert:iptables --policy FORWARD ACCCEPT

verwandte Informationen