🥇მიგრაცია 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 როუტერისთვის No2 ბინაში
192.168.10.150 დიაპაზონით 192.168.10.151 - 192.168.10.199 როუტერისთვის No3 ბინაში

ასევე საჭირო იყო ზუსტად ამ მისამართების მინიჭება 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 უნდა დამეხმაროს. სამწუხაროდ, ეს არ იყო ჩემს 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-ის გაცნობას.

რამდენიმე დღის წინ, IT-თან ამა თუ იმ გზით გავრცელდა ინფორმაცია, რომ WireGuard საბოლოოდ ჩაერთვება Linux-ის ბირთვში, დაწყებული 5.6 ვერსიით. ახალი ამბების სტატიებმა, როგორც ყოველთვის, შეაქო WireGuard. მე ისევ ჩავძირე კარგი ძველი OpenVPN-ის შეცვლის გზების ძიებაში. ამჯერად შევვარდი ამ მუხლის. საუბარი იყო Ethernet გვირაბის შექმნაზე L3-ზე GRE-ის გამოყენებით. ამ სტატიამ იმედი მომცა. გაურკვეველი დარჩა რა უნდა გაეკეთებინა 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
* მოწყობილობის კონფიგურაციები გამოქვეყნებულია სტატიის ბოლოს სპოილერში.

ასე რომ, პინგები გადის ქსელის კვანძებს შორის 192.168.31.0/24, დროა გადავიდეთ GRE გვირაბის დაყენებაზე. მანამდე, იმისათვის, რომ არ დაკარგოთ წვდომა მარშრუტიზატორებზე, ღირს SSH გვირაბების დაყენება 22-ე პორტის VPS-ზე გადასატანად, ასე რომ, მაგალითად, როუტერი 10022 ბინადან ხელმისაწვდომი იქნება VPS-ის 2 პორტზე და როუტერი მე-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 სერვერი პასუხობს, მაგრამ რატომღაც უბრალოდ არ მთხოვს შესვლას in.

$ 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 8000 და 7500 ფენის WireGuard კავშირებისთვის დაყენებული იყო XNUMX და XNUMX შესაბამისად.

მე განვახორციელე მსგავსი დაყენება როუტერზე მე-3 აპარტამენტიდან, ერთადერთი განსხვავებით, რომ სერვერის როუტერს დაემატა მეორე gretap ინტერფეისი სახელად grelan1, რომელიც ასევე დაემატა br-lan bridge-ს.

ყველაფერი მუშაობს. ახლა თქვენ შეგიძლიათ ჩართოთ 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 აპლიკაციაში, როდესაც ჩემს ქსელში ახალი მოწყობილობა გამოჩნდება. აქ არის სკრიპტის ბმული: 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-ის გაცნობა

შემაჯამებელი

ახალი კომენტარის დამატება

OpenVPN-დან WireGuard-ზე გადართვა ქსელების ერთ L2 ქსელში გაერთიანებისთვის

ნაწილი 1: ფონი

ნაწილი 2: WireGuard-ის გაცნობა

შემაჯამებელი

ახალი კომენტარის დამატება პასუხის გასაუქმებლად

ახალი კომენტარის დამატება