ProHoster > Blog > Stjórnsýsla > Flutningur frá OpenVPN til WireGuard til að sameina netkerfi í eitt L2 net

Flutningur frá OpenVPN til WireGuard til að sameina netkerfi í eitt L2 net

Flutningur frá OpenVPN til WireGuard til að sameina netkerfi í eitt L2 net

Mig langar að deila reynslu minni af því að sameina netkerfi í þremur landfræðilega fjarlægum íbúðum, sem hver um sig notar beina með OpenWRT sem gátt, í eitt sameiginlegt net. Þegar valin var aðferð til að sameina net á milli L3 með undirnetsleið og L2 með brúun, þegar allir nethnútar verða í sama undirneti, var valinn seinni aðferðin, sem er erfiðara að stilla, en gefur fleiri tækifæri, þar sem gagnsæ notkun tækni var skipulögð í stofnuðu neti Wake-on-Lan og DLNA.

Hluti 1: Bakgrunnur

OpenVPN var upphaflega valið sem samskiptareglur til að útfæra þetta verkefni, þar sem í fyrsta lagi getur það búið til tappatæki sem hægt er að bæta við brúna án vandræða, og í öðru lagi styður OpenVPN aðgerð yfir TCP samskiptareglur, sem var líka mikilvægt, vegna þess að engin íbúðanna var með sérstakt IP-tölu, og ég gat ekki notað STUN, vegna þess að af einhverjum ástæðum hindrar ISP-inn minn komandi UDP-tengingar frá netkerfum sínum, á meðan TCP-samskiptareglur leyfðu mér að framsenda VPN netþjónsgáttina á leigðum VPS með SSH. Já, þessi nálgun gefur mikið álag, þar sem gögnin eru dulkóðuð tvisvar, en ég vildi ekki kynna VPS inn í einkanetið mitt, þar sem enn var hætta á að þriðju aðilar næðu yfirráðum yfir því, því að hafa slíkt tæki á heimanetinu var afar óæskilegt og ákveðið var að borga fyrir öryggi með miklum kostnaði.

Til að framsenda portið á beininum sem áætlað var að setja þjóninn á var sshtunnel forritið notað. Ég mun ekki lýsa ranghala stillingar þess - þetta er gert nokkuð auðveldlega, ég tek bara fram að verkefni þess var að senda TCP tengi 1194 frá leiðinni til VPS. Næst var OpenVPN þjónninn stilltur á tap0 tækinu, sem var tengt við br-lan brúna. Eftir að hafa athugað tenginguna við nýstofnaðan netþjón úr fartölvunni, varð ljóst að hugmyndin um framsendingu hafna réttlætti sig og fartölvan mín varð meðlimur netkerfis beinisins, þó að hún væri ekki líkamlega í henni.

Málið var enn lítið: það var nauðsynlegt að dreifa IP tölum í mismunandi íbúðir svo þær stanguðust ekki á og stilltu beinar sem OpenVPN viðskiptavinir.
Eftirfarandi IP tölur beinar og DHCP miðlarasvið voru valin:

  • 192.168.10.1 með svið 192.168.10.2 - 192.168.10.80 fyrir þjóninn
  • 192.168.10.100 með svið 192.168.10.101 - 192.168.10.149 fyrir router í íbúð nr
  • 192.168.10.150 með svið 192.168.10.151 - 192.168.10.199 fyrir router í íbúð nr

Það var líka nauðsynlegt að úthluta nákvæmlega þessum vistföngum til biðlarabeina OpenVPN netþjónsins með því að bæta línunni við uppsetningu hans:

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

og bætir eftirfarandi línum við /etc/openvpn/ipp.txt skrána:

flat1_id 192.168.10.100
flat2_id 192.168.10.150

þar sem flat1_id og flat2_id eru tækjanöfnin sem tilgreind eru þegar búið er til vottorð til að tengjast OpenVPN

Næst voru OpenVPN viðskiptavinir stilltir á beinunum, tap0 tækjunum á báðum var bætt við br-lan brúna. Á þessu stigi virtist allt vera í lagi, þar sem öll þrjú netin sjást og vinna sem ein heild. Hins vegar kom ekki mjög skemmtilegt smáatriði í ljós: stundum gátu tæki fengið IP-tölu sem ekki var frá beini sínum, með öllum þeim afleiðingum sem af því fylgdu. Einhverra hluta vegna hafði beininn í einni íbúðinni ekki tíma til að svara DHCPDISCOVER í tæka tíð og tækið fékk rangt heimilisfang. Ég áttaði mig á því að ég þarf að sía slíkar beiðnir í tap0 á hverjum router, en eins og það kom í ljós, geta iptables ekki virkað með tæki ef það er hluti af brú og ebtables ættu að koma mér til bjargar. Mér til eftirsjá var það ekki í vélbúnaðinum mínum og ég þurfti að endurbyggja myndirnar fyrir hvert tæki. Með því að gera þetta og bæta þessum línum við /etc/rc.local á hverri leið var vandamálið leyst:

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

