ProHoster > блог > Администрација > Премин на OpenVPN на WireGuard да се комбинираат мрежи во една L2 мрежа

Премин на OpenVPN на WireGuard да се комбинираат мрежи во една L2 мрежа

Премин на OpenVPN на WireGuard да се комбинираат мрежи во една L2 мрежа

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

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

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

За да го пренасочам портот на рутерот каде што беше планирано да се распореди серверот, ја користев програмата sshtunnel. Нема да навлегувам во деталите за нејзината конфигурација - доста е лесна. Ќе напоменам само дека нејзината намена беше да го пренасочи 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-server, со додавање на следниов ред во неговата конфигурација:

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. Веднаш штом беше кажано, веднаш беше сторено. Сепак, сè додека MTU не беше поставена доволно високо - 7000 за gretap уредите - имав или прекинати TCP конекции или ниски брзини на пренос. Поради високиот MTU за gretap, MTU за конекции WireGuard Првото и второто ниво беа поставени на 8000 и 7500, соодветно.

Спроведов слично поставување на рутерот од станот 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 Mbps, а во другите станови е 5 Mbps. Покрај тоа, за време на користењето OpenVPN Не можев да постигнам брзина на пренос на податоци помеѓу мрежи поголема од 3,8 Mbps според iperf отчитувањата, додека WireGuard го „пумпаше“ до истите 5 Mbit/sec.

Конфигурација WireGuard на VPS[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>

[Врсник]
Јавен клуч = <VPN_1_MS_PUBLIC_KEY>
AllowedIPs = 192.168.30.2/32

[Врсник]
Јавен клуч = <VPN_2_MK2_PUBLIC_KEY>
AllowedIPs = 192.168.30.3/32

[Врсник]
Јавен клуч = <VPN_2_MK3_PUBLIC_KEY>
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

Купете доверлив хостинг за сајтови со DDoS заштита, VPS VDS сервери 🔥 Купете сигурен веб-хостинг со DDoS заштита, VPS VDS сервери | ProHoster