繼前兩篇介紹了tun/tap和veth之後,本篇將介紹Linux下常用的一種虛擬網絡設備,那就是bridge(橋)。
本篇將通過實際的例子來一步一步解釋bridge是如何工作的。
什麼是bridge?
首先,bridge是一個虛擬網絡設備,所以具有網絡設備的特徵,可以配置IP、MAC地址等;其次,bridge是一個虛擬交換機,和物理交換機有類似的功能。
對於普通的網絡設備來說,只有兩端,從一端進來的數據會從另一端出去,如物理網卡從外面網絡中收到的數據會轉發給內核協議棧,而從協議棧過來的數據會轉發到外面的物理網絡中。
而bridge不同,bridge有多個端口,數據可以從任何端口進來,進來之後從哪個口出去和物理交換機的原理差不多,要看mac地址。
創建bridge
我們先用iproute2創建一個bridge:
dev@debian:~$ sudo ip link add name br0 type bridge
dev@debian:~$ sudo ip link set br0 up
當剛創建一個bridge時,它是一個獨立的網絡設備,只有一個端口連着協議棧,其它的端口啥都沒連,這樣的bridge沒有任何實際功能,如下圖所示:
+----------------------------------------------------------------+
| |
| +------------------------------------------------+ |
| | Newwork Protocol Stack | |
| +------------------------------------------------+ |
| ↑ ↑ |
|..............|................................|................|
| ↓ ↓ |
| +----------+ +------------+ |
| | eth0 | | br0 | |
| +----------+ +------------+ |
| 192.168.3.21 ↑ |
| | |
| | |
+--------------|-------------------------------------------------+
↓
Physical Network
這裏假設eth0是我們的物理網卡,IP地址是192.168.3.21,網關是192.168.3.1
將bridge和veth設備相連
創建一對veth設備,並配置上IP
dev@debian:~$ sudo ip link add veth0 type veth peer name veth1
dev@debian:~$ sudo ip addr add 192.168.3.101/24 dev veth0
dev@debian:~$ sudo ip addr add 192.168.3.102/24 dev veth1
dev@debian:~$ sudo ip link set veth0 up
dev@debian:~$ sudo ip link set veth1 up
將veth0連上br0
dev@debian:~$ sudo ip link set dev veth0 master br0
#通過bridge link命令可以看到br0上連接了哪些設備
dev@debian:~$ sudo bridge link
6: veth0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 2
這時候,網絡就變成了這個樣子:
+----------------------------------------------------------------+
| |
| +------------------------------------------------+ |
| | Newwork Protocol Stack | |
| +------------------------------------------------+ |
| ↑ ↑ | ↑ |
|............|............|..............|............|..........|
| ↓ ↓ ↓ ↓ |
| +------+ +--------+ +-------+ +-------+ |
| | .3.21| | | | .3.101| | .3.102| |
| +------+ +--------+ +-------+ +-------+ |
| | eth0 | | br0 |<--->| veth0 | | veth1 | |
| +------+ +--------+ +-------+ +-------+ |
| ↑ ↑ ↑ |
| | | | |
| | +------------+ |
| | |
+------------|---------------------------------------------------+
↓
Physical Network
這裏爲了畫圖方便,省略了IP地址前面的192.168,比如.3.21就表示192.168.3.21
br0和veth0相連之後,發生了幾個變化:
-
br0和veth0之間連接起來了,並且是雙向的通道
-
協議棧和veth0之間變成了單通道,協議棧能發數據給veth0,但veth0從外面收到的數據不會轉發給協議棧
-
br0的mac地址變成了veth0的mac地址
相當於bridge在veth0和協議棧之間插了一腳,在veth0上面做了點小動作,將veth0本來要轉發給協議棧的數據給攔截了,全部轉發給bridge了,同時bridge也可以向veth0發數據。
下面來檢驗一下是不是這樣的:
通過veth0 ping veth1失敗:
dev@debian:~$ ping -c 1 -I veth0 192.168.3.102
PING 192.168.2.1 (192.168.2.1) from 192.168.2.11 veth0: 56(84) bytes of data.
From 192.168.2.11 icmp_seq=1 Destination Host Unreachable
--- 192.168.2.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
爲什麼veth0加入了bridge之後,就ping不通veth2了呢? 先抓包看看:
#由於veth0的arp緩存裏面沒有veth1的mac地址,所以ping之前先發arp請求
#從veth1上抓包來看,veth1收到了arp請求,並且返回了應答
dev@debian:~$ sudo tcpdump -n -i veth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on veth1, link-type EN10MB (Ethernet), capture size 262144 bytes
21:43:48.353509 ARP, Request who-has 192.168.3.102 tell 192.168.3.101, length 28
21:43:48.353518 ARP, Reply 192.168.3.102 is-at 26:58:a2:57:37:e9, length 28
#從veth0上抓包來看,數據包也發出去了,並且也收到了返回
dev@debian:~$ sudo tcpdump -n -i veth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on veth0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:44:09.775392 ARP, Request who-has 192.168.3.102 tell 192.168.3.101, length 28
21:44:09.775400 ARP, Reply 192.168.3.102 is-at 26:58:a2:57:37:e9, length 28
#再看br0上的數據包,發現只有應答
dev@debian:~$ sudo tcpdump -n -i br0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:45:48.225459 ARP, Reply 192.168.3.102 is-at 26:58:a2:57:37:e9, length 28
從上面的抓包可以看出,去和回來的流程都沒有問題,問題就出在veth0收到應答包後沒有給協議棧,而是給了br0,於是協議棧得不到veth1的mac地址,從而通信失敗。
給bridge配上IP
通過上面的分析可以看出,給veth0配置IP沒有意義,因爲就算協議棧傳數據包給veth0,應答包也回不來。這裏我們就將veth0的IP讓給bridge。
dev@debian:~$ sudo ip addr del 192.168.3.101/24 dev veth0
dev@debian:~$ sudo ip addr add 192.168.3.101/24 dev br0
於是網絡變成了這樣子:
+----------------------------------------------------------------+
| |
| +------------------------------------------------+ |
| | Newwork Protocol Stack | |
| +------------------------------------------------+ |
| ↑ ↑ ↑ |
|............|............|...........................|..........|
| ↓ ↓ ↓ |
| +------+ +--------+ +-------+ +-------+ |
| | .3.21| | .3.101 | | | | .3.102| |
| +------+ +--------+ +-------+ +-------+ |
| | eth0 | | br0 |<--->| veth0 | | veth1 | |
| +------+ +--------+ +-------+ +-------+ |
| ↑ ↑ ↑ |
| | | | |
| | +------------+ |
| | |
+------------|---------------------------------------------------+
↓
Physical Network
其實veth0和協議棧之間還是有聯繫的,但由於veth0沒有配置IP,所以協議棧在路由的時候不會將數據包發給veth0,就算強制要求數據包通過veth0發送出去,但由於veth0從另一端收到的數據包只會給br0,所以協議棧還是沒法收到相應的arp應答包,導致通信失敗。
這裏爲了表達更直觀,將協議棧和veth0之間的聯繫去掉了,veth0相當於一根網線。
再通過br0 ping一下veth1,結果成功
dev@debian:~$ ping -c 1 -I br0 192.168.3.102
PING 192.168.3.102 (192.168.3.102) from 192.168.3.101 br0: 56(84) bytes of data.
64 bytes from 192.168.3.102: icmp_seq=1 ttl=64 time=0.121 ms
--- 192.168.3.102 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.121/0.121/0.121/0.000 ms
但ping網關還是失敗,因爲這個bridge上只有兩個網絡設備,分別是192.168.3.101和192.168.3.102,br0不知道192.168.3.1在哪。
dev@debian:~$ ping -c 1 -I br0 192.168.3.1
PING 192.168.3.1 (192.168.3.1) from 192.168.3.101 br0: 56(84) bytes of data.
From 192.168.3.101 icmp_seq=1 Destination Host Unreachable
--- 192.168.3.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
將物理網卡添加到bridge
將eth0添加到br0上:
dev@debian:~$ sudo ip link set dev eth0 master br0
dev@debian:~$ sudo bridge link
2: eth0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 4
6: veth0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 2
br0根本不區分接入進來的是物理設備還是虛擬設備,對它來說都一樣的,都是網絡設備,所以當eth0加入br0之後,落得和上面veth0一樣的下場,從外面網絡收到的數據包將無條件的轉發給br0,自己變成了一根網線。
這時通過eth0來ping網關失敗,但由於br0通過eth0這根網線連上了外面的物理交換機,所以連在br0上的設備都能ping通網關,這裏連上的設備就是veth1和br0自己,veth1是通過veth0這根網線連上去的,而br0可以理解爲自己有一塊自帶的網卡。
#通過eth0來ping網關失敗
dev@debian:~$ ping -c 1 -I eth0 192.168.3.1
PING 192.168.3.1 (192.168.3.1) from 192.168.3.21 eth0: 56(84) bytes of data.
From 192.168.3.21 icmp_seq=1 Destination Host Unreachable
--- 192.168.3.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
#通過br0來ping網關成功
dev@debian:~$ ping -c 1 -I br0 192.168.3.1
PING 192.168.3.1 (192.168.3.1) from 192.168.3.101 br0: 56(84) bytes of data.
64 bytes from 192.168.3.1: icmp_seq=1 ttl=64 time=27.5 ms
--- 192.168.3.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 27.518/27.518/27.518/0.000 ms
#通過veth1來ping網關成功
dev@debian:~$ ping -c 1 -I veth1 192.168.3.1
PING 192.168.3.1 (192.168.3.1) from 192.168.3.102 veth1: 56(84) bytes of data.
64 bytes from 192.168.3.1: icmp_seq=1 ttl=64 time=68.8 ms
--- 192.168.3.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 68.806/68.806/68.806/0.000 ms
由於eth0已經變成了和網線差不多的功能,所以在eth0上配置IP已經沒有什麼意義了,並且還會影響協議棧的路由選擇,比如如果上面ping的時候不指定網卡的話,協議棧有可能優先選擇eth0,導致ping不通,所以這裏需要將eth0上的IP去掉。
#在本人的測試機器上,由於eth0上有IP,
#訪問192.168.3.0/24網段時,會優先選擇eth0
dev@debian:~$ sudo route -v
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.3.1 0.0.0.0 UG 0 0 0 eth0
link-local * 255.255.0.0 U 1000 0 0 eth0
192.168.3.0 * 255.255.255.0 U 0 0 0 eth0
192.168.3.0 * 255.255.255.0 U 0 0 0 veth1
192.168.3.0 * 255.255.255.0 U 0 0 0 br0
#由於eth0已結接入了br0,所有它收到的數據包都會轉發給br0,
#於是協議棧收不到arp應答包,導致ping失敗
dev@debian:~$ ping -c 1 192.168.3.1
PING 192.168.3.1 (192.168.3.1) 56(84) bytes of data.
From 192.168.3.21 icmp_seq=1 Destination Host Unreachable
--- 192.168.3.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
#將eth0上的IP刪除掉
dev@debian:~$ sudo ip addr del 192.168.3.21/24 dev eth0
#再ping一次,成功
dev@debian:~$ ping -c 1 192.168.3.1
PING 192.168.3.1 (192.168.3.1) 56(84) bytes of data.
64 bytes from 192.168.3.1: icmp_seq=1 ttl=64 time=3.91 ms
--- 192.168.3.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 3.916/3.916/3.916/0.000 ms
#這是因爲eth0沒有IP之後,路由表裏面就沒有它了,於是數據包會從veth1出去
dev@debian:~$ sudo route -v
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.3.0 * 255.255.255.0 U 0 0 0 veth1
192.168.3.0 * 255.255.255.0 U 0 0 0 br0
#從這裏也可以看出,由於原來的默認路由走的是eth0,所以當eth0的IP被刪除之後,
#默認路由不見了,想要連接192.168.3.0/24以外的網段的話,需要手動將默認網關加回來
#添加默認網關,然後再ping外網成功
dev@debian:~$ sudo ip route add default via 192.168.3.1
dev@debian:~$ ping -c 1 baidu.com
PING baidu.com (111.13.101.208) 56(84) bytes of data.
64 bytes from 111.13.101.208: icmp_seq=1 ttl=51 time=30.6 ms
--- baidu.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 30.690/30.690/30.690/0.000 ms
經過上面一系列的操作後,網絡變成了這個樣子:
+----------------------------------------------------------------+
| |
| +------------------------------------------------+ |
| | Newwork Protocol Stack | |
| +------------------------------------------------+ |
| ↑ ↑ |
|.........................|...........................|..........|
| ↓ ↓ |
| +------+ +--------+ +-------+ +-------+ |
| | | | .3.101 | | | | .3.102| |
| +------+ +--------+ +-------+ +-------+ |
| | eth0 |<--->| br0 |<--->| veth0 | | veth1 | |
| +------+ +--------+ +-------+ +-------+ |
| ↑ ↑ ↑ |
| | | | |
| | +------------+ |
| | |
+------------|---------------------------------------------------+
↓
Physical Network
上面的操作中有幾點需要注意:
-
如果是在虛擬機上做上述操作,記得打開網卡的混雜模式(不是在Linux裏面,而是在虛擬機的配置上面,如VirtualBox上相應虛擬機的網卡配置項裏面),不然veth1的網絡會不通,因爲eth0不在混雜模式的話,會丟掉目的mac地址是veth1的數據包
-
上面雖然通了,但由於Linux下arp的特性,當協議棧收到外面的arp請求時,不管是問101還是102,都會回覆兩個arp應答,分別包含br0和veth1的mac地址,也即Linux覺得外面發給101和102的數據包從br0和veth1進協議棧都一樣,沒有區別。由於回覆了兩個arp應答,而外面的設備只會用其中的一個,並且具體用哪個會隨着時間發生變化,於是導致一個問題,就是外面回覆給102的數據包可能從101的br0上進來,即通過102 ping外面時,可能在veth1抓不到回覆包,而在br0上能抓到回覆包。說明數據流在交換機那層沒有完全的隔離開,br0和veth1會收到對方的IP應答包。爲了解決上述問題,可以配置rp_filter, arp_filter, arp_ignore, arp_announce等參數,但不建議這麼做,容易出錯,調試比較麻煩。
-
在無線網絡環境中,情況會變得比較複雜,因爲無線網絡需要登錄,登陸後無線路由器只認一個mac地址,所有從這臺機器出去的mac地址都必須是那一個,於是通過無線網卡上網的機器上的所有虛擬機想要上網的話,都必須依賴虛擬機管理軟件(如VirtualBox)將每個虛擬機的網卡mac地址轉成出口的mac地址(即無線網卡的mac地址),數據包回來的時候還要轉回來,所以如果一個IP有兩個ARP應答包的話,有可能導致mac地址的轉換有問題,導致網絡不通,或者有時通有時不通。解決辦法就是將連接進br0的所有設備的mac地址都改成和eth0一樣的mac地址,因爲eth0的mac地址會被虛擬機正常的做轉換。在上面的例子中,執行下面的命令即可:
dev@debian:~$ sudo ip link set dev veth1 down #08:00:27:3b:0d:b9是eth0的mac地址 dev@debian:~$ sudo ip link set dev veth1 address 08:00:27:3b:0d:b9 dev@debian:~$ sudo ip link set dev veth1 up
bridge必須要配置IP嗎?
在我們常見的物理交換機中,有可以配置IP和不能配置IP兩種,不能配置IP的交換機一般通過com口連上去做配置(更簡單的交換機連com口的沒有,不支持任何配置),而能配置IP的交換機可以在配置好IP之後,通過該IP遠程連接上去做配置,從而更方便。
bridge就屬於後一種交換機,自帶虛擬網卡,可以配置IP,該虛擬網卡一端連在bridge上,另一端跟協議棧相連。和物理交換機一樣,bridge的工作不依賴於該虛擬網卡,但bridge工作不代表機器能連上網,要看組網方式。
刪除br0上的IP:
dev@debian:~$ sudo ip addr del 192.168.3.101/24 dev br0
於是網絡變成了這樣子,相當於br0的一個端口通過eth0連着交換機,另一個端口通過veth0連着veth1:
+----------------------------------------------------------------+
| |
| +------------------------------------------------+ |
| | Newwork Protocol Stack | |
| +------------------------------------------------+ |
| ↑ |
|.....................................................|..........|
| ↓ |
| +------+ +--------+ +-------+ +-------+ |
| | | | | | | | .3.102| |
| +------+ +--------+ +-------+ +-------+ |
| | eth0 |<--->| br0 |<--->| veth0 | | veth1 | |
| +------+ +--------+ +-------+ +-------+ |
| ↑ ↑ ↑ |
| | | | |
| | +------------+ |
| | |
+------------|---------------------------------------------------+
↓
Physical Network
ping網關成功,說明這種情況下br0不配置IP對通信沒有影響,數據包還能從veth1出去:
dev@debian:~$ ping -c 1 192.168.3.1
PING 192.168.3.1 (192.168.3.1) 56(84) bytes of data.
64 bytes from 192.168.3.1: icmp_seq=1 ttl=64 time=1.24 ms
--- 192.168.3.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.242/1.242/1.242/0.000 ms
上面如果沒有veth0和veth1的話,刪除br0上的IP後,網絡將會不通,因爲沒有設備和協議棧完全相連
bridge常用場景
上面通過例子展示了bridge的功能,但例子中的那種部署方式沒有什麼實際用途,還不如在一個網卡上配置多個IP地址來的直接。這裏來介紹兩種常見的部署方式。
虛擬機
虛擬機通過tun/tap或者其它類似的虛擬網絡設備,將虛擬機內的網卡同br0連接起來,這樣就達到和真實交換機一樣的效果,虛擬機發出去的數據包先到達br0,然後由br0交給eth0發送出去,數據包都不需要經過host機器的協議棧,效率高。
+----------------------------------------------------------------+-----------------------------------------+-----------------------------------------+
| Host | VirtualMachine1 | VirtualMachine2 |
| | | |
| +------------------------------------------------+ | +-------------------------+ | +-------------------------+ |
| | Newwork Protocol Stack | | | Newwork Protocol Stack | | | Newwork Protocol Stack | |
| +------------------------------------------------+ | +-------------------------+ | +-------------------------+ |
| ↑ | ↑ | ↑ |
|..........................|.....................................|...................|.....................|....................|....................|
| ↓ | ↓ | ↓ |
| +--------+ | +-------+ | +-------+ |
| | .3.101 | | | .3.102| | | .3.103| |
| +------+ +--------+ +-------+ | +-------+ | +-------+ |
| | eth0 |<--->| br0 |<--->|tun/tap| | | eth0 | | | eth0 | |
| +------+ +--------+ +-------+ | +-------+ | +-------+ |
| ↑ ↑ ↑ | ↑ | ↑ |
| | | +-------------------------------------------+ | | |
| | ↓ | | | |
| | +-------+ | | | |
| | |tun/tap| | | | |
| | +-------+ | | | |
| | ↑ | | | |
| | +-------------------------------------------------------------------------------|--------------------+ |
| | | | |
| | | | |
| | | | |
+------------|---------------------------------------------------+-----------------------------------------+-----------------------------------------+
↓
Physical Network (192.168.3.0/24)
docker
由於容器運行在自己單獨的network namespace裏面,所以都有自己單獨的協議棧,情況和上面的虛擬機差不多,但它採用了另一種方式來和外界通信:
+----------------------------------------------------------------+-----------------------------------------+-----------------------------------------+
| Host | Container 1 | Container 2 |
| | | |
| +------------------------------------------------+ | +-------------------------+ | +-------------------------+ |
| | Newwork Protocol Stack | | | Newwork Protocol Stack | | | Newwork Protocol Stack | |
| +------------------------------------------------+ | +-------------------------+ | +-------------------------+ |
| ↑ ↑ | ↑ | ↑ |
|............|.............|.....................................|...................|.....................|....................|....................|
| ↓ ↓ | ↓ | ↓ |
| +------+ +--------+ | +-------+ | +-------+ |
| |.3.101| | .9.1 | | | .9.2 | | | .9.3 | |
| +------+ +--------+ +-------+ | +-------+ | +-------+ |
| | eth0 | | br0 |<--->| veth | | | eth0 | | | eth0 | |
| +------+ +--------+ +-------+ | +-------+ | +-------+ |
| ↑ ↑ ↑ | ↑ | ↑ |
| | | +-------------------------------------------+ | | |
| | ↓ | | | |
| | +-------+ | | | |
| | | veth | | | | |
| | +-------+ | | | |
| | ↑ | | | |
| | +-------------------------------------------------------------------------------|--------------------+ |
| | | | |
| | | | |
| | | | |
+------------|---------------------------------------------------+-----------------------------------------+-----------------------------------------+
↓
Physical Network (192.168.3.0/24)
容器中配置網關爲.9.1,發出去的數據包先到達br0,然後交給host機器的協議棧,由於目的IP是外網IP,且host機器開啓了IP forward功能,於是數據包會通過eth0發送出去,由於.9.1是內網IP,所以一般發出去之前會先做NAT轉換(NAT轉換和IP forward功能都需要自己配置)。由於要經過host機器的協議棧,並且還要做NAT轉換,所以性能沒有上面虛擬機那種方案好,優點是容器處於內網中,安全性相對要高點。(由於數據包統一由IP層從eth0轉發出去,所以不存在mac地址的問題,在無線網絡環境下也工作良好)
上面兩種部署方案中,同一網段的每個網卡都有自己單獨的協議棧,所以不存在上面說的多個ARP的問題