Þessi uppsetning stóð í þrjú ár.

Part 2: Við kynnum WireGuard

Undanfarið hefur internetið í auknum mæli verið að tala um WireGuard, dást að einfaldleika uppsetningar þess, háum flutningshraða, lágu ping með sambærilegu öryggi. Leit að frekari upplýsingum um það gerði það ljóst að hvorki vinna sem brúarmeðlimur né vinna við TCP-samskiptareglur er studd af því, sem fékk mig til að halda að það væru enn engir kostir við OpenVPN fyrir mig. Svo ég fresta því að kynnast WireGuard.

Fyrir nokkrum dögum dreifðust þær fréttir í gegnum auðlindir á einn eða annan hátt sem tengjast upplýsingatækni að WireGuard verði loksins með í Linux kjarnanum, frá og með útgáfu 5.6. Fréttagreinar, eins og alltaf, lofuðu WireGuard. Ég hljóp aftur í leitina að leiðum til að skipta um gamla góða OpenVPN. Í þetta skiptið rakst ég á þessi grein. Það talaði um að búa til Ethernet göng yfir L3 með GRE. Þessi grein gaf mér von. Það var enn óljóst hvað ætti að gera við UDP siðareglur. Leit leiddi mig að greinum um að nota socat í tengslum við SSH göng til að framsenda UDP tengi, en þeir tóku fram að þessi aðferð virkar aðeins í einni tengingarham, sem þýðir að margir VPN viðskiptavinir væru ómögulegir. Ég kom með þá hugmynd að setja upp VPN netþjón á VPS og stilla GRE fyrir viðskiptavini, en eins og það kom í ljós þá styður GRE ekki dulkóðun, sem mun leiða til þess að ef þriðju aðilar fá aðgang að þjóninum, öll umferð milli neta minna er í þeirra höndum sem hentaði mér alls ekki.

Aftur var ákvörðunin tekin í þágu óþarfa dulkóðunar með því að nota VPN yfir VPN samkvæmt eftirfarandi kerfi:

Lag XNUMX VPN:
VPS er miðlara með innra heimilisfangi 192.168.30.1
MS er viðskiptavinur VPS með innra heimilisfangi 192.168.30.2
MK2 er viðskiptavinur VPS með innra heimilisfangi 192.168.30.3
MK3 er viðskiptavinur VPS með innra heimilisfangi 192.168.30.4

Layer XNUMX VPN:
MS er miðlara með ytra heimilisfang 192.168.30.2 og innra 192.168.31.1
MK2 er viðskiptavinur MS með heimilisfangið 192.168.30.2 og hefur innri IP 192.168.31.2
MK3 er viðskiptavinur MS með heimilisfangið 192.168.30.2 og hefur innri IP 192.168.31.3

* MS - leið-þjónn í íbúð 1, MK2 - beini í íbúð 2, MK3 - beini í íbúð 3
* Stillingar tækisins eru birtar í spoilernum í lok greinarinnar.

Og svo, ping milli hnúta netsins 192.168.31.0/24 go, það er kominn tími til að halda áfram að setja upp GRE göngin. Fyrir það, til að missa ekki aðgang að beinum, er rétt að setja upp SSH göng til að framsenda höfn 22 til VPS, þannig að t.d. beini frá íbúð 10022 verði tiltækur á höfn 2 í VPS, og a. beini frá íbúð 11122 verður fáanlegur á tengi 3 á VPS beini frá íbúð XNUMX. Best er að stilla áframsendinguna með sama sshtunnel, þar sem það mun endurheimta göngin ef það dettur.

Göngin eru stillt, þú getur tengst SSH í gegnum áframsendu höfnina:

ssh root@МОЙ_VPS -p 10022

Næst skaltu slökkva á OpenVPN:

/etc/init.d/openvpn stop

Nú skulum við setja upp GRE göng á beini frá íbúð 2:

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

Og bættu hinu búiða viðmóti við brúna:

brctl addif br-lan grelan0

Við skulum framkvæma svipaða aðferð á miðlarabeini:

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

Og bættu líka viðmótinu sem búið var til við brúna:

brctl addif br-lan grelan0

frá þessari stundu byrja pingar að fara í nýja netið og ég, ánægður, fer að drekka kaffi. Síðan, til að sjá hvernig netið á hinum enda vírsins virkar, reyni ég að SSH inn í eina af tölvunum í íbúð 2, en ssh biðlarinn frýs án þess að biðja mig um lykilorð. Ég reyni að tengjast þessari tölvu í gegnum telnet á port 22 og sé línu sem maður skilur af því að verið sé að koma á tengingunni, SSH server er að svara, en einhverra hluta vegna býður hann mér ekki inn.

$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1

