네트워크를 하나의 L2 네트워크로 통합하기 위해 OpenVPN에서 WireGuard로 마이그레이션

OpenWRT를 게이트웨이로 사용하는 라우터를 각각 사용하는 지리적으로 떨어진 3개의 아파트에서 네트워크를 하나의 공통 네트워크로 결합한 경험을 공유하고 싶습니다. 서브넷 라우팅이 있는 L2와 브리징이 있는 LXNUMX 사이의 네트워크를 결합하는 방법을 선택할 때 모든 네트워크 노드가 동일한 서브넷에 있을 때 구성하기가 더 어렵지만 투명하기 때문에 더 많은 기회를 제공하는 두 번째 방법이 선호되었습니다. 생성된 네트워크 Wake-on-Lan 및 DLNA에서 기술 사용이 계획되었습니다.

파트 1: 배경

OpenVPN은 처음에 이 작업을 구현하기 위한 프로토콜로 선택되었습니다. 첫 번째로 아무 문제 없이 브리지에 추가할 수 있는 탭 장치를 생성할 수 있고 두 번째로 OpenVPN이 TCP 프로토콜을 통한 작업을 지원하기 때문입니다. 어떤 아파트에도 전용 IP 주소가 없었고 STUN을 사용할 수 없었습니다. 어떤 이유로 ISP가 네트워크에서 들어오는 UDP 연결을 차단하고 TCP 프로토콜을 통해 SSH를 사용하여 임대한 VPS에서 VPN 서버 포트를 전달할 수 있었기 때문입니다. 예, 이 접근 방식은 데이터가 두 번 암호화되기 때문에 큰 부하를 주지만 제 XNUMX자가 여전히 제어할 위험이 있기 때문에 VPS를 개인 네트워크에 도입하고 싶지 않았습니다. 홈 네트워크의 장치는 매우 바람직하지 않았고 큰 오버헤드가 있는 보안 비용을 지불하기로 결정했습니다.

서버를 배포할 라우터의 포트를 전달하기 위해 sshtunnel 프로그램이 사용되었습니다. 구성의 복잡성에 대해서는 설명하지 않겠습니다. 이것은 매우 쉽게 수행됩니다. 그 작업은 라우터에서 VPS로 TCP 포트 1194를 전달하는 것입니다. 다음으로 br-lan 브리지에 연결된 tap0 장치에 OpenVPN 서버를 구성했습니다. 랩톱에서 새로 생성 된 서버에 대한 연결을 확인한 후 포트 포워딩에 대한 아이디어 자체가 정당하고 내 랩톱이 물리적으로는 아니지만 라우터 네트워크의 구성원이 된 것이 분명해졌습니다.

해야 할 일이 하나 남았습니다. IP 주소가 충돌하지 않도록 여러 아파트에 배포하고 라우터를 OpenVPN 클라이언트로 구성하는 것이 필요했습니다.
다음 라우터 IP 주소 및 DHCP 서버 범위가 선택되었습니다.

• 192.168.10.1 범위 포함 192.168.10.2 - 192.168.10.80 서버용
• 192.168.10.100 범위 포함 192.168.10.101 - 192.168.10.149 2호 아파트 라우터용
• 192.168.10.150 범위 포함 192.168.10.151 - 192.168.10.199 3호 아파트 라우터용

또한 해당 구성에 라인을 추가하여 OpenVPN 서버의 클라이언트 라우터에 이러한 주소를 정확히 할당해야 했습니다.

ifconfig-pool-persist /etc/openvpn/ipp.txt 0

/etc/openvpn/ipp.txt 파일에 다음 줄을 추가합니다.

flat1_id 192.168.10.100
flat2_id 192.168.10.150

여기서 flat1_id 및 flat2_id는 OpenVPN에 연결하기 위한 인증서를 생성할 때 지정된 장치 이름입니다.

다음으로 라우터에서 OpenVPN 클라이언트를 구성하고 둘 다에 있는 tap0 장치를 br-lan 브리지에 추가했습니다. 이 단계에서는 세 개의 네트워크가 모두 서로를 보고 전체적으로 작동하기 때문에 모든 것이 정상인 것처럼 보였습니다. 그러나 그다지 유쾌하지 않은 세부 사항이 밝혀졌습니다. 때때로 장치는 라우터가 아닌 IP 주소를 얻을 수 있으며 모든 후속 결과가 발생합니다. 어떤 이유로 아파트 중 하나의 라우터가 DHCPDISCOVER에 제 시간에 응답할 시간이 없었고 장치가 잘못된 주소를 받았습니다. 나는 각 라우터의 tap0에서 이러한 요청을 필터링해야 한다는 것을 깨달았지만 결과적으로 iptables는 장치가 브리지의 일부인 경우 장치와 함께 작동할 수 없으며 ebtables가 나를 구해야 합니다. 유감스럽게도 내 펌웨어에는 없었으며 각 장치의 이미지를 다시 빌드해야 했습니다. 이렇게 하고 각 라우터의 /etc/rc.local에 다음 줄을 추가하면 문제가 해결됩니다.

ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP

