Linux虚拟网络设备之tun/tap和veth设备的特点

最新推荐文章于 2023-12-07 15:52:20 发布
最新推荐文章于 2023-12-07 15:52:20 发布
阅读量930 收藏 4
点赞数 1
文章标签： linux 网络 运维
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Michaelwubo/article/details/134204672
版权

在现在的云时代，到处都是虚拟机和容器，它们背后的网络管理都离不开虚拟网络设备，所以了解虚拟网络设备有利于我们更好的理解云时代的网络结构。从本篇开始，将介绍Linux下的虚拟网络设备。

虚拟设备和物理设备的区别

在Linux网络数据包的接收过程和数据包的发送过程这两篇文章中，介绍了数据包的收发流程，知道了Linux内核中有一个网络设备管理层，处于网络设备驱动和协议栈之间，负责衔接它们之间的数据交互。驱动不需要了解协议栈的细节，协议栈也不需要了解设备驱动的细节。

对于一个网络设备来说，就像一个管道（pipe）一样，有两端，从其中任意一端收到的数据将从另一端发送出去。

比如一个物理网卡eth0，它的两端分别是内核协议栈（通过内核网络设备管理模块间接的通信）和外面的物理网络，从物理网络收到的数据，会转发给内核协议栈，而应用程序从协议栈发过来的数据将会通过物理网络发送出去。

那么对于一个虚拟网络设备呢？首先它也归内核的网络设备管理子系统管理，对于Linux内核网络设备管理模块来说，虚拟设备和物理设备没有区别，都是网络设备，都能配置IP，从网络设备来的数据，都会转发给协议栈，协议栈过来的数据，也会交由网络设备发送出去，至于是怎么发送出去的，发到哪里去，那是设备驱动的事情，跟Linux内核就没关系了，所以说虚拟网络设备的一端也是协议栈，而另一端是什么取决于虚拟网络设备的驱动实现。

tun/tap的另一端是什么？

先看图再说话：

+----------------------------------------------------------------+
|                                                                |
|  +--------------------+      +--------------------+            |
|  | User Application A |      | User Application B |<-----+     |
|  +--------------------+      +--------------------+      |     |
|               | 1                    | 5                 |     |
|...............|......................|...................|.....|
|               ↓                      ↓                   |     |
|         +----------+           +----------+              |     |
|         | socket A |           | socket B |              |     |
|         +----------+           +----------+              |     |
|                 | 2               | 6                    |     |
|.................|.................|......................|.....|
|                 ↓                 ↓                      |     |
|             +------------------------+                 4 |     |
|             | Newwork Protocol Stack |                   |     |
|             +------------------------+                   |     |
|                | 7                 | 3                   |     |
|................|...................|.....................|.....|
|                ↓                   ↓                     |     |
|        +----------------+    +----------------+          |     |
|        |      eth0      |    |      tun0      |          |     |
|        +----------------+    +----------------+          |     |
|    10.32.0.11  |                   |   192.168.3.11      |     |
|                | 8                 +---------------------+     |
|                |                                               |
+----------------|-----------------------------------------------+
                 ↓
         Physical Network

上图中有两个应用程序A和B，都在用户层，而其它的socket、协议栈（Newwork Protocol Stack）和网络设备（eth0和tun0）部分都在内核层，其实socket是协议栈的一部分，这里分开来的目的是为了看的更直观。

tun0是一个Tun/Tap虚拟设备，从上图中可以看出它和物理设备eth0的差别，它们的一端虽然都连着协议栈，但另一端不一样，eth0的另一端是物理网络，这个物理网络可能就是一个交换机，而tun0的另一端是一个用户层的程序，协议栈发给tun0的数据包能被这个应用程序读取到，并且应用程序能直接向tun0写数据。

这里假设eth0配置的IP是10.32.0.11，而tun0配置的IP是192.168.3.11.

这里列举的是一个典型的tun/tap设备的应用场景，发到192.168.3.0/24网络的数据通过程序B这个隧道，利用10.32.0.11发到远端网络的10.33.0.1，再由10.33.0.1转发给相应的设备，从而实现VPN。

