ISC KEA DHCP(DHCPv4) 서버를 사용하여 클라이언트에 경로를 푸시하는 방법은 무엇입니까?

이 답변(튜토리얼)과 관련하여:

이 튜토리얼은 ISC KEA DHCP(DHCPv4) 구성 및 배포의 "성공 사례"를 보여주기 위해 설계되었습니다. DHCP 클라이언트에 경로를 푸시하는 데모에 중점을 둡니다. 프레젠테이션을 더욱 유익하게 만들기 위해 사례별로 다른 사항도 고려됩니다.

특정 사례(VirtualBox를 사용하여 시뮬레이션)에서는 OpenVPN 터널을 사용하고 이를 LAN-to-LAN 인프라에서 두 가지 방법으로 사용하도록 라우팅하는 방법을 보여줍니다.

이 튜토리얼은 시나리오를 염두에 두고 작성되었습니다. 인터넷에 VPN의 한쪽에는 하이퍼바이저(Xen)를 실행하는 서버(Serverloft)가 있고 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" 참조).

참고: 실제 시나리오에서 "OpenVPN 서버 네트워크"의 컴퓨터에는 하나의 DHCP 서버가 있고 "OpenVPN 클라이언트 네트워크"의 컴퓨터에는 또 다른 DHCP 서버가 있습니다. 이 분할은 OSI 모델의 "계층 2"에 대해 이야기할 때 잘 작동하므로 "라우팅", "IP 전달" 등이 있는 "계층 3"과 격리됩니다. 두 개의 네트워크.

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'

중요: 제안된 인프라에서 OPENVPN 작동에 필요한 구성("server.conf" 및 "client0")만 고려합니다. 추가 설정이 필요합니다. 자세한 내용은 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 및 #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, #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*

---

기타 가이드:

이 튜토리얼에서 사용되는 환경에 대한 일반 지침 및 정보:

1. 이 구성 튜토리얼은 VirtualBox를 사용하여 테스트 환경에서 구축되었습니다.

2. 사용된 모든 네트워크는 "호스트 전용" 네트워크이며, 그 중 하나(192.168.56.0/24)에는 인터넷이 있습니다(3 참조). 이들 중 어느 것도 VirtualBox DHCP를 활성화해서는 안 됩니다.