이 구성은 XNUMX년 동안 지속되었습니다.

2부: WireGuard 소개

최근 인터넷은 WireGuard에 대해 점점 더 많이 이야기하고 있으며 구성의 단순성, 높은 전송 속도, 유사한 보안으로 낮은 핑에 감탄했습니다. 그것에 대한 더 많은 정보를 검색한 결과 브리지 구성원으로 작동하거나 TCP 프로토콜을 통한 작업이 지원되지 않는다는 것이 분명해졌기 때문에 여전히 OpenVPN에 대한 대안이 없다고 생각했습니다. 그래서 WireGuard를 알게 되는 것을 미뤘습니다.

며칠 전 IT와 관련된 리소스를 통해 WireGuard가 마침내 버전 5.6부터 Linux 커널에 포함될 것이라는 소식이 퍼졌습니다. 항상 그렇듯이 뉴스 기사는 WireGuard를 칭찬했습니다. 나는 좋은 오래된 OpenVPN을 대체할 방법을 찾기 위해 다시 뛰어들었습니다. 이번에 나는 달려들었다. 이 문서. GRE를 사용하여 L3를 통한 이더넷 터널 생성에 대해 이야기했습니다. 이 기사는 나에게 희망을 주었다. UDP 프로토콜로 무엇을 해야 할지 불분명했습니다. 검색 결과 UDP 포트를 전달하기 위해 SSH 터널과 함께 socat을 사용하는 방법에 대한 기사가 나왔지만 이 접근 방식은 단일 연결 모드에서만 작동하므로 여러 VPN 클라이언트가 불가능하다는 의미입니다. VPS에 VPN 서버를 설정하고 클라이언트에 GRE를 설정하는 아이디어를 생각해 냈지만 알고 보니 GRE는 암호화를 지원하지 않기 때문에 제XNUMX자가 서버에 액세스할 경우 , 내 네트워크 간의 모든 트래픽은 나에게 전혀 적합하지 않은 손에 있습니다.

다시 한 번, 다음 체계에 따라 VPN over VPN을 사용하여 중복 암호화를 선호하는 결정이 내려졌습니다.

레이어 XNUMX VPN:
VPS 이 섬기는 사람 내부 주소 192.168.30.1 포함
MS 이 고객 내부 주소가 192.168.30.2인 VPS
MK2 이 고객 내부 주소가 192.168.30.3인 VPS
MK3 이 고객 내부 주소가 192.168.30.4인 VPS

레이어 XNUMX VPN:
MS 이 섬기는 사람 외부 주소 192.168.30.2 및 내부 주소 192.168.31.1
MK2 이 고객 MS 주소는 192.168.30.2이고 내부 IP는 192.168.31.2입니다.
MK3 이 고객 MS 주소는 192.168.30.2이고 내부 IP는 192.168.31.3입니다.

* MS - 아파트 1의 라우터 서버, MK2 - 아파트 2의 라우터, MK3 - 아파트 3의 라우터
* 장치 구성은 기사 끝의 스포일러에 게시됩니다.

따라서 네트워크 192.168.31.0/24의 노드 간 ping이 발생하면 GRE 터널 설정으로 넘어갈 시간입니다. 그 전에 라우터에 대한 액세스 권한을 잃지 않으려면 포트 22를 VPS로 전달하도록 SSH 터널을 설정하는 것이 좋습니다. 예를 들어 아파트 10022의 라우터는 VPS의 포트 2에서 사용할 수 있습니다. 아파트 11122의 라우터는 VPS의 포트 3에서 사용할 수 있습니다 아파트 XNUMX의 라우터 라우터가 떨어질 경우 터널을 복원하므로 동일한 sshtunnel로 포워딩을 구성하는 것이 가장 좋습니다.

터널이 구성되면 전달된 포트를 통해 SSH에 연결할 수 있습니다.

ssh root@МОЙ_VPS -p 10022

다음으로 OpenVPN을 비활성화합니다.

/etc/init.d/openvpn stop

이제 아파트 2의 라우터에 GRE 터널을 설정해 보겠습니다.

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up

그리고 생성된 인터페이스를 브리지에 추가합니다.

brctl addif br-lan grelan0

서버 라우터에서 유사한 절차를 수행해 보겠습니다.

ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up

또한 생성된 인터페이스를 브리지에 추가합니다.

brctl addif br-lan grelan0