Ég er að reyna að tengjast honum í gegnum VNC og ég sé svartan skjá. Ég sannfæri sjálfan mig um að málið sé í fjartölvunni, því ég get auðveldlega tengst beini frá þessari íbúð með því að nota innra heimilisfangið. Hins vegar ákveð ég að SSH inn í þessa tölvu í gegnum routerinn og er hissa að komast að því að tengingin heppnast og fjartölvan virkar fínt en nær ekki að tengjast tölvunni minni heldur.

Ég tek grelan0 tækið úr brúnni og ræsi OpenVPN á routernum í íbúð 2 og passa að netið sé að virka rétt aftur og tengingar falla ekki. Í leitinni rekst ég á spjallborð þar sem fólk kvartar yfir sömu vandamálum, þar sem því er ráðlagt að hækka MTU. Ekki fyrr sagt en gert. Hins vegar, þar til MTU var stillt á nógu stórt gildi upp á 7000 fyrir gretap tæki, sáust annaðhvort fallandi TCP tengingar eða hægar sendingar. Vegna mikils MTU fyrir gretap voru MTUs fyrir WireGuard tengingar á fyrsta og öðru stigi stillt á 8000 og 7500, í sömu röð.

Ég gerði svipaða uppsetningu á routernum frá íbúð 3, eini munurinn var sá að öðru gretap viðmóti að nafni grelan1 var bætt við server routerinn, sem einnig var bætt við br-lan brúna.

Allt er að virka. Nú geturðu sett gretap samsetninguna í sjálfvirka hleðslu. Fyrir þetta:

Setti þessar línur í /etc/rc.local á routernum í íbúð 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

Bætti þessu við /etc/rc.local á routernum í íbúð 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

Og á netþjónsleiðinni:

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

Eftir að hafa endurræst biðlarabeinana fann ég að einhverra hluta vegna tengdust þeir ekki við netþjóninn. Þegar ég tengdist SSH þeirra (sem betur fer hafði ég áður stillt sshtunnel fyrir þetta) kom í ljós að WireGuard af einhverjum ástæðum býr til leið fyrir endapunktinn á meðan það er rangt. Svo, fyrir 192.168.30.2, var leiðartaflan tilgreind í leiðartöflunni í gegnum pppoe-wan viðmótið, það er í gegnum internetið, þó leiðinni að henni hefði átt að vera beint í gegnum wg0 viðmótið. Eftir að þessari leið var eytt var tengingin endurheimt. Ég fann hvergi leiðbeiningar um hvernig á að þvinga WireGuard til að búa ekki til þessar leiðir. Þar að auki skildi ég ekki einu sinni hvort þetta er eiginleiki OpenWRT eða WireGuard sjálfs. Án þess að þurfa að takast á við þetta vandamál í langan tíma, bætti ég einfaldlega við báða leiðina í handriti sem var lykkjuð af tímamæli, línu sem eyddi þessari leið: 

route del 192.168.30.2

Samantekt

Ég hef ekki enn náð algerri höfnun á OpenVPN, þar sem ég þarf stundum að tengjast nýju neti úr fartölvu eða síma, og það er almennt ómögulegt að setja upp gretap tæki á þeim, en þrátt fyrir það fékk ég forskot í gagnaflutningi hraði á milli íbúða og til dæmis að nota VNC er ekki lengur óþægilegt. Ping minnkaði lítillega, en varð stöðugra:

Þegar þú notar 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

Þegar WireGuard er notað:

[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

Það er aðallega fyrir áhrifum af háu ping til VPS sem er um það bil 61.5 ms

Hins vegar hefur hraðinn aukist verulega. Svo, í íbúð með beini-miðlara, er ég með nettengingarhraða upp á 30 Mbps, og í öðrum íbúðum, 5 Mbps. Á sama tíma, meðan ég notaði OpenVPN, gat ég ekki náð gagnaflutningshraða milli neta sem var meira en 3,8 Mbps samkvæmt iperf, á meðan WireGuard „dældi“ því upp í sömu 5 Mbps.

WireGuard stillingar á 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 stillingar á MS (bætt við /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 stillingar á MK2 (bætt við /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 stillingar á MK3 (bætt við /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'

Í uppsetningunni sem lýst er fyrir VPN á öðru stigi, tilgreini ég tengi 51821 fyrir WireGuard viðskiptavini. Í orði er þetta ekki nauðsynlegt, þar sem viðskiptavinurinn mun koma á tengingu frá hvaða ókeypis tengi sem er án forréttinda, en ég gerði það þannig að allar komandi tengingar hægt að neita á wg0 tengi allra beina, nema komandi UDP tengingar á höfn 51821.

Ég vona að greinin nýtist einhverjum.

PS Einnig vil ég deila handritinu mínu sem sendir mér PUSH tilkynningu í símann minn í WirePusher forritinu þegar nýtt tæki birtist á netinu mínu. Hér er hlekkur á handritið: github.com/r0ck3r/device_discover.

UPDATE: OpenVPN netþjónn og stillingar viðskiptavina

OpenVPN netþjónn

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 viðskiptavinur

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

Ég notaði easy-rsa til að búa til vottorð.

Heimild: www.habr.com

Bæta við athugasemd