下面来看看数据包的流程：

  1. 应用程序A是一个普通的程序，通过socket A发送了一个数据包，假设这个数据包的目的IP地址是192.168.3.1

  2. socket将这个数据包丢给协议栈

  3. 协议栈根据数据包的目的IP地址，匹配本地路由规则，知道这个数据包应该由tun0出去，于是将数据包交给tun0

  4. tun0收到数据包之后，发现另一端被进程B打开了，于是将数据包丢给了进程B

  5. 进程B收到数据包之后，做一些跟业务相关的处理，然后构造一个新的数据包，将原来的数据包嵌入在新的数据包中，最后通过socket B将数据包转发出去，这时候新数据包的源地址变成了eth0的地址，而目的IP地址变成了一个其它的地址，比如是10.33.0.1.

  6. socket B将数据包丢给协议栈

  7. 协议栈根据本地路由，发现这个数据包应该要通过eth0发送出去，于是将数据包交给eth0

  8. eth0通过物理网络将数据包发送出去

10.33.0.1收到数据包之后，会打开数据包，读取里面的原始数据包，并转发给本地的192.168.3.1，然后等收到192.168.3.1的应答后，再构造新的应答包，并将原始应答包封装在里面，再由原路径返回给应用程序B，应用程序B取出里面的原始应答包，最后返回给应用程序A

这里不讨论Tun/Tap设备tun0是怎么和用户层的进程B进行通信的，对于Linux内核来说，有很多种办法来让内核空间和用户空间的进程交换数据。

从上面的流程中可以看出，数据包选择走哪个网络设备完全由路由表控制，所以如果我们想让某些网络流量走应用程序B的转发流程，就需要配置路由表让这部分数据走tun0。

un/tap设备有什么用？

从上面介绍过的流程可以看出来，tun/tap设备的用处是将协议栈中的部分数据包转发给用户空间的应用程序，给用户空间的程序一个处理数据包的机会。于是比较常用的数据压缩，加密等功能就可以在应用程序B里面做进去，tun/tap设备最常用的场景是VPN，包括tunnel以及应用层的IPSec等，比较有名的项目是VTun，有兴趣可以去了解一下。

tun和tap的区别

用户层程序通过tun设备只能读写IP数据包，而通过tap设备能读写链路层数据包，类似于普通socket和raw socket的差别一样，处理数据包的格式不一样。

 veth设备的特点

  • veth和其它的网络设备都一样，一端连接的是内核协议栈。
  • veth设备是成对出现的，另一端两个设备彼此相连
  • 一个设备收到协议栈的数据发送请求后，会将数据发送到另一个设备上去。

下面这张关系图很清楚的说明了veth设备的特点：

+----------------------------------------------------------------+
|                                                                |
|       +------------------------------------------------+       |
|       |             Newwork Protocol Stack             |       |
|       +------------------------------------------------+       |
|              ↑               ↑               ↑                 |
|..............|...............|...............|.................|
|              ↓               ↓               ↓                 |
|        +----------+    +-----------+   +-----------+           |
|        |   eth0   |    |   veth0   |   |   veth1   |           |
|        +----------+    +-----------+   +-----------+           |
|192.168.1.11  ↑               ↑               ↑                 |
|              |               +---------------+                 |
|              |         192.168.2.11     192.168.2.1            |
+--------------|-------------------------------------------------+
               ↓
         Physical Network

上图中，我们给物理网卡eth0配置的IP为192.168.1.11， 而veth0和veth1的IP分别是192.168.2.11和192.168.2.1。

我们通过示例的方式来一步一步的看看veth设备的特点。

只给一个veth设备配置IP

先通过ip link命令添加veth0和veth1，然后配置veth0的IP，并将两个设备都启动起来

dev@debian:~$ sudo ip link add veth0 type veth peer name veth1
dev@debian:~$ sudo ip addr add 192.168.2.11/24 dev veth0
dev@debian:~$ sudo ip link set veth0 up
dev@debian:~$ sudo ip link set veth1 up

 

这里不给veth1设备配置IP的原因就是想看看在veth1没有IP的情况下，veth0收到协议栈的数据后会不会转发给veth1。

ping一下192.168.2.1，由于veth1还没配置IP，所以肯定不通

dev@debian:~$ ping -c 4 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
From 192.168.2.11 icmp_seq=1 Destination Host Unreachable
From 192.168.2.11 icmp_seq=2 Destination Host Unreachable
From 192.168.2.11 icmp_seq=3 Destination Host Unreachable
From 192.168.2.11 icmp_seq=4 Destination Host Unreachable

--- 192.168.2.1 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3015ms
pipe 3

但为什么ping不通呢？是到哪一步失败的呢？

