私の初期状態は次のとおりです。
- サブネット192.168.15.0/24の有線および無線コンピュータの組み合わせにDHCPアドレスを配布する住宅用ゲートウェイを備えた「一般」ホームネットワーク。
- WindowsとLinuxのゲストが混在するLinux(Ubuntu 18.04.3)仮想マシンホスト。この VM ホストは、単一のブリッジ インターフェイスを使用して、VM ゲスト インターフェイスを 192.168.15.x ネットワークに直接ブリッジします。ここで、eno1 と ens2 は VM ホストをプライマリネットワークに接続し、そのブリッジドメインを別の物理スイッチに「拡張」する物理イーサネットポートで、vnetX インターフェイスは VM ゲストシステムのインターフェイスです.
lwobker@lwobker-vms:~$ brctl show bridge name bridge id STP enabled interfaces bridge1 8000.0017b60066e8 no eno1 # goes to router/gateway ens2 # extends the subnet to other machines vnet0 # VM guest #1 vnet1 # VM guest #2 docker0 8000.0242bd3d4632 no virbr0 8000.52540096aaf5 yes virbr0-nic
これらすべては私が望む方法で動作します。ローカル有線、ワイヤレス、およびVMゲストクライアントはすべて、デフォルトの192.168.15.1 res-gateway/routerからDHCPアドレスを取得できます。そのうちのいくつかはDHCPサーバー側で予約/静的で、一部はDHCPサーバー側で予約/静的です。ダイナミックです。とにかく - すべてが大丈夫です...前までは...
ドッカーをインストールしました。私はコンテナでUbiquity / UnifiワイヤレスAPコントローラソフトウェアを実行するためにこれをやっています。ただし、Dockerのインストール中に(より正確にはDockerネットワークの変更であると確信しています)、VMホストブリッジインターフェイスの背後にあるすべてのエントリに対してDHCPがハングしました。確かに:
- VMホストの背後にない有線および無線クライアントは通常、192.168.15.1からDHCPアドレス(予約および動的)を受信します。
- すべての座っている機械後ろにVMホストブリッジはDHCPアドレスを受信しなくなりました。これには、VM 自体の仮想マシンゲストインスタンスだけでなく、インターフェイス ens2 を介して物理的に接続されたマシンも含まれます。
- 重要なもの:IPv6アドレス指定するこの新しいDockerfied VMホストの背後にあるコンピュータではまだ実行でき、ターゲットがルーティング可能なv6アドレスである限り、そのコンピュータは引き続きインターネットに正常にアクセスできます。
私は明らかにdockerに初めて触れ、Linuxネットワークとブリッジングについてよく知っていますが、これは私の能力を超えています。数回起動したが、tcpdump
iptablesに関連している可能性が最も高いという内容を読んでみると、DHCPを見ることができます。 Dockerをインストールする前の出力はありませんが、iptables --list
明らかにいくつかのエントリが追加されました。 ;-) 以下にリストしました。私が確信できることは関連しており、特に重要な項目に注釈を付けようとします。助ける? ! ? ! !
lwobker@lwobker-vms:~$ brctl showmacs bridge1 | uniq
port no mac addr is local? ageing timer
1 18:1d:ea:8a:86:e9 no 49.83
1 44:61:32:d0:43:02 no 117.27
1 44:61:32:fb:4d:7b no 117.27
1 60:6d:c7:1a:8f:e1 no 4.47
1 78:f2:9e:90:4c:a1 no 1.21
1 7c:2e:bd:9c:4a:4a no 0.00
1 80:4a:14:ec:5a:ea no 95.33
1 80:4a:14:f3:d8:8c no 71.62
1 90:70:65:13:b7:16 no 117.16
1 a0:cc:2b:ff:a4:b4 no 0.70
1 ac:1f:6b:b3:ad:fa yes 0.00
1 ac:1f:6b:b7:d2:44 no 286.56
1 b4:fb:e4:d6:e2:35 no 2.54
1 b8:27:eb:f9:c6:fe no 117.18
1 d8:31:34:f3:2c:69 no 62.38
1 ec:11:27:58:a8:0d no 0.22
2 00:17:b6:00:66:e8 yes 0.00
2 00:30:93:10:05:8e no 3.61 >> physical machine behind intf ens2
3 52:54:00:ed:c9:fc no 0.67 >> linux VM guest
3 fe:54:00:ed:c9:fc yes 0.00
4 52:54:00:d9:2d:b0 no 1.29 >> windows VM guest
4 fe:54:00:d9:2d:b0 yes 0.00
現在のiptables出力:
lwobker@lwobker-vms:/storage/unifi$ sudo iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:bootps
ACCEPT tcp -- anywhere anywhere tcp dpt:bootps
ACCEPT udp -- anywhere anywhere multiport dports mdns
ACCEPT tcp -- anywhere anywhere multiport dports 4000
Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere 192.168.122.0/24 ctstate RELATED,ESTABLISHED
ACCEPT all -- 192.168.122.0/24 anywhere
ACCEPT all -- anywhere anywhere
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
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
ACCEPT udp -- anywhere anywhere udp dpt:bootpc
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
lwobker@lwobker-vms:/storage/unifi$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
be342a77a105 jacobalberty/unifi:stable "/usr/local/bin/dock…" 23 hours ago Up 5 hours (healthy) unifi
ブリッジドッカーネットワークチェック出力...
lwobker@lwobker-vms:/storage/unifi$ docker network inspect 20d74e3d7efc
[
{
"Name": "bridge",
"Id": "20d74e3d7efc41320c054dbd4fde76808a7c0e021e737e22cfceebefacb24b8c",
"Created": "2019-10-15T12:36:22.059240054-04:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.17.0.0/16",
"Gateway": "172.17.0.1"
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {},
"Options": {
"com.docker.network.bridge.default_bridge": "true",
"com.docker.network.bridge.enable_icc": "true",
"com.docker.network.bridge.enable_ip_masquerade": "true",
"com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
"com.docker.network.bridge.name": "docker0",
"com.docker.network.driver.mtu": "1500"
},
"Labels": {}
}
]
VMホストifconfig出力...
lwobker@lwobker-vms:~$ ifconfig | egrep -v 'errors|0.0 B|device mem'
bridge1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.15.150 netmask 255.255.255.0 broadcast 192.168.15.255
ether 00:17:b6:00:66:e8 txqueuelen 1000 (Ethernet)
RX packets 105730 bytes 73076273 (73.0 MB)
TX packets 47591 bytes 11607902 (11.6 MB)
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
ether 02:42:bd:3d:46:32 txqueuelen 0 (Ethernet)
eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether ac:1f:6b:b3:ad:fa txqueuelen 1000 (Ethernet)
RX packets 479110 bytes 451330614 (451.3 MB)
TX packets 352901 bytes 284906323 (284.9 MB)
eno2: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether ac:1f:6b:b3:ad:fb txqueuelen 1000 (Ethernet)
eno2:avahi: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 169.254.11.170 netmask 255.255.0.0 broadcast 169.254.255.255
ether ac:1f:6b:b3:ad:fb txqueuelen 1000 (Ethernet)
ens2: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 00:17:b6:00:66:e8 txqueuelen 1000 (Ethernet)
RX packets 375663 bytes 281196261 (281.1 MB)
TX packets 292663 bytes 270964344 (270.9 MB)
ens2:avahi: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 169.254.8.164 netmask 255.255.0.0 broadcast 169.254.255.255
ether 00:17:b6:00:66:e8 txqueuelen 1000 (Ethernet)
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 92697 bytes 34802204 (34.8 MB)
TX packets 92697 bytes 34802204 (34.8 MB)
virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255
ether 52:54:00:96:aa:f5 txqueuelen 1000 (Ethernet)
virbr0-nic: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 52:54:00:96:aa:f5 txqueuelen 1000 (Ethernet)
vnet0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether fe:54:00:ed:c9:fc txqueuelen 1000 (Ethernet)
RX packets 4563 bytes 509949 (509.9 KB)
TX packets 28463 bytes 2796658 (2.7 MB)
vnet1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether fe:54:00:d9:2d:b0 txqueuelen 1000 (Ethernet)
RX packets 50067 bytes 5253268 (5.2 MB)
TX packets 82339 bytes 105281318 (105.2 MB)
vnet0:avahi: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 169.254.12.44 netmask 255.255.0.0 broadcast 169.254.255.255
ether fe:54:00:ed:c9:fc txqueuelen 1000 (Ethernet)
vnet1:avahi: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 169.254.8.4 netmask 255.255.0.0 broadcast 169.254.255.255
ether fe:54:00:d9:2d:b0 txqueuelen 1000 (Ethernet)
答え1
クイックフィックス:
iptables -t filter -P FORWARD ACCEPT
より良い修正:
iptables -A FORWARD -p udp --sport 68 --dport 67 -m conntrack --ctstate NEW -j ACCEPT
答え2
迅速かつ詳細な修正を提供していただき、「ありがとうございます」と言いたくて参加しました。私は彼の答えに直接コメントするのに十分な評判を持っていません。数え切れないほどデバッグし、髪を抜いた後に助けてくれた@Stuart Cardallに感謝します。
いくつかの追加結果を追加する必要があります。最初の提案コマンドは迅速であるだけでなく、一時的な修正でもあります。 docker が開始される前にルールが適用されると、docker が開始された直後に再び DENY に切り替わります。
2番目のコマンドの場合、これは必要なコマンドの1つですが、パケットを別の方向に転送するコマンドも必要です。だから結局私は使った
iptables -A FORWARD -p udp --sport 68 --dport 67 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -p udp --sport 67 --dport 68 -m conntrack --ctstate NEW -j ACCEPT
これらの規則とあらゆる種類のiptables永続性(ArchLinuxの/ etc / iptables / iptables.rules)を使用すると、VPNクライアントがネットワークルーターからアドレスを取得できるようになります。