Ես կցանկանայի կիսվել աշխարհագրորեն հեռավոր երեք բնակարաններում ցանցերը միավորելու իմ փորձով, որոնցից յուրաքանչյուրը օգտագործում է 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: Դժբախտաբար, իմ firmware-ը չէր ներառում այն, ուստի ես ստիպված էի վերակառուցել պատկերները յուրաքանչյուր սարքի համար: Սա անելուց և յուրաքանչյուր ռաութերի /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Այս անգամ ես հանդիպեցի . Այն խոսում էր 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-ի պատճառով, կապերի MTU-ն... WireGuard Առաջին և երկրորդ մակարդակները սահմանվել են համապատասխանաբար 8000 և 7500:
Ես նմանատիպ կարգավորում իրականացրեցի երթուղիչի վրա բնակարան 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-ի՞, թե՞ 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>
[Հասակակից]
Հանրային բանալի = <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 ինտերֆեյսների վրա, բացառությամբ 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