先看看抓包的情况，从下面的输出可以看出，veth0和veth1收到了同样的ARP请求包，但没有看到ARP应答包：

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
20:20:18.285230 ARP, Request who-has 192.168.2.1 tell 192.168.2.11, length 28
20:20:19.282018 ARP, Request who-has 192.168.2.1 tell 192.168.2.11, length 28
20:20:20.282038 ARP, Request who-has 192.168.2.1 tell 192.168.2.11, length 28
20:20:21.300320 ARP, Request who-has 192.168.2.1 tell 192.168.2.11, length 28
20:20:22.298783 ARP, Request who-has 192.168.2.1 tell 192.168.2.11, length 28
20:20:23.298923 ARP, Request who-has 192.168.2.1 tell 192.168.2.11, length 28

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
20:20:48.570459 ARP, Request who-has 192.168.2.1 tell 192.168.2.11, length 28
20:20:49.570012 ARP, Request who-has 192.168.2.1 tell 192.168.2.11, length 28
20:20:50.570023 ARP, Request who-has 192.168.2.1 tell 192.168.2.11, length 28
20:20:51.570023 ARP, Request who-has 192.168.2.1 tell 192.168.2.11, length 28
20:20:52.569988 ARP, Request who-has 192.168.2.1 tell 192.168.2.11, length 28
20:20:53.570833 ARP, Request who-has 192.168.2.1 tell 192.168.2.11, length 28

为什么会这样呢？了解ping背后发生的事情后就明白了：

  1. ping进程构造ICMP echo请求包，并通过socket发给协议栈，
  2. 协议栈根据目的IP地址和系统路由表，知道去192.168.2.1的数据包应该要由192.168.2.11口出去
  3. 由于是第一次访问192.168.2.1，且目的IP和本地IP在同一个网段，所以协议栈会先发送ARP出去，询问192.168.2.1的mac地址
  4. 协议栈将ARP包交给veth0，让它发出去
  5. 由于veth0的另一端连的是veth1，所以ARP请求包就转发给了veth1
  6. veth1收到ARP包后，转交给另一端的协议栈
  7. 协议栈一看自己的设备列表，发现本地没有192.168.2.1这个IP，于是就丢弃了该ARP请求包，这就是为什么只能看到ARP请求包，看不到应答包的原因

给两个veth设备都配置IP

给veth1也配置上IP

dev@debian:~$ sudo ip addr add 192.168.2.1/24 dev veth1

再ping 192.168.2.1成功（由于192.168.2.1是本地IP，所以默认会走lo设备，为了避免这种情况，这里使用ping命令带上了-I参数，指定数据包走指定设备）

dev@debian:~$ ping -c 4 192.168.2.1 -I veth0
PING 192.168.2.1 (192.168.2.1) from 192.168.2.11 veth0: 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.032 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=0.048 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.055 ms
64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=0.050 ms

--- 192.168.2.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 0.032/0.046/0.055/0.009 ms
注意：对于非debian系统，这里有可能ping不通，主要是因为内核中的一些ARP相关配置导致veth1不返回ARP应答包，如ubuntu上就会出现这种情况，解决办法如下：
root@ubuntu:~# echo 1 > /proc/sys/net/ipv4/conf/veth1/accept_local
root@ubuntu:~# echo 1 > /proc/sys/net/ipv4/conf/veth0/accept_local
root@ubuntu:~# echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
root@ubuntu:~# echo 0 > /proc/sys/net/ipv4/conf/veth0/rp_filter
root@ubuntu:~# echo 0 > /proc/sys/net/ipv4/conf/veth1/rp_filter

再来看看抓包情况，我们在veth0和veth1上都看到了ICMP echo的请求包，但为什么没有应答包呢？上面不是显示ping进程已经成功收到了应答包吗？

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
20:23:43.113062 IP 192.168.2.11 > 192.168.2.1: ICMP echo request, id 24169, seq 1, length 64
20:23:44.112078 IP 192.168.2.11 
> 192.168.2.1: ICMP echo request, id 24169, seq 2, length 64
20:23:45.111091 IP 192.168.2.11 > 192.168.2.1: ICMP echo request, id 24169, seq 3, length 64
20:23:46.110082 IP 192.168.2.11 > 192.168.2.1: ICMP echo request, id 24169, seq 4, length 64


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
20:24:12.221372 IP 192.168.2.11 > 192.168.2.1: ICMP echo request, id 24174, seq 1, length 64
20:24:13.222089 IP 192.168.2.11 > 192.168.2.1: ICMP echo request, id 24174, seq 2, length 64
20:24:14.224836 IP 192.168.2.11 > 192.168.2.1: ICMP echo request, id 24174, seq 3, length 64
20:24:15.223826 IP 192.168.2.11 > 192.168.2.1: ICMP echo request, id 24174, seq 4, length 64

