質問:
5台のサーバー(サーバー#1、#2、#3、#4、#5)を備えたインフラストラクチャがあります。 ISC KEA DHCP(DHCPv4)( https://kea.isc.org/wiki )でサーバー(サーバー#5)を使用して、他のサーバー(サーバー#1、 #2、#3、#4)。目標は、すべてのサーバーがサーバー#2と3#の間のLAN(VPNトンネル)を使用して他のサーバー(ping
、ssh
など)と通信できるようにすることです。
サーバー:
Server #1 - DHCPv4 Client;
Server #2 - DHCPv4 Client and OpenVPN Server;
Server #3 - DHCPv4 Client and OpenVPN Client;
Server #4 - DHCPv4 Client;
Server #5 - ISC KEA DHCP (DHCPv4).
サブネット:
192.168.56.0/24
10.1.2.0/24
10.1.4.0/24
10.1.6.0/24
10.8.0.1/24 (VPN tunnel)
サーバー設定:
注:ここに示すインフラストラクチャは、テストを実行するためにVirtualBoxで作成したテスト環境の一部です(実際の環境ではありません)。たとえば、192.168.56.0/24ネットワークはすべてのサーバーに存在します。
各サーバーのLAN(ネットワークインターフェース)に関する情報...
サーバー#1
[root@localhost ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope Host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope Host
valid_lft forever preferred_lft forever
2: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:56:84:1f brd ff:ff:ff:ff:ff:ff
inet 10.1.6.3/24 brd 10.1.6.255 scope global noprefixroute dynamic enp0s8
valid_lft 3514sec preferred_lft 3514sec
inet6 fe80::a00:27ff:fe56:841f/64 scope link
valid_lft forever preferred_lft forever
3: enp0s17: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:12:26:e2:6c brd ff:ff:ff:ff:ff:ff
inet 192.168.56.3/24 brd 192.168.56.255 scope global noprefixroute dynamic enp0s17
valid_lft 3606sec preferred_lft 3606sec
inet6 fe80::a00:12ff:fe26:e26c/64 scope link
valid_lft forever preferred_lft forever
サーバー#2
[root@localhost ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope Host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope Host
valid_lft forever preferred_lft forever
2: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:2c:d1:58 brd ff:ff:ff:ff:ff:ff
inet 10.1.6.4/24 brd 10.1.6.255 scope global noprefixroute dynamic enp0s8
valid_lft 3856sec preferred_lft 3856sec
inet6 fe80::a00:27ff:fe2c:d158/64 scope link
valid_lft forever preferred_lft forever
3: enp0s17: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:1c:a6:b9:59 brd ff:ff:ff:ff:ff:ff
inet 192.168.56.4/24 brd 192.168.56.255 scope global noprefixroute dynamic enp0s17
valid_lft 3897sec preferred_lft 3897sec
inet6 fe80::a00:1cff:fea6:b959/64 scope link
valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
link/none
inet 10.8.0.1/24 brd 10.8.0.255 scope global tun0
valid_lft forever preferred_lft forever
inet6 fe80::ec75:f69e:e65c:1215/64 scope link flags 800
valid_lft forever preferred_lft forever
サーバー#3
[root@localhost ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope Host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope Host
valid_lft forever preferred_lft forever
2: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:71:77:07 brd ff:ff:ff:ff:ff:ff
inet 10.1.4.5/24 brd 10.1.4.255 scope global noprefixroute dynamic enp0s8
valid_lft 3741sec preferred_lft 3741sec
inet6 fe80::a00:27ff:fe71:7707/64 scope link
valid_lft forever preferred_lft forever
3: enp0s17: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:ea:4e:40:ae brd ff:ff:ff:ff:ff:ff
inet 192.168.56.5/24 brd 192.168.56.255 scope global noprefixroute dynamic enp0s17
valid_lft 3766sec preferred_lft 3766sec
inet6 fe80::a00:eaff:fe4e:40ae/64 scope link
valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
link/none
inet 10.8.0.6/24 brd 10.8.0.255 scope global tun0
valid_lft forever preferred_lft forever
inet6 fe80::6763:9d85:a754:bf0f/64 scope link flags 800
valid_lft forever preferred_lft forever
サーバー#4
[root@localhost ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope Host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope Host
valid_lft forever preferred_lft forever
2: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:e0:d2:c8 brd ff:ff:ff:ff:ff:ff
inet 10.1.4.6/24 brd 10.1.4.255 scope global noprefixroute dynamic enp0s8
valid_lft 3907sec preferred_lft 3907sec
inet6 fe80::a00:27ff:fee0:d2c8/64 scope link
valid_lft forever preferred_lft forever
3: enp0s17: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:aa:e7:60 brd ff:ff:ff:ff:ff:ff
inet 192.168.56.6/24 brd 192.168.56.255 scope global noprefixroute dynamic enp0s17
valid_lft 3907sec preferred_lft 3907sec
inet6 fe80::a00:27ff:feaa:e760/64 scope link
valid_lft forever preferred_lft forever
サーバー#5
[root@localhost ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope Host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope Host
valid_lft forever preferred_lft forever
2: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:63:ce:c5 brd ff:ff:ff:ff:ff:ff
inet 10.1.2.2/24 brd 10.1.2.255 scope global noprefixroute enp0s8
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fe63:cec5/64 scope link
valid_lft forever preferred_lft forever
3: enp0s9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:98:ee:35 brd ff:ff:ff:ff:ff:ff
inet 10.1.4.2/24 brd 10.1.4.255 scope global noprefixroute enp0s9
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fe98:ee35/64 scope link
valid_lft forever preferred_lft forever
4: enp0s10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:b6:6b:50 brd ff:ff:ff:ff:ff:ff
inet 10.1.6.2/24 brd 10.1.6.255 scope global noprefixroute enp0s10
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:feb6:6b50/64 scope link
valid_lft forever preferred_lft forever
5: enp0s17: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:78:ed:d4 brd ff:ff:ff:ff:ff:ff
inet 192.168.56.2/24 brd 192.168.56.255 scope global noprefixroute enp0s17
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fe78:edd4/64 scope link
valid_lft forever preferred_lft forever
ありがとう!
この回答について(チュートリアル):
このチュートリアルは、ISC KEA DHCP(DHCPv4)の構成と展開の「成功事例」を示すことを目的としています。特に、DHCPクライアントへのルートのプッシュを示します。他のポイントも特定のケースで考慮され、デモンストレーションをより教訓的にするためにあります。
特定のケース(VirtualBoxを使用したシミュレーション)では、OpenVPNトンネルを使用し、LAN-TO-LANインフラストラクチャで2つの方法でそれを使用するためのルーティングを行う方法を示します。
このチュートリアルは、VPNの一方の端でハイパーバイザー(Xen)を実行するインターネット上のサーバー(Serverloft)と、VPNのもう一方の端で両方のネットワークのすべてのサーバーが可能な企業LANがあるシナリオを考慮して作成されました透過的な方法で通信します。
このチュートリアル全体を通して他の考慮事項があり、完全に読むことをお勧めします。
インターネット上にはこれほど「実用的」なものはないので、このチュートリアルを行う必要があると感じています。このチュートリアルは、私たちのように、ここで紹介する基本的な概念が非常に難しい読者も対象としています。
続行する前に、このプロセスを支援してくれた多くの人々に感謝します。特に、@ Filipe Brandenburger、@ Rui F Ribeiro、@ A.B、@ Isaac、@ slmなどのユーザーに感謝します(残念ながら、全員を引用することはできません)。
このチュートリアルのサーバー:
Server #1 - DHCPv4 Client (ips ending with 3);
Server #2 - DHCPv4 Client and OpenVPN Server (ips ending with 4);
Server #3 - DHCPv4 Client and OpenVPN Client (ips ending with 5);
Server #4 - DHCPv4 Client (ips ending with 6);
Server #5 - ISC KEA DHCP (DHCPv4) Server (ips ending with 2).
注:すべてのサーバーはCentOS7です。
サブネット:
192.168.56.0/24
10.1.2.0/24
10.1.4.0/24
10.1.6.0/24
10.8.0.1/24 (VPN tunnel)
サーバー#5-ISC KEA DHCP(DHCPv4)サーバー:
。 CentOS7へのISCKEA DHCP(DHCPv4)のインストール
yum -y install gcc-c++ openssl-devel wget
cd /usr/local/src/
wget https://dl.bintray.com/boostorg/release/1.67.0/source/boost_1_67_0.tar.gz
tar -zxvf boost_1_67_0.tar.gz
cd boost_1_67_0
./bootstrap.sh
./b2 install
rm -rf /usr/local/src/boost_1_67_0*
cd /usr/local/src/
wget https://github.com/log4cplus/log4cplus/releases/download/REL_2_0_1/log4cplus-2.0.1.tar.gz
tar zxvf log4cplus-2.0.1.tar.gz
cd log4cplus-2.0.1
./configure
make
make install
rm -rf /usr/local/src/log4cplus-2.0.1*
cd /usr/local/src/
wget https://ftp.isc.org/isc/kea/1.4.0/kea-1.4.0.tar.gz
tar zxvf kea-1.4.0.tar.gz
cd kea-1.4.0
./configure --enable-Shell
make
make install
rm -rf /usr/local/src/kea-1.4.0*
。 systemd(systemctl)でKEAサービスの設定(起動設定)を作成します。
vi '/ usr/lib/systemd/system/kea-dhcp4.service'
[Unit]
Description=Kea DHCPv4 Server
Documentation=man:kea-dhcp4(8)
Wants=network-online.target
After=network-online.target
After=time-sync.target
[Service]
ExecStart=/usr/local/sbin/kea-dhcp4 -c /usr/local/etc/kea/kea-dhcp4.conf
[Install]
WantedBy=multi-user.target
vi '/ usr/lib/systemd/system/kea-dhcp6.service'
[Unit]
Description=Kea DHCPv6 Server
Documentation=man:kea-dhcp6(8)
Wants=network-online.target
After=network-online.target
After=time-sync.target
[Service]
ExecStart=/usr/local/sbin/kea-dhcp6 -c /usr/local/etc/kea/kea-dhcp6.conf
[Install]
WantedBy=multi-user.target
vi '/ usr/lib/systemd/system/kea-dhcp-ddns.service'
[Unit]
Description=Kea DHCP-DDNS Server
Documentation=man:kea-dhcp-ddns(8)
Wants=network-online.target
After=network-online.target
After=time-sync.target
[Service]
ExecStart=/usr/local/sbin/kea-dhcp-ddns -c /usr/local/etc/kea/kea-dhcp-ddns.conf
[Install]
WantedBy=multi-user.target
。設定ファイル「/usr/local/etc/kea/kea-dhcp4.conf」を作成(調整)します。
cp '/usr/local/etc/kea/kea-dhcp4.conf' '/usr/local/etc/kea/kea-dhcp4.conf_BAK'
vi '/ usr/local/etc/kea/kea-dhcp4.conf'
{
"Dhcp4": {
"interfaces-config": {
"interfaces": ["enp0s8", "enp0s9", "enp0s10", "enp0s17"]
},
"control-socket": {
"socket-type": "unix",
"socket-name": "/tmp/kea-dhcp4-ctrl.sock"
},
"lease-database": {
"type": "memfile",
"lfc-interval": 1800
},
"expired-leases-processing": {
"reclaim-timer-wait-time": 10,
"flush-reclaimed-timer-wait-time": 25,
"hold-reclaimed-time": 3600,
"max-reclaim-leases": 100,
"max-reclaim-time": 250,
"unwarned-reclaim-cycles": 5
},
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
// Defines the "rfc3442-classless-static-routes" option.
// More details https://unix.stackexchange.com/a/460147/61742 .
"option-def": [{
"name": "rfc3442-classless-static-routes",
"code": 121,
"space": "dhcp4",
"type": "record",
"array": true,
"record-types": "uint8,uint8,uint8,uint8,uint8,uint8,uint8,uint8"
}
],
"subnet4": [{
"interface": "enp0s8",
"subnet": "10.1.2.0/24",
"pools": [{
"pool": "10.1.2.3 - 10.1.2.254"
}
]
}, {
"interface": "enp0s9",
"subnet": "10.1.4.0/24",
"pools": [{
"pool": "10.1.4.3 - 10.1.4.254"
}
],
// Reserve ips for the interfaces that have these MAC ADDRESS on that network.
"reservations": [{
// Server 3# (4)
"hw-address": "08:00:27:71:77:07",
"ip-address": "10.1.4.5"
}, {
// Server 4# (6)
"hw-address": "08:00:27:e0:d2:c8",
"ip-address": "10.1.4.6"
}
],
// Defines a route to be pushed to this subnet.
// More details https://unix.stackexchange.com/a/460147/61742 .
"option-data": [{
"name": "rfc3442-classless-static-routes",
"data": "24,10,1,6,10,1,4,5"
}
]
}, {
"interface": "enp0s10",
"subnet": "10.1.6.0/24",
"pools": [{
"pool": "10.1.6.3 - 10.1.6.254"
}
],
// Reserve ips for the interfaces that have these MAC ADDRESS on that network.
"reservations": [{
// Server 1# (3)
"hw-address": "08:00:27:56:84:1f",
"ip-address": "10.1.6.3"
}, {
// Server 2# (4)
"hw-address": "08:00:27:2c:d1:58",
"ip-address": "10.1.6.4"
}
],
// Defines a route to be pushed to this subnet.
// More details https://unix.stackexchange.com/a/460147/61742 .
"option-data": [{
// Server 3# (4) e Server 4# (6)
"name": "rfc3442-classless-static-routes",
"data": "24,10,1,4,10,1,6,4"
}
]
}, {
"interface": "enp0s17",
"subnet": "192.168.56.0/24",
"pools": [{
"pool": "192.168.56.3 - 192.168.56.254"
}
],
"option-data": [{
"name": "domain-name-servers",
"data": "192.168.56.1"
}, {
"name": "routers",
"data": "192.168.56.1"
}
],
// Reserve ips for the interfaces that have these MAC ADDRESS on that network.
"reservations": [{
// Server 1# (3)
"hw-address": "08:00:12:26:e2:6c",
"ip-address": "192.168.56.3"
}, {
// Server 2# (4)
"hw-address": "08:00:1c:a6:b9:59",
"ip-address": "192.168.56.4"
}, {
// Server 3# (5)
"hw-address": "08:00:ea:4e:40:ae",
"ip-address": "192.168.56.5"
}, {
// Server 4# (6)
"hw-address": "08:00:27:aa:e7:60",
"ip-address": "192.168.56.6"
}
]
}
]
},
"Logging": {
"loggers": [{
"name": "kea-dhcp4",
"output_options": [{
"output": "/usr/local/var/log/kea-dhcp4.log"
}
],
"severity": "INFO",
"debuglevel": 0
}
]
}
}
。ネットワークインターフェイスを構成する
これらのネットワークインターフェイスは、すべてのマシンにDHCPサーバーを提供します(上記の「kea-dhcp4.conf」を参照)。
注:REAL WORLD SCENARIOでは、「OpenVPNサーバー側ネットワーク」上にあるマシンはDHCPサーバーを所有し、「OpenVPNクライアント側ネットワーク」上にあるマシンは別のDHCPサーバーを所有します。この分割は、OSIモデルの「レイヤー2」について話しているときに完全に機能します。したがって、OSIモデルは、「ルーティング」、「ip forward」などが存在する「レイヤー3」から分離されており、これらの間の統合の一部になります。 2つのネットワーク。
vi '/ etc/sysconfig/network-scripts/ifcfg-enp0s17'
BOOTPROTO=static
DEVICE=enp0s17
DNS1=192.168.56.1
GATEWAY=192.168.56.1
IPADDR=192.168.56.2
IPV6INIT=NO
NETMASK=255.255.255.0
NM_CONTROLLED=yes
ONBOOT=yes
USERCTL=NO
vi '/ etc/sysconfig/network-scripts/ifcfg-enp0s8'
BOOTPROTO=static
DEVICE=enp0s8
IPADDR=10.1.2.2
IPV6INIT=NO
NETMASK=255.255.255.0
NM_CONTROLLED=yes
ONBOOT=yes
USERCTL=NO
vi '/ etc/sysconfig/network-scripts/ifcfg-enp0s9'
BOOTPROTO=static
DEVICE=enp0s9
IPADDR=10.1.4.2
IPV6INIT=NO
NETMASK=255.255.255.0
NM_CONTROLLED=yes
ONBOOT=yes
USERCTL=NO
vi '/ etc/sysconfig/network-scripts/ifcfg-enp0s10'
BOOTPROTO=static
DEVICE=enp0s10
IPADDR=10.1.6.2
IPV6INIT=NO
NETMASK=255.255.255.0
NM_CONTROLLED=yes
ONBOOT=yes
USERCTL=NO
サーバー#2-クライアントDHCPv4およびOpenVPNサーバー:
。 OpenVPNサーバー設定
vi '/ etc/openvpn/server/server.conf'
重要:提案されたインフラストラクチャ(「server.conf」および「client0」)でのOPENVPN操作に厳密に必要な構成のみを検討しています。その他の設定が必要です。詳細については、OpenVPNのドキュメントをご覧ください。このリンクでここで対処されるニーズの詳細 https://openvpn.net/index.php/open-source/documentation/howto.html#scope 。
dev tun
topology subnet
server 10.8.0.0 255.255.255.0
Push "route 10.1.6.0 255.255.255.0"
Push "route 10.1.4.0 255.255.255.0"
client-to-client
ifconfig 10.8.0.1 255.255.255.0
。 OpenVPNクライアント設定
注:これらの設定は、サーバー側のクライアントによって使用されます。
vi '/ etc/openvpn/ccd/client0'
ifconfig-Push 10.8.0.6 255.255.255.0
iroute 10.1.4.0 255.255.255.0
route 10.1.4.0 255.255.255.0
サーバー#3-クライアントDHCPv4およびOpenVPNクライアント
。 OpenVPNクライアント設定
vi '/ etc/openvpn/client/client0.conf'
dev tun
remote 192.168.56.4 1194
サーバー#2 e#3:
。 「OpenVPN」のファイアウォールを開きます(サーバー#2および#3)
注:Openvpnはスレッドの焦点ではないため、ここでは詳しく説明しません。
firewall-cmd --permanent --add-service openvpn
firewall-cmd --permanent --add-masquerade
firewall-cmd --reload
。 「ip_forward」を有効にします(サーバー#2および#3)
echo -n "net.ipv4.ip_forward=1
" >> /etc/sysctl.d/ip_forward.conf
sysctl -w net.ipv4.ip_forward=1
サーバー#1、#2、#3 e#4:
。ネットワークインターフェイスを構成する
vi '/ etc/sysconfig/network-scripts/ifcfg-enp0s8'
注:ネットワーク構成はサーバー#5(KEA DHCPサーバー)によって提供されるため、すべてのマシンのすべてのインターフェイスはこの同じモデルに従います。
BOOTPROTO=dhcp
DEVICE=enp0s8
IPV6INIT=NO
ONBOOT=yes
ZONE=public
vi '/ etc/sysconfig/network'
NETWORKING=yes
テスト:
。これらのテストがすべて陽性の場合、このチュートリアルは正常に実行されています。
Server #1
ping 10.1.4.5 # (#3)
ssh <USER>@10.1.4.5 # (#3)
ping 10.1.4.6 # (#4)
ssh <USER>10.1.4.6 # (#4)
Server #2
ping 10.1.4.5 # (#3)
ssh <USER>10.1.4.5 # (#3)
ping 10.1.4.6 # (#4)
ssh <USER>10.1.4.6 # (#4)
Server #3
ping 10.1.6.3 # (#1)
ssh <USER>10.1.6.3 # (#1)
ping 10.1.6.4 # (#2)
ssh <USER>10.1.6.4 # (#2)
Server #4
ping 10.1.6.3 # (#1)
ssh <USER>10.1.6.3 # (#1)
ping 10.1.6.4 # (#2)
ssh <USER>10.1.6.4 # (#2)
ヒント:
インターネット(WAN)テスト
curl http://www.google.com
クライアントのDHCPを更新する
dhclient -r
クライアントからDHCPリース設定を削除します。
注:DHCPサーバーの動作をテストすることが重要です。
rm -rf $(find /var/lib/NetworkManager/ -name "*.lease" | egrep <NETWORK_INTERFACE_NAME>)
サーバーからDHCPリース設定を削除します。
注:DHCPサーバーの動作をテストすることが重要です。
rm -rf /usr/local/var/kea/kea-leases4.csv*
その他のガイドライン:
一般的なガイドラインとこのチュートリアルで使用される環境について:
この構成チュートリアルは、VirtualBoxを使用してテスト環境で作成されました。
使用中のすべてのネットワークは「ホストオンリー」であり、そのうちの1つ(192.168.56.0/24)にはインターネットがあります(3を参照)。それらのどれもVirtualBoxDHCPを有効にするべきではありません。
デフォルトでは、「ホストオンリー」ネットワークにはインターネットアクセスがありません( https://www.virtualbox.org/manual/ch06.html#networkingmodes )。ただし、このチュートリアルでは https://forum.manjaro.org/t/manjaro-and-virtualbox-Host-only-with-internet/28722/12 この制限を「回避」する方法を教えます;
192.168.56.0/24ネットワークのインターネット(WAN)は、必要な場合にのみアクティブ化する必要があります。インターネットアクセスを確認する場合を除いて、テストを実行するには無効にする必要があります(curl http://www.google.com
)サーバー#1、#2、#3、および#4(3を参照)。
「dnsmasq」や「iptables」などのサービスは、ネットワークテスト(ping、sshなど)の実行時にホストで無効にする必要があります(3を参照)。
一般的に言って、サーバー#5にあるものを除いて、テスト中はネットワークのレイヤー2にDHCPが存在してはなりません。
tunまたはtapを使用する(OpenVPN)-ディスカッション:
この回答のデプロイモデルについて、@ Eduardo Lucioと@Isaacの間のチャット(chat.stackexchange.com)の一部を転置します。私たち(@Eduardo Lucio)は、「もっと面倒な」構成でしたが、現時点では「tun」を使用することを選択しました。ただし、VPNの両側のネットワーク間で真に透過的な統合が必要な場合は、タップを選択します(すべての長所と短所を含む)。 @Isaacの説明は、何を使用するか(タップまたは調整)を決定するのに非常に関連しているので、より多くの人に届くようにここで置き換えられていると思います。
Eduardo Lucio Sat 15:22 @Isaac https://serverfault.com/questions/21157/should-i-use-tap-or-tun-for-openvpn/21168#21168 これはルーターなしで物事を成し遂げる方法。 「2つの異なる場所で2つのイーサネットセグメントをブリッジする必要がある場合は、タップを使用します。このような設定では、VPNの両端で同じIPサブネット(例:10.0.0.0/24)にコンピューターを配置できます」。したがって、「vpnはイーサネットスイッチのように機能します」。しかし、別の質問があります...このモデルでは、たとえば、ネットワーク10.7.1.0/24(VPN側A)にあるマシンがネットワーク192.168.58.0/24(VPN側B)と透過的に通信することができますか?
Isaac Sat22:19あなたは正しい質問をし始めています。
ただし、各ネットワークにはルーターがあります。まあ、ちょっと。
パケットがコンピュータに到達する方法は2つだけです。(1)コンピュータは、すべてのポートと同様に、別のコンピュータ(同じレイヤ2スコープ)と同じワイヤの一部です。 (単純な)スイッチ(またはハブの古い名前)の、または同じVLANに属している(VLANの経験がない場合は、将来の参照用にこのデータポイントを保持してください。忘れてください)今のところ言及したことがあります)。
Isaac Sat 22:52(2)パケットは、ルーターによって2つのレイヤー2スコープ間でルーティングされます。パケットをルーティングするかどうかの決定は、スイッチのルートテーブルに従って行われます。
これまでのところ、これは一般的なネットワークの説明であり、コンピュータに転送パケットを指示すると、そのコンピュータが動作していることに気付くまで、特定のユースケースとは無関係であることがわかります。ルーティングデバイスとして、つまりルーターとして。そのルーターにはルーティングテーブルが必要です。たとえば、VPNクライアントであるサーバー4(10.1.4.6)は、順方向にアクティブ化されている必要があり、次のように設定する必要があります(異なる質問ごとに実際に数字が混乱しているため、特定するのが非常に困難です)。 10.1.6.xを宛先として持つすべてのパケットをtunインターフェイスにルーティングします。パケットはVPNに入り、反対側のVPNから出ます。サーバー3(10.1.4.5の同じネットワーク範囲10.1.4.y上)は、それ自体がではないすべてのパケットを送信するためのデフォルト(ゲートウェイ)ルートを持っている必要がありますネットワーク範囲(10.1.4.0/24)からGW10.1.4.6まで。
VPNからのパケットが他のコンピューターサーバー2(10.1.6.4)に到達したら、ルーターにもルーティングする必要があります。オフィスとオフィスのルーターには、宛先10.1.4.xのパケットをサーバー2に送信するためのルートエントリが必要です。サーバー2は、受信したすべてのパケットをtunインターフェイスに内部的にルーティング(およびそのようなルートエントリ)する必要があります。明確に説明されていますか?使用されるデバイスはtun(レイヤー3デバイス)であるため、このルーティングはすべて必要です。
はるかに単純な(そしてより安全でない)デバイスは、タップ(レイヤー2デバイス)です。コンピュータを追加するスイッチと考えてください。受信したすべてのパケットを転送します。これは、任意の(レベル3)IPアドレスに送信されたパケット、またはブロードキャストパケット、ARP解像度などです。そのような意味で、それはあなたのオフィスLAN上のコンピュータをVPNの反対側のコンピュータからのARP攻撃に開放します。 VPNの両側にあるすべてのコンピューターは、大規模な幸せな(誰もがお互いを信頼する)家族になります。そうは言っても、IPアドレス10.7.1.0/24で発信されたyesパケットは、VPNの反対側に表示されます。しかし、あなたの質問の言い方:( 10.7.1.0/24と192.168.58.0/24のマシンは通信できますか?)はNOの答えを強制します。異なる(プライベート)ネットワークのコンピューターが相互に通信できる唯一の方法は、ローカルアドレスをNAT(ネットワークアドレス変換)などを介して外部(リモート)アドレスに変換する場合です。したがって、NATの両側には、同じネットワーク範囲が表示されます。上記はすべてIPv4のみを対象としています。これを確認し、IPv6に拡張する必要があります。