Instradamento dai contenitori della finestra mobile utilizzando un'interfaccia di rete fisica e un gateway predefiniti diversi

Informazioni di base

Ho un server con due interfacce di rete che esegue Docker. Docker, come alcuni strumenti di virtualizzazione, crea un'interfaccia bridge Linux chiamata docker0. Questa interfaccia è configurata per impostazione predefinita con un IP di 172.17.42.1e tutti i contenitori Docker comunicano con questa interfaccia come gateway e vengono assegnati indirizzi IP nello stesso /16intervallo. A quanto ho capito, tutto il traffico di rete da / verso i container passa attraverso un NAT, quindi sembra in uscita da cui proviene 172.17.42.1e in entrata viene inviato a 172.17.42.1.

La mia configurazione è simile al seguente:

                                          +------------+        /
                                          |            |       |
                            +-------------+ Gateway 1  +-------
                            |             | 10.1.1.1   |     /
                     +------+-------+     +------------+    |
                     |     eth0     |                      /
                     |   10.1.1.2   |                      |
                     |              |                      |
                     | DOCKER HOST  |                      |
                     |              |                      | Internet
                     |   docker0    |                      |
                     |   (bridge)   |                      |
                     |  172.17.42.1 |                      |
                     |              |                      |
                     |     eth1     |                      |
                     |  192.168.1.2 |                      \
                     +------+-------+     +------------+    |
                            |             |            |     \
                            +-------------+ Gateway 2  +-------
                                          | 192.168.1.1|       |
                                          +------------+            

Il problema

Voglio instradare tutto il traffico da / verso qualsiasi contenitore Docker dalla seconda eth1 192.168.1.2interfaccia a un gateway predefinito di 192.168.1.1, mentre tutto il traffico da / verso la macchina host esce eth0 10.1.1.2dall'interfaccia verso un gateway predefinito di 10.1.1.1. Finora ho provato una varietà di cose senza risultati, ma l'unica cosa che penso sia la più vicina da correggere è usare iproute2 in questo modo:

# Create a new routing table just for docker
echo "1 docker" >> /etc/iproute2/rt_tables

# Add a rule stating any traffic from the docker0 bridge interface should use 
# the newly added docker routing table
ip rule add from 172.17.42.1 table docker

# Add a route to the newly added docker routing table that dictates all traffic
# go out the 192.168.1.2 interface on eth1
ip route add default via 192.168.1.2 dev eth1 table docker

# Flush the route cache
ip route flush cache

# Restart the Docker daemon so it uses the correct network settings
# Note, I do this as I found Docker containers often won't be able
# to connect out if any changes to the network are made while it's     
# running
/etc/init.d/docker restart

Quando apro un contenitore non riesco più a eseguire il ping da esso dopo averlo fatto. Non sono sicuro che le interfacce bridge siano gestite allo stesso modo delle interfacce fisiche per questo tipo di instradamento, e voglio solo un controllo di integrità e qualsiasi suggerimento su come potrei realizzare questo compito apparentemente semplice.

Potrebbe essere necessario cercare di più anche sulla configurazione di iptables. Docker maschera tutto il traffico proveniente dalla sottorete del contenitore, ad esempio 172.17.0.0/16, su 0.0.0.0. Se corri iptables -L -n -t nat, puoi vedere la catena POSTROUTING sotto la tabella nat che fa questo -

Catena POSTROUTING (politica ACCETTA)
destinazione di destinazione opt opt ​​prot
Tutti MASQUERADE - 172.17.0.0/16 0.0.0.0/0

Ora puoi rimuovere questa regola e sostituirla con una regola che maschera tutto il traffico proveniente dalla sottorete dei container verso l'IP della tua seconda interfaccia - 192.168.1.2, poiché è quello che desideri. La regola di eliminazione sarà, supponendo che sia la prima regola nella catena POSTROUTING -

iptables -t nat -D POSTROUTING 1

Quindi aggiungi questa regola personalizzata:

iptables -t nat -A POSTROUTING -s 172.17.0.0/16 -j SNAT - to-source 192.168.1.2

Un amico e io ci siamo imbattuti in questo esatto problema in cui volevamo che la docker supportasse più interfacce di rete per soddisfare le richieste. In particolare, stavamo lavorando con il servizio AWS EC2 in cui stavamo anche collegando / configurando / mettendo in evidenza le interfacce aggiuntive. In questo progetto , c'è molto di più di quello che ti serve, quindi cercherò di includere solo ciò di cui hai bisogno qui.

Innanzitutto, abbiamo creato una tabella di route separata per eth1:

ip route add default via 192.168.1.2 dev eth1 table 1001

Successivamente abbiamo configurato la tabella mangle per impostare alcuni segni di connessione provenienti da eth1:

iptables -t mangle -A PREROUTING -i eth1 -j MARK --set-xmark 0x1001/0xffffffff
iptables -t mangle -A PREROUTING -i eth1 -j CONNMARK --save-mark --nfmask 0xffffffff --ctmask 0xffffffff

Infine aggiungiamo questa regola per tutti fwmarks di utilizzare la nuova tabella che abbiamo creato.

ip rule add from all fwmark 0x1001 lookup 1001

Il iptablescomando seguente ripristina il segno di connessione e quindi consente alla regola di routing di utilizzare la tabella di routing corretta.

iptables -w -t mangle -A PREROUTING -i docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff

Credo che questo sia tutto ciò che è necessario dal nostro esempio più complesso in cui (come ho detto) il nostro progetto stava collegando / configurando / aprendo l' eth1interfaccia all'avvio.

Ora questo esempio non impedirebbe alle connessioni di eth0gestire le richieste fino a, docker0ma credo che tu possa aggiungere una regola di routing per impedirlo.

La mascherata non è del 172.17.42.1 ma piuttosto

 -A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE

Ciò significa che questa regola non funzionerà correttamente.

ip rule add from 172.17.42.1 table docker

Prova invece

ip rule add from 172.17.0.0/16 table docker