이 순간부터 핑이 성공적으로 새 네트워크로 이동하기 시작하고 나는 만족스럽게 커피를 마시러갑니다. 그런 다음 회선의 다른 쪽 끝에서 네트워크가 어떻게 작동하는지 확인하기 위해 아파트 2에 있는 컴퓨터 중 하나에 SSH를 시도했지만 ssh 클라이언트는 암호를 묻지 않고 정지됩니다. 포트 22에서 텔넷을 통해 이 컴퓨터에 연결을 시도하고 연결이 설정되고 있음을 이해할 수 있는 라인이 표시되고 SSH 서버가 응답하지만 어떤 이유로 입력할 수 없습니다.

$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1

VNC를 통해 연결하려고 하는데 검은색 화면이 표시됩니다. 내부 주소를 사용하여 이 아파트에서 라우터에 쉽게 연결할 수 있기 때문에 문제가 원격 컴퓨터에 있다고 스스로 확신합니다. 그러나 라우터를 통해 이 컴퓨터에 SSH로 연결하기로 결정하고 연결이 성공하고 원격 컴퓨터가 제대로 작동하지만 내 컴퓨터에 연결하지 못하는 것을 보고 놀랐습니다.

브리지에서 grelan0 장치를 꺼내 아파트 2의 라우터에서 OpenVPN을 시작하고 네트워크가 다시 제대로 작동하고 연결이 끊기지 않는지 확인합니다. 검색 중 사람들이 동일한 문제에 대해 불평하고 MTU를 높이라는 조언을 받는 포럼을 발견했습니다. 말한 것보다 빨리. 그러나 MTU가 gretap 장치에 대해 충분히 큰 값인 7000으로 설정될 때까지 TCP 연결이 끊어지거나 느린 전송이 관찰되었습니다. gretap에 대한 높은 MTU로 인해 첫 번째 및 두 번째 수준의 WireGuard 연결에 대한 MTU는 각각 8000 및 7500으로 설정되었습니다.

나는 아파트 3의 라우터에서 비슷한 설정을 수행했으며 유일한 차이점은 grelan1이라는 두 번째 gretap 인터페이스가 서버 라우터에 추가되었고 br-lan 브리지에도 추가되었다는 것입니다.

모든 것이 작동합니다. 이제 gretap 어셈블리를 자동 로드에 넣을 수 있습니다. 이를 위해:

아파트 2에 있는 라우터의 /etc/rc.local에 다음 줄을 배치했습니다.

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0

이것을 아파트 3의 라우터에 있는 /etc/rc.local에 추가했습니다.

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0

그리고 서버 라우터에서:

ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0

ip link add grelan1 type gretap remote 192.168.31.3 local 192.168.31.1
ip link set dev grelan1 mtu 7000
ip link set grelan1 up
brctl addif br-lan grelan1

클라이언트 라우터를 재부팅한 후 어떤 이유로 서버에 연결되지 않는 것을 발견했습니다. SSH에 연결하면(다행히도 이전에 이를 위해 sshtunnel을 구성했습니다) WireGuard가 어떤 이유로 엔드포인트에 대한 경로를 생성하지만 올바르지 않은 것으로 나타났습니다. 따라서 192.168.30.2의 경우 경로 테이블은 pppoe-wan 인터페이스, 즉 인터넷을 통해 경로 테이블에 지정되었지만 경로는 wg0 인터페이스를 통해 지정되어야 합니다. 이 경로를 삭제한 후 연결이 복원되었습니다. WireGuard가 이러한 경로를 만들지 않도록 강제하는 방법에 대한 지침을 찾을 수 없습니다. 또한 이것이 OpenWRT의 기능인지 WireGuard 자체의 기능인지조차 이해하지 못했습니다. 오랜 시간 동안 이 문제를 처리할 필요 없이 타이머에 의해 반복되는 스크립트에서 이 경로를 삭제하는 줄을 두 라우터에 간단히 추가했습니다.

route del 192.168.30.2

최대 합계

나는 때때로 랩톱이나 전화에서 새 네트워크에 연결해야하고 일반적으로 gretap 장치를 설정하는 것이 불가능하기 때문에 OpenVPN을 완전히 거부하지는 않았지만 데이터 전송에서 이점을 얻었습니다. 예를 들어 VNC를 사용하는 것이 더 이상 불편하지 않습니다. Ping이 약간 감소했지만 더 안정적이 되었습니다.

OpenVPN을 사용하는 경우:

[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=133 ms
...
64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=125 ms

--- 192.168.10.110 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19006ms
rtt min/avg/max/mdev = 124.722/126.152/136.907/3.065 ms

WireGuard를 사용하는 경우:

[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=124 ms
...
64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=124 ms
--- 192.168.10.110 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19003ms
rtt min/avg/max/mdev = 123.954/124.423/126.708/0.675 ms

주로 약 61.5ms인 VPS에 대한 높은 핑의 영향을 받습니다.

그러나 속도는 크게 증가했습니다. 따라서 라우터 서버가 있는 아파트에서는 ​​인터넷 연결 속도가 30Mbps이고 다른 아파트에서는 ​​5Mbps입니다. 동시에 OpenVPN을 사용하는 동안 iperf에 따르면 3,8Mbps 이상의 네트워크 간 데이터 전송 속도를 달성할 수 없었지만 WireGuard는 동일한 5Mbps까지 "펌핑"했습니다.

VPS의 WireGuard 구성[Interface] Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>

[Peer] PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_1_МС>
AllowedIPs = 192.168.30.2/32

[Peer] PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК2>
AllowedIPs = 192.168.30.3/32

[Peer] PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК3>
AllowedIPs = 192.168.30.4/32

MS의 WireGuard 구성(/etc/config/network에 추가됨)

#VPN первого уровня - клиент
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.2/24'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МС'
        option auto '1'
        option mtu '8000'

config wireguard_wg0
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
        option endpoint_port '51820'
        option route_allowed_ips '1'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP_АДРЕС_VPS'

#VPN второго уровня - сервер
config interface 'wg1'
        option proto 'wireguard'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
        option listen_port '51821'
        list addresses '192.168.31.1/24'
        option auto '1'
        option mtu '7500'

config wireguard_wg1
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК2'
        list allowed_ips '192.168.31.2'

config wireguard_wg1ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3

        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК3'
        list allowed_ips '192.168.31.3'

MK2의 WireGuard 구성(/etc/config/network에 추가됨)

#VPN первого уровня - клиент
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.3/24'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МК2'
        option auto '1'
        option mtu '8000'

config wireguard_wg0
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
        option endpoint_port '51820'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP_АДРЕС_VPS'

#VPN второго уровня - клиент
config interface 'wg1'
        option proto 'wireguard'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МК2'
        list addresses '192.168.31.2/24'
        option auto '1'
        option listen_port '51821'
        option mtu '7500'

config wireguard_wg1
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
        option endpoint_host '192.168.30.2'
        option endpoint_port '51821'
        option persistent_keepalive '25'
        list allowed_ips '192.168.31.0/24'

MK3의 WireGuard 구성(/etc/config/network에 추가됨)

#VPN первого уровня - клиент
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.4/24'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МК3'
        option auto '1'
        option mtu '8000'

config wireguard_wg0
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
        option endpoint_port '51820'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP_АДРЕС_VPS'

#VPN второго уровня - клиент
config interface 'wg1'
        option proto 'wireguard'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МК3'
        list addresses '192.168.31.3/24'
        option auto '1'
        option listen_port '51821'
        option mtu '7500'

config wireguard_wg1
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
        option endpoint_host '192.168.30.2'
        option endpoint_port '51821'
        option persistent_keepalive '25'
        list allowed_ips '192.168.31.0/24'

두 번째 수준 VPN에 대해 설명된 구성에서 WireGuard 클라이언트에 포트 51821을 지정합니다.이론적으로 이것은 클라이언트가 권한이 없는 무료 포트에서 연결을 설정하기 때문에 필요하지 않지만 들어오는 모든 연결이 포트 0에서 들어오는 UDP 연결을 제외하고 모든 라우터의 wg51821 인터페이스에서 거부될 수 있습니다.

이 기사가 누군가에게 유용하기를 바랍니다.

PS 또한 내 네트워크에 새 장치가 나타날 때 WirePusher 애플리케이션에서 내 전화로 PUSH 알림을 보내는 내 스크립트를 공유하고 싶습니다. 다음은 스크립트에 대한 링크입니다. github.com/r0ck3r/device_discover.

UPDATE : OpenVPN 서버 및 클라이언트 구성

OpenVPN 서버

client-to-client

ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/vpn-server.crt
dh /etc/openvpn/server/dh.pem
key /etc/openvpn/server/vpn-server.key

dev tap
ifconfig-pool-persist /etc/openvpn/ipp.txt 0
keepalive 10 60
proto tcp4
server-bridge 192.168.10.1 255.255.255.0 192.168.10.80 192.168.10.254
status /var/log/openvpn-status.log
verb 3
comp-lzo

OpenVPN 클라이언트

client
tls-client
dev tap
proto tcp
remote VPS_IP 1194 # Change to your router's External IP
resolv-retry infinite
nobind

ca client/ca.crt
cert client/client.crt
key client/client.key
dh client/dh.pem

comp-lzo
persist-tun
persist-key
verb 3

easy-rsa를 사용하여 인증서를 생성했습니다.

출처 : habr.com