看看数据包的流程就明白了：

  1. ping进程构造ICMP echo请求包，并通过socket发给协议栈，
  2. 由于ping程序指定了走veth0，并且本地ARP缓存里面已经有了相关记录，所以不用再发送ARP出去，协议栈就直接将该数据包交给了veth0
  3. 由于veth0的另一端连的是veth1，所以ICMP echo请求包就转发给了veth1
  4. veth1收到ICMP echo请求包后，转交给另一端的协议栈
  5. 协议栈一看自己的设备列表，发现本地有192.168.2.1这个IP，于是构造ICMP echo应答包，准备返回
  6. 协议栈查看自己的路由表，发现回给192.168.2.11的数据包应该走lo口，于是将应答包交给lo设备
  7. lo接到协议栈的应答包后，啥都没干，转手又把数据包还给了协议栈（相当于协议栈通过发送流程把数据包给lo，然后lo再将数据包交给协议栈的接收流程）
  8. 协议栈收到应答包后，发现有socket需要该包，于是交给了相应的socket
  9. 这个socket正好是ping进程创建的socket，于是ping进程收到了应答包

抓一下lo设备上的数据，发现应答包确实是从lo口回来的：

dev@debian:~$ sudo tcpdump -n -i lo
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
20:25:49.590273 IP 192.168.2.1 > 192.168.2.11: ICMP echo reply, id 24177, seq 1, length 64
20:25:50.590018 IP 192.168.2.1 > 192.168.2.11: ICMP echo reply, id 24177, seq 2, length 64
20:25:51.590027 IP 192.168.2.1 > 192.168.2.11: ICMP echo reply, id 24177, seq 3, length 64
20:25:52.590030 IP 192.168.2.1 > 192.168.2.11: ICMP echo reply, id 24177, seq 4, length 64

试着ping下其它的IP

ping 192.168.2.0/24网段的其它IP失败，ping一个公网的IP也失败：

dev@debian:~$ ping -c 1 -I veth0 192.168.2.2
PING 192.168.2.2 (192.168.2.2) 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.2 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

dev@debian:~$ ping -c 1 -I veth0 baidu.com
PING baidu.com (111.13.101.208) from 192.168.2.11 veth0: 56(84) bytes of data.
From 192.168.2.11 icmp_seq=1 Destination Host Unreachable

--- baidu.com ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

从抓包来看，和上面第一种veth1没有配置IP的情况是一样的，ARP请求没人处理

dev@debian:~$ sudo tcpdump -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
02:25:23.223947 ARP, Request who-has 192.168.2.2 tell 192.168.2.11, length 28
02:25:24.224352 ARP, Request who-has 192.168.2.2 tell 192.168.2.11, length 28
02:25:25.223471 ARP, Request who-has 192.168.2.2 tell 192.168.2.11, length 28
02:25:27.946539 ARP, Request who-has 123.125.114.144 tell 192.168.2.11, length 28
02:25:28.946633 ARP, Request who-has 123.125.114.144 tell 192.168.2.11, length 28
02:25:29.948055 ARP, Request who-has 123.125.114.144 tell 192.168.2.11, length 28

结束语

从上面的介绍中可以看出，从veth0设备出去的数据包，会转发到veth1上，如果目的地址是veth1的IP的话，就能被协议栈处理，否则连ARP那关都过不了，IP forward啥的都用不上，所以不借助其它虚拟设备的话，这样的数据包只能在本地协议栈里面打转转，没法走到eth0上去，即没法发送到外面的网络中去。

下一篇将介绍Linux下的网桥，到时候veth设备就有用武之地了。

