Ես կցանկանայի կիսվել աշխարհագրորեն հեռավոր երեք բնակարաններում ցանցերը միավորելու իմ փորձով, որոնցից յուրաքանչյուրը օգտագործում է 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 սերվերի հաճախորդի երթուղիչներին՝ ավելացնելով տողը դրա կազմաձևում.
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-ի մասին՝ հիանալով դրա կազմաձևման պարզությամբ, փոխանցման բարձր արագությամբ, ցածր ping-ով՝ համեմատելի անվտանգությամբ: Դրա մասին լրացուցիչ տեղեկությունների որոնումը պարզ դարձրեց, որ ոչ որպես կամուրջի անդամ աշխատելը, ոչ էլ TCP արձանագրության վրա աշխատելը դրանով չի աջակցվում, ինչը ինձ ստիպեց մտածել, որ OpenVPN-ին ինձ համար դեռ այլընտրանքներ չկան: Այսպիսով, ես հետաձգեցի WireGuard-ի հետ ծանոթանալը:
Մի քանի օր առաջ ՏՏ-ի հետ կապված այս կամ այն կերպ ռեսուրսներում լուրեր տարածվեցին, որ WireGuard-ը վերջապես կներառվի Linux-ի միջուկում՝ սկսած 5.6 տարբերակից: Լրատվական հոդվածները, ինչպես միշտ, գովաբանում էին WireGuard-ին: Ես նորից ընկա հին լավ OpenVPN-ի փոխարինման ուղիների որոնման մեջ: Այս անգամ բախվեցի . Այն խոսում էր GRE-ի միջոցով L3-ի վրայով Ethernet թունելի ստեղծման մասին: Այս հոդվածն ինձ հույս տվեց: Անհասկանալի մնաց, թե ինչ անել UDP արձանագրության հետ: Որոնումն ինձ հանգեցրեց հոդվածների այն մասին, թե ինչպես օգտագործել socat-ը SSH թունելի հետ UDP նավահանգիստ փոխանցելու համար, այնուամենայնիվ, նրանք նշեցին, որ այս մոտեցումն աշխատում է միայն մեկ կապի ռեժիմում, այսինքն՝ մի քանի VPN հաճախորդների աշխատանքը անհնար կլինի: Ես հղացա VPS-ի վրա VPN սերվեր տեղադրելու և հաճախորդների համար GRE տեղադրելու գաղափարը, բայց ինչպես պարզվեց, GRE-ն չի աջակցում կոդավորումը, ինչը կհանգեցնի նրան, որ եթե երրորդ կողմերը մուտք գործեն սերվեր: , իմ ցանցերի միջև ամբողջ տրաֆիկը կլինի նրանց ձեռքում, ինչը ինձ բոլորովին չէր սազում:
Եվս մեկ անգամ որոշում է կայացվել հօգուտ ավելորդ կոդավորման՝ VPN-ի վրա VPN-ի միջոցով օգտագործելով հետևյալ սխեմա.
Մակարդակ XNUMX VPN.
VPS է սերվեր ներքին 192.168.30.1 հասցեով
MS է հաճախորդ VPS ներքին հասցեով 192.168.30.2
MK2 է հաճախորդ VPS ներքին հասցեով 192.168.30.3
MK3 է հաճախորդ VPS ներքին հասցեով 192.168.30.4
Երկրորդ մակարդակի 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 բնակարանում
* Սարքի կոնֆիգուրացիաները հրապարակված են հոդվածի վերջում գտնվող սփոյլերում:
Եվ այսպես, ping-երը աշխատում են ցանցային 192.168.31.0/24 հանգույցների միջև, ժամանակն է անցնել GRE թունելի ստեղծմանը: Մինչ այս, որպեսզի չկորցնեք մուտքը դեպի երթուղիչներ, արժե տեղադրել SSH թունելներ 22-րդ նավահանգիստը VPS-ին փոխանցելու համար, որպեսզի, օրինակ, 10022-րդ բնակարանի երթուղիչը հասանելի լինի VPS-ի 2 նավահանգստում, և Բնակարան 11122-ի երթուղիչը հասանելի կլինի 3 նավահանգստի երթուղիչով XNUMX-րդ բնակարանից: Լավագույնն այն է, որ կարգավորեք վերահասցեավորումը՝ օգտագործելով նույն sshtunnel-ը, քանի որ այն կվերականգնի թունելը, եթե այն ձախողվի:
Թունելը կազմաձևված է, կարող եք միանալ 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 հաճախորդը սառչում է առանց գաղտնաբառ պահանջելու: Ես փորձում եմ միանալ այս համակարգչին telnet-ի միջոցով պորտ 22-ում և տեսնում եմ մի գիծ, որտեղից կարող եմ հասկանալ, որ կապը հաստատվում է, SSH սերվերը արձագանքում է, բայց ինչ-ինչ պատճառներով դա ինձ պարզապես չի հուշում մուտք գործել: մեջ
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
Ես փորձում եմ միանալ դրան VNC-ի միջոցով և տեսնել սև էկրան: Ես ինքս ինձ համոզում եմ, որ խնդիրը հեռակառավարվող համակարգչի հետ է, քանի որ ես հեշտությամբ կարող եմ միանալ երթուղիչին այս բնակարանից՝ օգտագործելով ներքին հասցեն։ Այնուամենայնիվ, ես որոշում եմ միանալ այս համակարգչի SSH-ին երթուղիչի միջոցով և զարմացած եմ, երբ տեսնում եմ, որ կապը հաջող է, և հեռակառավարվող համակարգիչը աշխատում է բավականին նորմալ, բայց այն նաև չի կարող միանալ իմ համակարգչին:
Ես հեռացնում եմ grelan0 սարքը կամրջից և գործարկում OpenVPN-ը բնակարան 2-ի երթուղիչի վրա և համոզվում, որ ցանցը նորից աշխատում է այնպես, ինչպես սպասվում էր, և միացումները չեն անջատվում: Փնտրելով ես հանդիպում եմ ֆորումների, որտեղ մարդիկ բողոքում են նույն խնդիրներից, որտեղ նրանց խորհուրդ է տրվում բարձրացնել MTU-ն: Ոչ շուտ ասել, քան արվել: Այնուամենայնիվ, քանի դեռ MTU-ն բավականաչափ բարձր չէր սահմանվել՝ 7000 gretap սարքերի համար, նկատվում էին կա՛մ TCP միացումներ, կա՛մ փոխանցման ցածր արագություն: Շնորհիվ gretap-ի բարձր MTU-ի, Layer 8000-ի և Layer 7500-ի WireGuard կապերի MTU-ները սահմանվել են համապատասխանաբար XNUMX և XNUMX:
Ես նմանատիպ կարգավորում իրականացրեցի երթուղիչի վրա բնակարան 3-ից, միակ տարբերությամբ, որ սերվերի երթուղիչին ավելացվեց grelan1 անունով երկրորդ gretap ինտերֆեյսը, որը նույնպես ավելացվեց 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-ի օգտագործումն այլևս անհարմար չէ: 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
Դրա վրա ավելի շատ ազդում է VPS-ի բարձր պինգը, որը մոտավորապես 61.5 ms է
Սակայն արագությունը զգալիորեն աճել է։ Այսպիսով, սերվերային երթուղղիչ ունեցող բնակարանում ես ունեմ ինտերնետ կապի արագությունը 30 Մբիտ/վրկ, իսկ մյուս բնակարաններում այն 5 Մբիթ/վրկ է։ Միևնույն ժամանակ, OpenVPN-ն օգտագործելիս ես չկարողացա հասնել տվյալների փոխանցման արագություն ցանցերի միջև ավելի քան 3,8 Մբիթ/վրկ՝ ըստ iperf-ի ընթերցումների, մինչդեռ WireGuard-ը «խթանեց» այն նույն 5 Մբիթ/վրկ։
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 ինտերֆեյսներում, բացառությամբ 51821 նավահանգստի մուտքային UDP միացումների:
Հուսով եմ, որ հոդվածը օգտակար կլինի ինչ-որ մեկին:
PS Նաև ես ուզում եմ կիսվել իմ սկրիպտով, որն ինձ PUSH ծանուցում է ուղարկում իմ հեռախոսին WirePusher հավելվածում, երբ իմ ցանցում նոր սարք է հայտնվում: Ահա սցենարի հղումը. .
ԹԱՐՄԱՑՆԵԼ: 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-lzoOpenVPN հաճախորդ
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 սերտիֆիկատներ ստեղծելու համար
Source: www.habr.com