🥇Миграција од OpenVPN во WireGuard за комбинирање на мрежи во една L2 мрежа

Би сакал да го споделам моето искуство за комбинирање мрежи во три географски оддалечени апартмани, од кои секој користи рутери OpenWRT како порта, во една заедничка мрежа. При изборот на метод за комбинирање мрежи помеѓу L3 со рутирање на подмрежа и L2 со премостување, кога сите мрежни јазли ќе бидат во иста подмрежа, предност се даде на вториот метод, кој е потежок за конфигурирање, но дава поголеми можности, бидејќи беше планирано транспарентно користење на технологии во мрежата што се создава Wake-on-Lan и DLNA.

Дел 1: Позадина

OpenVPN првично беше избран како протокол за спроведување на оваа задача, бидејќи, прво, може да создаде уред за допир што може да се додаде на мостот без проблеми, и второ, OpenVPN поддржува работа преку протоколот TCP, што исто така беше важно, бидејќи ниту еден од становите имаа посветена IP адреса и не можев да користам STUN, бидејќи мојот провајдер поради некоја причина ги блокира дојдовните UDP конекции од нивните мрежи, додека протоколот TCP ми дозволи да ја препратам портата за серверот VPN до изнајмениот VPS користејќи SSH. Да, овој пристап дава големо оптоварување, бидејќи податоците се шифрираат двапати, но не сакав да воведам VPS во мојата приватна мрежа, бидејќи сè уште постоеше ризик трети лица да добијат контрола над него, затоа, да има таков уред на мојата домашна мрежа беше крајно непожелно и беше одлучено да се плати за безбедност со големи трошоци.

За препраќање на портот на рутерот на кој беше планирано да се распореди серверот, беше искористена програмата штунел. Нема да ги опишам сложеноста на неговата конфигурација - тоа е направено прилично лесно, само ќе забележам дека неговата задача беше да ја препрати TCP портата 1194 од рутерот до VPS. Следно, серверот OpenVPN беше конфигуриран на уредот tap0, кој беше поврзан со мостот br-lan. Откако ја проверив врската со новосоздадениот сервер од лаптопот, стана јасно дека идејата за пренасочување на портата е оправдана и мојот лаптоп стана член на мрежата на рутерот, иако физички не беше во него.

Остана само една мала работа: беше неопходно да се дистрибуираат 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

Оваа конфигурација траеше три години.

Дел 2: Воведување на WireGuard

Неодамна, луѓето на Интернет сè повеќе почнаа да зборуваат за WireGuard, восхитувајќи се на едноставноста на неговата конфигурација, голема брзина на пренос, низок пинг со споредлива безбедност. Пребарувањето повеќе информации за него стана јасно дека ниту работата како член на мостот ниту работата преку протоколот TCP не беа поддржани од него, што ме натера да мислам дека сè уште нема алтернативи за OpenVPN за мене. Затоа го одложив запознавањето со WireGuard.

Пред неколку дена, вестите се проширија низ ресурсите на еден или друг начин поврзани со ИТ дека WireGuard конечно ќе биде вклучен во кернелот на Linux, почнувајќи од верзијата 5.6. Новинските написи, како и секогаш, го пофалија WireGuard. Повторно се втурнав во потрага по начини да го заменам стариот добар OpenVPN. Овој пат налетав овој член,. Зборуваше за создавање на етернет тунел преку L3 користејќи GRE. Оваа статија ми даде надеж. Остана нејасно што да се прави со протоколот UDP. Пребарувањето ме доведе до написи за користење на socat во врска со тунел SSH за проследување на UDP порта, сепак, тие забележаа дека овој пристап работи само во режим на едно поврзување, односно работата на неколку VPN клиенти ќе биде невозможна. Дојдов до идеја да инсталирам VPN сервер на VPS и да поставам GRE за клиенти, но како што се испостави, GRE не поддржува шифрирање, што ќе доведе до фактот дека ако трети лица добијат пристап до серверот , целиот сообраќај помеѓу моите мрежи ќе биде во нивни раце, што воопшто не ми одговараше.

Уште еднаш, одлуката беше донесена во корист на вишок шифрирање, со користење на VPN преку VPN користејќи ја следнава шема:

Ниво XNUMX VPN:
VPS е сервер со внатрешна адреса 192.168.30.1
MS е клиент VPS со внатрешна адреса 192.168.30.2
МК2 е клиент VPS со внатрешна адреса 192.168.30.3
МК3 е клиент VPS со внатрешна адреса 192.168.30.4

VPN од второ ниво:
MS е сервер со надворешна адреса 192.168.30.2 и внатрешна 192.168.31.1
МК2 е клиент MS со адреса 192.168.30.2 и има внатрешна IP 192.168.31.2
МК3 е клиент MS со адреса 192.168.30.2 и има внатрешна IP 192.168.31.3

* MS — рутер-сервер во стан 1, МК2 - рутер во стан 2, МК3 - рутер во стан 3
* Конфигурациите на уредот се објавени во спојлерот на крајот од статијата.

