如何使用 ISC KEA DHCP (DHCPv4) 服务器向客户端推送路由？

关于这个答案（教程）：

本教程旨在展示 ISC KEA DHCP (DHCPv4) 配置和部署的“成功案例”。特别演示了向 DHCP 客户端推送路由。针对具体案例还考虑了其​​他要点，这些要点是为了使演示更具说教性。

在特定情况下（使用 VirtualBox 进行模拟），我们使用 OpenVPN 隧道，并演示如何在 LAN-TO-LAN 基础设施中进行路由以两种方式使用它。

本教程的构建考虑了这样一个场景：我们在 Internet 上的服务器 (Serverloft) 在 VPN 的一端运行 Hypervisor (Xen)，在 VPN 的另一端运行公司 LAN，其中两个网络的所有服务器都能够以透明的方式进行沟通。

本教程中还考虑了其​​他注意事项，我们建议您完整阅读。

我们觉得有必要做这个教程，因为在互联网上找不到像它这样“实用”的东西。本教程还针对像我们这样对此处介绍的基本概念有更大困难的受众。

在我们继续之前，我们要感谢在此过程中提供帮助的许多人。我们特别感谢用户：@Filipe Brandenburger、@Rui F Ribeiro、@AB、@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).

注意：所有服务器都是 CentOS 7。

子网：

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) 服务器：

. 在 CentOS 7 上安装 ISC KEA 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”）。

NOTE: In a REAL WORLD SCENARIO the machines that are on the "OpenVPN server side network" would own a DHCP server and machines that are on the "OpenVPN client side network" would own another DHCP server. This division works perfectly as we are talking about the "layer 2" of the OSI model, which is therefore isolated from "layer 3" where there will be "routing", "ip forward" etc, which will be part of the integration between the two networks.

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

Server #2 - Client DHCPv4 and OpenVPN Server:

. OpenVPN server settings

vi '/etc/openvpn/server/server.conf'

IMPORTANT: We are only considering the CONFIGURATIONS STRICTLY NECESSARY FOR THE OPENVPN OPERATION IN THE PROPOSED INFRASTRUCTURE ("server.conf" and "client0"). Other settings are required. For more information, check out the OpenVPN documentation. More details on the needs addressed here at this link 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 client settings

NOTE: These settings are consumed by the client on the server side.

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

Server #3 - Client DHCPv4 and OpenVPN Client

. OpenVPN client settings

vi '/etc/openvpn/client/client0.conf'

dev tun
remote 192.168.56.4 1194

Server #2 e #3:

. Open the firewall for "OpenVPN" (Server #2 and #3)

NOTE: Openvpn is not the focus of the thread so we will not go into details here!

firewall-cmd --permanent --add-service openvpn
firewall-cmd --permanent --add-masquerade
firewall-cmd --reload

. Enable "ip_forward" (Server #2 and #3)

echo -n "net.ipv4.ip_forward=1

" >> /etc/sysctl.d/ip_forward.conf
sysctl -w net.ipv4.ip_forward=1

Server #1, #2, #3 e #4:

. Configure network interfaces

vi '/etc/sysconfig/network-scripts/ifcfg-enp0s8'

NOTE: All interfaces in all machines follow this same model since the network configurations will be provided by Server #5 (KEA DHCP Server).

BOOTPROTO=dhcp
DEVICE=enp0s8
IPV6INIT=NO
ONBOOT=yes
ZONE=public

vi '/etc/sysconfig/network'

NETWORKING=yes

Test:

. This tutorial will have been successfully executed if all of these tests are positive:

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)

Tips:

Internet (WAN) test

curl http://www.google.com

Renew DHCP on clients

dhclient -r

Remove DHCP leases settings from clients:

NOTE: Important to test the operation of the DHCP server.

rm -rf $(find /var/lib/NetworkManager/ -name "*.lease" | egrep <NETWORK_INTERFACE_NAME>)

Remove DHCP leases settings from server:

NOTE: Important to test the operation of the DHCP server.

rm -rf /usr/local/var/kea/kea-leases4.csv*

Other guidelines:

General guidelines and about the environment used for this tutorial:

1. This configuration tutorial was built in a test environment using VirtualBox;

2. All networks in use are "Host-only" and one of them (192.168.56.0/24) has internet (see 3). None of them should have VirtualBox DHCP enabled;

3. By default "Host-only" networks have no internet access ( https://www.virtualbox.org/manual/ch06.html#networkingmodes ). However, in this tutorial https://forum.manjaro.org/t/manjaro-and-virtualbox-host-only-with-internet/28722/12 I teach how to "circumvent" this limitation;

4. The internet (WAN) for the 192.168.56.0/24 network must be activated only when it is necessary. Must be disabled for running tests except to check internet access (curl http://www.google.com) on Servers #1, #2, #3 and #4 (see 3);

5. Services such as "dnsmasq" and "iptables" should be disabled on the host when the network tests are executed (ping, ssh, etc) (see 3);

6. Generally speaking, no DHCP should be present on layer 2 of the networks during the tests except what is on Server #5.

Use tun or tap (OpenVPN) - A Discussion:

We transpose below part of a chat ( chat.stackexchange.com ) between @Eduardo Lucio and @Isaac about the deploy model in this answer. We ( @Eduardo Lucio ) opted, at the moment, for using "tun", even though it was a "more laborious" configuration. However if you want a truly transparent integration between the networks on both sides of the VPN opt for tap (with all its pros and cons). I believe that the clarifications of @Isaac are very relevant to decide what to use (tap or tun) and so are transposed here so that it can reach more people.

Eduardo Lucio Sat 15:22 @Isaac https://serverfault.com/questions/21157/should-i-use-tap-or-tun-for-openvpn/21168#21168 I believe this is the way to get things done without a router. Look: "if you need to bridge two ethernet segments in two different locations - then use tap. in such setup you can have computers in the same ip subnet (eg 10.0.0.0/24) on both ends of vpn". So "vpn will act like ethernet switch". But there comes another question ... With this model I could have, for example, machines that are in the network 10.7.1.0/24 (VPN side A) communicating transparently with the network 192.168.58.0/24 (VPN side B)?

Isaac Sat 22:19 You are starting to make the right questions.

But you do have a router on each network!! Well, kind of.

There are only two ways in which a packet will reach a computer: (1) The computer is part of the same wire as another computer (the same layer 2 scope) like all ports of a (simple) switch (or the old name of hub) or belong to the same VLAN (if you do not have experience with VLANs please just keep this data point for future reference and forget I ever mentioned it for now).

Isaac Sat 22:52 (2) The packet gets routed between two layer 2 scopes by a router. The decision of whether to route a packet (or not) is taken by following the route table of the switch.

Up to this point that is just a general network description that you might find irrelevant to your specific use case until you also realize that when you tell a computer to forward packets that computer is acting as a routing device, in short, a router. That router needs to have routing tables. For example, Assuming ( you really have a mess of numbers on every question they are different, it makes quite difficult to being specific) the server 4 (at 10.1.4.6) which is the VPN client should have forward activated and must be set to route all packets it see that have 10.1.6.x as destination to the tun interface. The packets will enter the VPN, and exit the VPN on the other side. Server 3 (on the same network range 10.1.4.y at 10.1.4.5) just need to have a default (gateway) route to send all packets that are not in its own network range (10.1.4.0/24) to the GW of 10.1.4.6.

Once the packets from the VPN reach the other computer server2 (at 10.1.6.4) they must be routed as well to the router at the office and the router at the office must have a route entry to send any packet with destination 10.1.4.x to server 2. Server 2 must internally route (and have such route entry) all packets it receive to the tun interface. Is it clearly explained? All of that routing is needed because the device used is a tun (a layer 3 device).

A much simpler (and more insecure) device is a tap (a layer 2 device). Think of it as a switch to which you add computers. It will forward all packets it receive, be those directed to any (level 3) IP address or be those broadcast packets, ARP resolutions and others. In such sense, that will open computers on your office LAN to ARP attacks from computers on the other side of the VPN. All the computers on both sides of the VPN will become a large happy (everyone trust every other) family. Having said that, then yes packets that originate on IP address 10.7.1.0/24 will appear at the other side of the VPN. But the way you phrase your question: (machines at 10.7.1.0/24 and 192.168.58.0/24 will be able to communicate?) forces a NO answer. The only way in which computers at dissimilar (private) networks could communicate each other is when they have their local addresses translated to the external (remote) addresses via NAT (Network Address Translation) or similar. So each side of the NAT will see the same network range. All the above just covers IPv4. You will need to review it and extend for IPv6.