Michaelwubo
关注
  • 1
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
易语言TUN/TAP虚拟网卡使用例子-易语言
06-12
易语言TUN/TAP虚拟网卡使用例子
tun/tap虚拟网卡驱动tun.ko
08-17
tun/tap虚拟网卡驱动
Linux - 虚拟网络设备- TUN，TAP，ip tunnel
vertor11的博客
09-12 4891
引用 Tun/Tap interface tutorial 什么是IP隧道，Linux怎么实现隧道通信？ Linux内核网络设备--TUN. TAP设备 一. concep TUN设备：一种虚拟网络设备，点对点的设备。三层设备，即处理的是IP数据包。不需要物理地址，即不需要ARP。用于创建路由。因为通过读写/dev/tun设备可以直接从协议栈的三层读写ip包，所以tun设备常用于vpn、tunnel、ipsec之类的。 TAP设备：一种虚拟网络设备，ethernet以太网设备。二层设备，即处...
Linux：虚拟网卡技术tun/tap
hhd1988的专栏
05-30 3971
Linux：虚拟网卡技术tun/tap
Linux tun虚拟网卡通信初识
weixin_42271802的博客
08-08 2205
Linux TUN 设备是一种虚拟网络设备，用于在用户空间和内核空间之间建立数据通道，使用户空间程序可以通过这个设备与内核网络栈进行交互。TUN 设备是一种通用的网络隧道设备，常用于实现虚拟专用网络（VPN）和其他网络隧道技术。
网络虚拟化之 tun/tap 网络设备
Keep Moving~
05-24 2943
本文将详细介绍 tun/tap 设备的原理及应用，希望能通过本文的介绍读者能对 tun/tap 网络设备有一个更加全面的了解。
云原生虚拟化：一文读懂网络虚拟化之 tun/tap 网络设备
VE_Edge的博客
01-27 8362
网络作为边缘虚机的底层基础设施之一，其重要性也是不言而喻，它承担着虚拟机实例南北向、东西向的流量连通性职能，而 tun/tap 设备正是 qemu 连通 vm 内外网络的重要虚拟设备。
关于Linux的TUN／TAP编程.pdf
09-06
关于Linux的TUN／TAP编程.pdf
论文研究-用Tun/tap虚拟设备实现数据安全传送的方法的研究与实现 .pdf
08-15
用Tun/tap虚拟设备实现数据安全传送的方法的研究与实现，刘敏，蒋砚军，本文以Tun/tap为理论基础和技术背景，实现了一种安全传送数据的方法。Tun/tap驱动不仅实现了网卡驱动而且还实现了字符设备驱动部分，�
opensslPtunPtap.rar_openssl_tun tap_tun/tap
07-15
TUN/TAP设备是Linux内核提供的一种虚拟网络接口，允许用户空间程序直接参与网络数据包的处理。TUN设备工作在网络层，处理IP级别的数据包；而TAP设备则工作在数据链路层，处理以太网或PPP等帧。这两种设备为开发者...
云网络中的虚拟网络设备Tap与Tun
最新发布
m0_73901077的博客
12-07 2794
Tap/Tun设备是Linux操作系统内核中的虚拟网络设备，提供与硬件网卡完全相同的功能，但一般物理网卡一端连接的是物理网络，一端连接的是网络协议栈，而Tap/Tun主要用于用户空间和内核空间传递报文，即一端连接的是应用程序（通过字符设备文件/net/dev/tun），一端连接的是网络协议栈。当发送数据包的时候，如果与应用程序连接的是TCP/IP协议栈，则使用TCP/IP协议栈来发送数据包，如果与应用程序相连接的tap设备，则使用tap设备来发送数据。那到底该怎么选择呢？
理解Linux TunTap设备
Crazy博客
05-26 1131
通信流程是，在Node1中的NS1进行ping Node2中NS2的veth0网卡的IP，ICMP的IP包会通过veth0到达veth1中，并进入到宿主机的网络协议栈，通过路由配置达到tun设备，这时app服务从tun设备中读取到IP包数据，然后将其封装在UDP包中，并通过eth0网卡发送到Node2的eth0网卡上，通过网络协议栈解包达到app程序中，拿到里面的IP包，将其写入到tun设备中，进入到网络协议栈中，通过路由达到veth1中，然后到达net ns1的veth0网卡。
Linux tun:tap 详解
yufei82314的博客
11-11 2351
tun与tap区别
TUN 设备原理
Network/Storage/Linux Kernel
01-25 4439
TUN 设备原理 本文要解决的就是 sslvpn 的运行机制。例如如何使用tun设备，是的连个独立的私网ip能够跨公网访问 simpletun 首先玩一下简单的例子 https://github.com/gregnietsky/simpletun.git 然后有个直观的感受 我们找2台机器 分别使用make命令编译上述代码，生成 二进制 simpletun A物理ip 11.238.116.73 B物理ip 11.238.116.75 在B机器上执行 sudo ./simpletun -i tun90 -
ip命令添加tun网卡和tap网卡
zby枣菠鱼的博客
12-01 3211
tun网卡处于三层没有mac地址 添加名称为tun0网卡： ip tuntap add tun0 mode tun tap网卡处于二层有mac地址 添加名称为tap0网卡： ip tuntap add tap0 mode tap
linux虚拟网络设备
yiyu89的专栏
04-08 1555
准备工作 CentOS7 网卡eth0(192.168.0.3/24) 1.网络命名空间（namespace） 在 Linux 中，网络名字空间可以被认为是隔离的拥有单独网络栈（网卡、路由转发表、iptables）的环境。网络名字空间经常用来隔离网络设备和服务，只有拥有同样网络名字空间的设备，才能看到彼此。 从逻辑上说，网络命名空间是网络栈的副本，有自己的网络设备、路由选择表、邻接表、Netfilter表、网络套接字、网络procfs条目、网络sysfs条目和其他网络资源。 从系统的角度来看，当通过clon
虚拟设备之TUN和TAP
m0_53157173的博客
08-04 510
虚拟设备之TUN和TAP
Linux虚拟网络设备---之Veth pair详解
meihualing的专栏
06-10 1949
linux, veth pair, namespaces命令空间
Linux网络设备
zc58778560的博客
08-23 217
（5）当一个母设备拥有多个VLAN子设备时，子设备之间是隔离的，不存在Bridge那样的交换转发关系，原因如下：802.1.qVLAN协议的主要目的是从逻辑上隔离子网。当母设备收到一包数据时，它将会分析其中的VLANTag，如果有对应的子设备存在，则把数据转发到那个子设备上并根据设置移除VLANTag，否则丢弃该数据。发送到虚拟网络接口中的数据也会出现在该字符设备上。和Bridge一样，母子设备的数据也是有方向的，子设备收到的数据不会进入母设备，同样母设备上请求发送的数据不会被转到子设备上。
Linux下用虚拟网络设备进行广域网配置实验报告
05-26
本实验旨在通过创建虚拟网络设备，在Linux操作系统上进行广域网配置实验。以下是实验报告： 一、实验环境 1. 操作系统：Ubuntu 20.04 LTS 2. 虚拟机软件：VirtualBox 6.1.22 二、实验步骤 1. 创建两个虚拟机，分别命名为Router和Host，并设置虚拟机的网络适配器为“仅NAT网络”模式。 2. 在Router虚拟机上创建两个虚拟网络设备：tun0和tun1。其中，tun0设备为本地网络连接，IP地址为192.168.1.1/24；tun1设备为广域网连接，IP地址为10.0.0.1/24。 ``` sudo ip tuntap add mode tun tun0 sudo ip tuntap add mode tun tun1 sudo ip link set dev tun0 up sudo ip link set dev tun1 up sudo ip addr add 192.168.1.1/24 dev tun0 sudo ip addr add 10.0.0.1/24 dev tun1 ``` 3. 在Host虚拟机上创建一个虚拟网络设备：tun0，IP地址为192.168.1.2/24。 ``` sudo ip tuntap add mode tun tun0 sudo ip link set dev tun0 up sudo ip addr add 192.168.1.2/24 dev tun0 ``` 4. 在Router虚拟机上启用IP转发功能。 ``` sudo sysctl -w net.ipv4.ip_forward=1 ``` 5. 在Router虚拟机上设置路由，将Host虚拟机的数据包转发到tun1设备。 ``` sudo ip route add 192.168.1.0/24 dev tun0 sudo ip route add default via 10.0.0.2 dev tun1 ``` 6. 在Host虚拟机上设置默认网关为Router虚拟机的tun0设备。 ``` sudo ip route add default via 192.168.1.1 dev tun0 ``` 7. 测试网络连接，Host虚拟机可以ping通Router虚拟机的tun0设备和tun1设备。 三、实验总结 通过本实验，我们成功地创建了虚拟网络设备，在Linux操作系统上进行了广域网配置实验。我们可以通过创建虚拟网络设备，实现不同网络之间的连接，并进行数据传输。虚拟网络设备的创建和配置，是Linux系统网络配置的一个重要部分，也是进行网络编程和网络调试的必备技能。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值