И така, пинговите се извршуваат помеѓу мрежните јазли 192.168.31.0/24, време е да се продолжи кон поставување на тунел GRE. Пред ова, за да не се изгуби пристапот до рутерите, вреди да се постават SSH тунели за препраќање на портата 22 до VPS, така што, на пример, рутерот од стан 10022 ќе биде достапен на портата 2 на VPS, а рутерот од станот 11122 ќе биде достапен на рутерот порта 3 од станот XNUMX. Најдобро е да го конфигурирате препраќањето користејќи го истиот штунел, бидејќи ќе го врати тунелот ако не успее.

Тунелот е конфигуриран, можете да се поврзете со SSH преку препратената порта:

ssh root@МОЙ_VPS -p 10022

Следно, треба да го оневозможите OpenVPN:

/etc/init.d/openvpn stop

Сега ајде да поставиме тунел GRE на рутерот од стан 2:

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

почнувајќи од овој момент, пинговите почнуваат успешно да одат на новата мрежа и јас задоволна одам да пијам кафе. Потоа, за да проценам како работи мрежата на другиот крај од линијата, се обидувам да внесам SSH во еден од компјутерите во стан 2, но ssh клиентот се замрзнува без да бара лозинка. Се обидувам да се поврзам со овој компјутер преку телнет на порта 22 и гледам линија од која можам да разберам дека врската се воспоставува, SSH серверот реагира, но поради некоја причина едноставно не ме поттикнува да се логирам во.

$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1

Се обидувам да се поврзам со него преку VNC и да видам црн екран. Се убедувам дека проблемот е со далечинскиот компјутер, бидејќи лесно можам да се поврзам со рутерот од овој стан користејќи ја внатрешната адреса. Сепак, решавам да се поврзам со SSH на овој компјутер преку рутерот и изненаден сум кога открив дека врската е успешна, а далечинскиот компјутер работи сосема нормално, но исто така не може да се поврзе со мојот компјутер.

Го отстранувам уредот grelan0 од мостот и го стартувам OpenVPN на рутерот во стан 2 и внимавам мрежата повторно да работи како што се очекува и да не се испуштаат врските. Со пребарувањето наидувам на форуми каде што луѓето се жалат на истите проблеми, каде што им се советува да го подигнат МТУ. Не порано кажано отколку направено. Сепак, додека MTU не беше поставен доволно високо - 7000 за gretap уреди, беа забележани или испуштени TCP конекции или ниски стапки на пренос. Поради високиот MTU за gretap, MTU за Layer 8000 и Layer 7500 WireGuard врски беа поставени на XNUMX и XNUMX соодветно.

Спроведов слично поставување на рутерот од станот 3, со единствената разлика што беше додаден втор интерфејс за gretap наречен grelan1 на рутерот на серверот, кој исто така беше додаден на мостот br-lan.

Сè работи. Сега можете да го ставите склопот на gretap во стартување. За ова:

Ги поставив овие линии во /etc/rc.local на рутерот во стан 2:

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

Го додадов ова во /etc/rc.local на рутерот во стан 3:

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

Сумирањето

Сè уште не сум постигнал целосно напуштање на OpenVPN, бидејќи понекогаш ми треба да се поврзам на нова мрежа од лаптоп или телефон, а поставувањето уред за gretap на нив е генерално невозможно, но и покрај ова, добив предност во брзината преносот на податоци помеѓу становите и, на пример, користењето VNC веќе не е незгодно. Пингот малку се намали, но стана постабилен:

Кога користите 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

Тоа е повеќе погодено од високиот пинг до VPS, што е приближно 61.5 ms

Сепак, брзината е значително зголемена. Значи, во стан со сервер рутер имам брзина на интернет конекција од 30 Mbit/sec, а во другите станови е 5 Mbit/sec. Во исто време, додека користев OpenVPN, не можев да постигнам брзина на пренос на податоци помеѓу мрежите поголема од 3,8 Mbit/sec според читањата на iperf, додека WireGuard го „засили“ на истите 5 Mbit/sec.

Конфигурација на WireGuard на VPS[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

Конфигурација на WireGuard на MS (додадена во /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'

Конфигурација на WireGuard на MK2 (додадена во /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'

Конфигурација на WireGuard на MK3 (додадена во /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. Во теорија, тоа не е неопходно, бидејќи клиентот ќе воспостави врска од која било бесплатна непривилегирана порта, но јас го направив тоа така што беше можно да се забрани сите дојдовни врски на wg0 интерфејсите на сите рутери освен дојдовните UDP конекции до портата 51821.

Се надевам дека статијата ќе биде корисна за некого.

PS Исто така, сакам да ја споделам мојата скрипта што ми испраќа PUSH известување до мојот телефон во апликацијата WirePusher кога ќе се појави нов уред на мојата мрежа. Еве ја врската до сценариото: github.com/r0ck3r/device_discover.

Ажурирање: Конфигурација на 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 за генерирање сертификати

Извор: www.habr.com

Префрлување од OpenVPN на WireGuard за комбинирање на мрежи во една L2 мрежа

Дел 1: Позадина

Дел 2: Воведување на WireGuard

Сумирањето

Додадете коментар Откажи одговор