La rete / bridge di Alpine Linux veth non ha Internet

Question

Ho provato a seguire più guide per configurare una coppia veth per 2 spazi dei nomi che possono comunicare tra loro su alpine linux. Finora ho la comunicazione tra gli spazi dei nomi funzionanti ma nessuno dei due spazi dei nomi può connettersi / eseguire il ping a qualsiasi IP / URL esterno.

Ecco la configurazione delle guide che uso esattamente:

  ip netns add namespace1
  ip netns add namespace2
  ip netns exec namespace1 ip address show
  ip link add veth1 type veth peer name br-veth1
  ip link add veth2 type veth peer name br-veth2
  ip link set veth1 netns namespace1
  ip link set veth2 netns namespace2
  ip netns exec namespace1 ip address show
  ip netns exec namespace1 ip addr add 192.168.1.11/24 dev veth1
  ip netns exec namespace1 ip address show
  ip netns exec namespace2 ip addr add 192.168.1.12/24 dev veth2
  
  # Create the bridge device naming it `br1`
  # and set it up:
  ip link add name br1 type bridge
  ip link set br1 up
  ip link | grep br1
  
  # Set the bridge veths from the default
  # namespace up.
  ip link set br-veth1 up
  ip link set br-veth2 up
  ip netns exec namespace1 ip link set veth1 up
  ip netns exec namespace2 ip link set veth2 up
  
  # Add the br-veth* interfaces to the bridge
  # by setting the bridge device as their master.
  ip link set br-veth1 master br1
  ip link set br-veth2 master br1
  bridge link show br1
  ip addr add 192.168.1.10/24 brd + dev br1
  ip -all netns exec ip route add default via 192.168.1.10
  iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE

Ho anche verificato che /etc/sysctl.conf contenga

net.ipv4.ip_forward = 1

e ho eseguito anche questo comando per ogni evenienza

sysctl -w net.ipv4.ip_forward=1

il mio resolv.conf contiene:

nameserver 8.8.8.8

quando corro

ip netns exec namespace1 ip route

Ottengo i risultati:

192.168.1.0/24 dev veth1 proto kernel scope link src 192.168.1.11

Se eseguo un normale elenco di percorsi IP ottengo:

192.168.56.0 eth0 proto kernel scope link src 192.168.56.217
192.168.1.0/24 dev br1 proto kernel scope link src 192.168.1.10

Non ho idea del motivo per cui la configurazione di cui sopra non funzionerà poiché la maggior parte delle guide sembra suggerire che l'host e gli spazi dei nomi dovrebbero essere in grado di comunicare dopo aver eseguito MASQUERADE e aver impostato il percorso predefinito degli spazi dei nomi, tuttavia il networking non è il mio campo di studio principale, quindi qualsiasi suggerimento lo farebbe essere estremamente utile. Se mancano delle informazioni, non esitare a lasciare un commento e cercherò di fornirle nel caso mi sia perso qualcosa.

Answer 1

Ho applicato la tua configurazione alla lettera e funziona.

Devi aver fatto un errore di battitura da qualche parte o non hai seguito esattamente quello che hai scritto nella tua domanda.

Due osservazioni:

bridge link show br1

è una sintassi non valida. man bridgeè stato modificato nelle versioni recenti probabilmente perché era un errore comune:

bridge link show- elenca la configurazione delle porte per tutti i bridge . Questo comando visualizza la configurazione della porta e i flag per tutti i bridge .

Per visualizzare la configurazione della porta e i flag per un bridge specifico, utilizzare il ip link show master <bridge_device>comando " ".

Quindi dovresti usare invece:

ip link show master br1

o avresti interfacce extra su altri bridge. Ovviamente non importa.

Ciò che conta è che:

  ip -all netns exec ip route add default via 192.168.1.10

avrebbe dovuto impostare percorsi predefiniti negli spazi dei nomi di rete (e ha fatto per me), ma scrivi in ​​seguito:

quando corro

ip netns exec namespace1 ip route

Ottengo i risultati:

192.168.1.0/24 dev veth1 proto kernel scope link src 192.168.1.11

Qui manca il percorso predefinito. Facendo lo stesso sul mio sistema, ottengo, come avresti dovuto ma non hai:

# ip netns exec namespace1 ip route
default via 192.168.1.10 dev veth1 
192.168.1.0/24 dev veth1 proto kernel scope link src 192.168.1.11 

Quindi scopri cosa manca. Riprova i tuoi comandi esattamente come forniti, manualmente, senza modificare alcun ordine, e verifica di ottenere il percorso predefinito. Ad esempio, questo percorso andrebbe perso se l'interfaccia fosse abbassata e poi rialzata (ma non è stata eseguita nello script di OP). Se necessario, non utilizzare -allma ripetere due volte il comando una volta per namespace1una volta namespace2.

---

AGGIORNAMENTO: da ulteriori discussioni nei commenti risulta anche che OP aveva iptables 'con una politica FORWARD impostata come DROP.

Se si intende abilitare il traffico inter-namespace (dovrebbe essere attivato br_netfilter , vedere alla fine) e qualsiasi traffico in uscita dai namespace, si potrebbe semplicemente usare per esempio:

iptables -I FORWARD -i br1 -j ACCEPT

Allo stesso modo per gli spazi dei nomi per raggiungere l'host, se necessario:

iptables -I INPUT -i br1 -j ACCEPT

La sicurezza in questo campo dovrebbe davvero essere ponderata e le regole integrate nella soluzione firewall esistente.

Le cose possono diventare più complesse se altri strumenti come Docker sono in esecuzione perché potrebbe abilitare br_netfilter , come si può vedere nella mia risposta a questa domanda / risposta .