3. 기본적으로 "호스트 전용" 네트워크는 인터넷에 액세스할 수 없습니다(https://www.virtualbox.org/manual/ch06.html#networkingmodes). 그러나 이 튜토리얼에서는https://forum.manjaro.org/t/manjaro-and-virtualbox-host-only-with-internet/28722/12나는 이 제한을 "피하는" 방법을 가르칩니다.

4. 192.168.56.0/24 네트워크의 인터넷(WAN)은 필요한 경우에만 활성화해야 합니다. curl http://www.google.com서버 #1, #2, #3 및 #4에서 인터넷 액세스( ) 확인을 제외하고 테스트를 실행하려면 비활성화되어야 합니다 (3 참조).

5. 네트워크 테스트(ping, ssh 등)를 수행할 때 "dnsmasq" 및 "iptables"와 같은 서비스는 호스트에서 비활성화되어야 합니다(3 참조).

6. 일반적으로 테스트 중에는 서버 #5의 DHCP를 제외하고 네트워크의 레이어 2에 DHCP가 없어야 합니다.

---

Tun 또는 Tap(OpenVPN) 사용 - 토론:

이 답변의 배포 모델에 관해 @Eduardo Lucio와 @Isaac 사이의 채팅(chat.stackexchange.com)의 다음 부분을 바꾸었습니다. 현재 우리(@Eduardo Lucio)는 "tun"을 사용하기로 선택했지만 이는 "더 힘든" 구성입니다. 그러나 VPN 양쪽의 네트워크 간에 진정으로 투명한 통합을 원한다면 Tap(및 모든 장단점)을 선택하세요. 나는 @Isaac의 설명이 무엇을 사용할지(탭 또는 튜닝) 결정하는 데 매우 관련이 있다고 생각하므로 더 많은 사람들에게 다가갈 수 있도록 여기에 옮겨 놓았습니다.

에두아르도 루시우 토요일 15:22 @Isaac https://serverfault.com/questions/21157/should-i-use-tap-or-tun-for-openvpn/21168#21168 나는 이것이 라우터 없이 작업을 수행하는 방법이라고 믿습니다. 다음을 살펴보십시오. "두 개의 서로 다른 위치에 있는 두 개의 이더넷 세그먼트를 연결해야 하는 경우 Tap을 사용하십시오. 이 설정에서는 VPN 양쪽의 동일한 IP 서브넷(예: 10.0.0.0/24)에 컴퓨터를 가질 수 있습니다." 따라서 "VPN은 이더넷 스위치처럼 작동합니다". 하지만 또 다른 문제가 있습니다... 예를 들어, 이 모델을 사용하면 네트워크 10.7.1.0/24(VPN A 측)의 컴퓨터가 네트워크 192.168.58.0/24(VPN B 측)와 투명하게 통신하도록 할 수 있습니까?

이삭 토 22:19 당신은 올바른 질문을 하기 시작했습니다.

하지만 모든 네트워크에는 라우터가 있습니다! 글쎄요.

데이터 패킷이 컴퓨터에 도달하는 방법은 두 가지뿐입니다. (1) 컴퓨터는 동일한 컴퓨터의 일부입니다.메탈릭 라인(간단한) 스위치(또는 이전 이름의 허브)와 같은 다른 컴퓨터(동일한 레이어 2 범위)의 모든 포트로 사용되거나 동일한 VLAN에 속합니다(VLAN에 대한 경험이 없는 경우 나중에 사용할 수 있도록 이 데이터 포인트를 유지하십시오). 내가 지금 언급한 것을 참고하고 잊어버리세요).

Isaac Sat 22:52 (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) ~ GW 10.1.4.6.

VPN의 패킷이 다른 컴퓨터 Server 2(10.1.6.4에 위치)에 도달하면 패킷은 다음과 같아야 합니다.라우팅됨게다가라우터10.1.4.x로 향하는 패킷을 서버 2로 보내려면 사무실 라우터와 사무실 라우터 사이에 경로 항목이 있어야 합니다. 서버 2는 수신하는 모든 패킷(및 그러한 라우팅 항목이 있음)을 내부적으로 tun 인터페이스로 라우팅해야 합니다. 명확하게 설명되었나요? 사용되는 장치가 tun(계층 3 장치)이기 때문에 이러한 경로가 모두 필요합니다.

더 간단하고 덜 안전한 장치는 Tap(계층 2 장치)입니다. 컴퓨터를 추가하는 스위치라고 생각하세요. 임의의 (레벨 3) IP 주소 또는 브로드캐스트 패킷, ARP 확인 등으로 전달되는지 여부에 관계없이 수신된 모든 패킷을 전달합니다. 이러한 의미에서 사무실 LAN의 컴퓨터는 VPN 반대편에 있는 컴퓨터의 ARP 공격에 취약해집니다. VPN 양쪽에 있는 모든 컴퓨터는 하나의 행복한 가족이 될 것입니다(모두가 서로를 신뢰합니다). 하지만 IP 주소 10.7.1.0/24에서 오는 패킷은 VPN 반대편에 나타납니다. 그러나 질문하는 방식: (10.7.1.0/24 및 192.168.58.0/24의 컴퓨터가 통신할 수 있습니까?) "아니요" 대답을 강요합니다. 서로 다른(개인) 네트워크에 있는 컴퓨터가 서로 통신할 수 있는 유일한 방법은 NAT(Network Address Translation) 또는 유사한 방법을 통해 로컬 주소를 외부(원격) 주소로 변환하는 것입니다. 따라서 NAT의 각 끝은 동일한 네트워크 범위를 보게 됩니다. 위의 내용은 IPv4에만 적용됩니다. 이를 살펴보고 IPv6으로 확장해야 합니다.