ProHoster > Š‘Š»Š¾Š³ > Administrācija > Pāreja no OpenVPN par WireGuard apvienot tÄ«klus vienā L2 tÄ«klā

Pāreja no OpenVPN par WireGuard apvienot tīklus vienā L2 tīklā

Pāreja no OpenVPN par WireGuard apvienot tīklus vienā L2 tīklā

Vēlos dalÄ«ties pieredzē par tÄ«klu apvienoÅ”anu trÄ«s Ä£eogrāfiski attālos dzÄ«vokļos, no kuriem katrs izmanto marÅ”rutētājus ar OpenWRT kā vārteju, vienā kopējā tÄ«klā. Izvēloties metodi tÄ«klu apvienoÅ”anai starp L3 ar apakÅ”tÄ«kla marÅ”rutÄ“Å”anu un L2 ar tiltu, kad visi tÄ«kla mezgli atradÄ«sies vienā apakÅ”tÄ«klā, priekÅ”roka tika dota otrajai metodei, kas ir grÅ«tāk konfigurējama, taču sniedz vairāk iespēju, jo ir caurspÄ«dÄ«ga. tehnoloÄ£iju izmantoÅ”ana tika plānota izveidotajā tÄ«klā Wake-on-Lan un DLNA.

1. daļa: fons

Sākotnēji Ŕī uzdevuma Ä«stenoÅ”anai izvēlētais protokols OpenVPN, jo, pirmkārt, tas var izveidot krāna ierÄ«ci, ko var bez problēmām pievienot tiltam, un, otrkārt, OpenVPN Tas atbalsta TCP, kas arÄ« bija svarÄ«gi, jo nevienam no dzÄ«vokļiem nebija Ä«paÅ”as IP adreses. Es nevarēju izmantot STUN, jo mans interneta pakalpojumu sniedzējs nez kāpēc bloķē ienākoÅ”os UDP savienojumus no saviem tÄ«kliem. TCP ļāva man pārsÅ«tÄ«t VPN servera portu uz Ä«rēto VPS, izmantojot SSH. Lai gan Ŕī pieeja rada ievērojamas papildu izmaksas, jo dati tiek dubultÅ”ifrēti, es negribēju integrēt VPS savā privātajā tÄ«klā, jo pastāvēja risks, ka treŔās personas iegÅ«s kontroli pār to. Tāpēc Ŕādas ierÄ«ces atraÅ”anās manā mājas tÄ«klā bija ļoti nevēlama, tāpēc nolēmu maksāt ievērojamas papildu izmaksas par droŔību.

Lai pāradresētu portu marÅ”rutētājā, kurā bija plānots izvietot serveri, es izmantoju programmu sshtunnel. Es neiedziļināŔos tās konfigurācijas detaļās ā€” tas ir diezgan vienkārÅ”i. Es tikai atzÄ«mÄ“Å”u, ka tās mērÄ·is bija pāradresēt TCP portu 1194 no marÅ”rutētāja uz VPS. Pēc tam es konfigurēju serveri. OpenVPN IerÄ«cē tap0, kas bija savienota ar br-lan tiltu. Pēc savienojuma ar jaunizveidoto serveri pārbaudes no mana klēpjdatora kļuva skaidrs, ka portu pāradresācijas ideja bija nostrādājusi, un mans klēpjdators bija kļuvis par marÅ”rutētāja tÄ«kla dalÄ«bnieku, lai gan fiziski nebija tā daļa.

Atlika vien sadalÄ«t IP adreses dažādos dzÄ«vokļos, lai tās nekonfliktētu, un konfigurēt marÅ”rutētājus tā, kā OpenVPN-klienti.
Tika atlasÄ«tas Ŕādas marÅ”rutētāja IP adreses un DHCP servera diapazoni:

  • 192.168.10.1 ar diapazonu 192.168.10.2 Sākot no 192.168.10.80 serverim
  • 192.168.10.100 ar diapazonu 192.168.10.101 Sākot no 192.168.10.149 par rÅ«teri dzÄ«voklÄ« Nr.2
  • 192.168.10.150 ar diapazonu 192.168.10.151 Sākot no 192.168.10.199 par rÅ«teri dzÄ«voklÄ« Nr.3

Bija nepiecieÅ”ams arÄ« pieŔķirt Ŕīs adreses klientu marÅ”rutētājiem. OpenVPN-server, pievienojot tā konfigurācijai Ŕādu rindu:

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

un pievienojot /etc/openvpn/ipp.txt failam Ŕādas rindas:

flat1_id 192.168.10.100
flat2_id 192.168.10.150

kur flat1_id un flat2_id ir ierīču nosaukumi, kas norādīti, veidojot sertifikātus savienojuma izveidei OpenVPN

Tālāk marÅ”rutētāji tika konfigurēti OpenVPN- klienti, tap0 ierÄ«ces abos tika pievienotas br-lan tiltam. Å ajā brÄ«dÄ« viss Ŕķita kārtÄ«bā, jo visi trÄ«s tÄ«kli varēja redzēt viens otru un darboties kā viena vienÄ«ba. Tomēr parādÄ«jās diezgan nepatÄ«kama detaļa: dažreiz ierÄ«ces saņēma IP adresi no nepareizā marÅ”rutētāja ar visām no tā izrietoÅ”ajām sekām. Kādu iemeslu dēļ marÅ”rutētājs vienā no dzÄ«vokļiem laikus neatbildēja uz DHCPDISCOVER, un ierÄ«ce saņēma nepareizu adresi. Es sapratu, ka man ir jāfiltrē Ŕādi pieprasÄ«jumi tap0 katrā marÅ”rutētājā, bet, kā izrādÄ«jās, iptables nevar darboties ar ierÄ«ci, ja tā ir daļa no tilta, tāpēc man bija jāizmanto ebtables. Diemžēl mana programmaparatÅ«ra to neiekļāva, tāpēc man bija jāpārveido attēli katrai ierÄ«cei. Pēc tam, kad tas tika izdarÄ«ts un katra marÅ”rutētāja /etc/rc.local failā tika pievienotas Ŕādas rindas, problēma tika atrisināta:

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

Šī konfigurācija ilga trīs gadus.

2. daļa: IepazīŔanās WireGuard

Pēdējā laikā internetā arvien biežāk tiek runāts par to, ka WireGuard, apbrÄ«nojot tā konfigurÄ“Å”anas vienkārŔību, augsto pārsÅ«tÄ«Å”anas ātrumu, zemo ping un salÄ«dzināmo droŔību. Meklējot papildu informāciju par to, atklājās, ka tas neatbalsta ne tilta dalÄ«bnieku, ne TCP protokola atbalstu, kas lika man domāt, ka alternatÄ«vas nav. OpenVPN man tā vēl aizvien nav. Tāpēc es atliku iepazÄ«Å”anos WireGuard.

Pirms dažām dienām resursos, kas vienā vai otrā veidā saistÄ«ti ar IT, izplatÄ«jās ziņas, ka WireGuard beidzot tiks iekļauts kodolā Linux, sākot ar 5.6. versiju. Ziņu raksti, kā vienmēr, tika atzinÄ«gi novērtēti WireGuardEs atkal ieniru meklējumos, kā aizstāt veco labo OpenVPNÅ oreiz es saskāros ar Å”is raksts. Tajā tika runāts par Ethernet tuneļa izveidi L3, izmantojot GRE. Å is raksts man deva cerÄ«bu. Palika neskaidrs, ko darÄ«t ar UDP protokolu. Meklējot, es nonāku pie rakstiem par socat izmantoÅ”anu kopā ar SSH tuneli, lai pārsÅ«tÄ«tu UDP portu, tomēr viņi atzÄ«mēja, ka Ŕī pieeja darbojas tikai viena savienojuma režīmā, kas nozÄ«mē, ka nav iespējams izmantot vairākus VPN klientus. Man radās ideja iestatÄ«t VPN serveri uz VPS un iestatÄ«t GRE klientiem, taču, kā izrādÄ«jās, GRE neatbalsta Å”ifrÄ“Å”anu, kas novedÄ«s pie tā, ka gadÄ«jumā, ja treŔās puses iegÅ«st piekļuvi serverim , visa trafika starp maniem tÄ«kliem ir viņu rokās, kas man nepavisam nederēja.

Atkal tika pieņemts lēmums par labu liekajai Å”ifrÄ“Å”anai, izmantojot VPN, izmantojot VPN saskaņā ar Ŕādu shēmu:

XNUMX. slāņa VPN:
VPS ir serveris ar iekŔējo adresi 192.168.30.1
MS ir klients VPS ar iekŔējo adresi 192.168.30.2
ŠœŠš2 ir klients VPS ar iekŔējo adresi 192.168.30.3
ŠœŠš3 ir klients VPS ar iekŔējo adresi 192.168.30.4

XNUMX. slāņa VPN:
MS ir serveris ar ārējo adresi 192.168.30.2 un iekŔējo 192.168.31.1
ŠœŠš2 ir klients MS ar adresi 192.168.30.2 un iekŔējais IP ir 192.168.31.2
ŠœŠš3 ir klients MS ar adresi 192.168.30.2 un iekŔējais IP ir 192.168.31.3

* MS - marÅ”rutētājs-serveris dzÄ«voklÄ« 1, ŠœŠš2 - marÅ”rutētājs 2. dzÄ«voklÄ«, ŠœŠš3 - marÅ”rutētājs 3. dzÄ«voklÄ«
* Ierīču konfigurācijas ir publicētas spoilerī raksta beigās.

Un tā, pings starp tÄ«kla 192.168.31.0/24 mezgliem iet, ir pienācis laiks pāriet uz GRE tuneļa iestatÄ«Å”anu. Pirms tam, lai nezaudētu piekļuvi marÅ”rutētājiem, ir vērts izveidot SSH tuneļus 22. porta pārsÅ«tÄ«Å”anai uz VPS, lai, piemēram, VPS 10022. portā bÅ«tu pieejams marÅ”rutētājs no 2. dzÄ«vokļa, un marÅ”rutētājs no 11122. dzÄ«vokļa bÅ«s pieejams VPS portā 3. rÅ«teris no dzÄ«vokļa XNUMX. Pāradresāciju vislabāk konfigurēt ar to paÅ”u sshtuneli, jo tas atjaunos tuneli, ja tas nokrÄ«t.

Tunelis ir konfigurēts, jūs varat izveidot savienojumu ar SSH, izmantojot pārsūtīto portu:

ssh root@ŠœŠžŠ™_VPS -p 10022

Tālāk jums vajadzētu atspējot OpenVPN:

/etc/init.d/openvpn stop

Tagad izveidosim GRE tuneli marÅ”rutētājā no 2. dzÄ«vokļa:

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

Un pievienojiet izveidoto saskarni tiltam:

brctl addif br-lan grelan0

Veiksim lÄ«dzÄ«gu procedÅ«ru servera marÅ”rutētājā:

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

Un arī pievienojiet izveidoto saskarni tiltam:

brctl addif br-lan grelan0

no Ŕī brīža ping sāk veiksmÄ«gi iet uz jauno tÄ«klu un es ar gandarÄ«jumu dodos dzert kafiju. Pēc tam, lai redzētu, kā darbojas tÄ«kls otrā vada galā, mēģinu SSH vienā no 2. dzÄ«vokļa datoriem, taču ssh klients sastingst, neprasot ievadÄ«t paroli. Mēģinu pieslēgties Å”im datoram caur telnet 22. portā un redzu rindiņu, no kuras var saprast, ka savienojums tiek izveidots, SSH serveris atbild, bet nez kāpēc man nepiedāvā ieiet.

$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1

Es mēģinu izveidot savienojumu ar to, izmantojot VNC, un es redzu melnu ekrānu. Pārliecinu sevi, ka lieta ir attālajā datorā, jo no Ŕī dzÄ«vokļa varu viegli pieslēgties marÅ”rutētājam, izmantojot iekŔējo adresi. Tomēr es nolemju SSH Å”ajā datorā, izmantojot marÅ”rutētāju, un esmu pārsteigts, konstatējot, ka savienojums ir veiksmÄ«gs un attālais dators darbojas labi, bet arÄ« neizdodas izveidot savienojumu ar manu datoru.

Es izņemu grelan0 ierÄ«ci no tilta un palaižu to. OpenVPN Otrā dzÄ«vokļa marÅ”rutētājā es pārliecinājos, ka tÄ«kls atkal darbojas pareizi un savienojumi nepārtrÅ«kst. Meklējot, es uzdÅ«ros forumiem, kuros cilvēki sÅ«dzējās par tām paŔām problēmām un ieteica palielināt MTU. Tas viss notika. Tomēr, lÄ«dz brÄ«dim, kad MTU tika iestatÄ«ts pietiekami augsts ā€” 7000 gretap ierÄ«cēm ā€”, es piedzÄ«voju vai nu TCP savienojumu pārtrÅ«kÅ”anu, vai mazu pārsÅ«tÄ«Å”anas ātrumu. Augstā gretap MTU dēļ savienojumu MTU... WireGuard Pirmais un otrais lÄ«menis tika noteikts attiecÄ«gi 8000 un 7500 apmērā.

Es veicu lÄ«dzÄ«gu iestatÄ«Å”anu marÅ”rutētājam no 3. dzÄ«vokļa, ar vienÄ«go atŔķirÄ«bu, ka servera marÅ”rutētājam tika pievienots otrs gretap interfeiss ar nosaukumu grelan1, kas tika pievienots arÄ« br-lan tiltam.

Viss darbojas. Tagad jūs varat ievietot gretap komplektu automātiskajā ielādei. PriekŔ Ŕī:

Å Ä«s rindiņas ievietoja marÅ”rutētājā 2. dzÄ«vokļa mapē /etc/rc.local:

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

Tas ir pievienots 3. dzÄ«vokļa marÅ”rutētājā /etc/rc.local:

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

Un servera marÅ”rutētājā:

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

Pēc klientu marÅ”rutētāju pārstartÄ“Å”anas es atklāju, ka kaut kādu iemeslu dēļ tie neizveidoja savienojumu ar serveri. Pēc savienojuma izveides ar viņu SSH (par laimi, es iepriekÅ” biju konfigurējis sshtunnel Å”im nolÅ«kam), es atklāju, ka WireGuard Kādu iemeslu dēļ tas izveido marÅ”rutu galapunktam, bet tas ir nepareizs. Piemēram, adresei 192.168.30.2 marÅ”ruta tabulā bija norādÄ«ts marÅ”ruts caur pppoe-wan saskarni, t. i., caur internetu, lai gan marÅ”rutam uz to vajadzēja bÅ«t novirzÄ«tam caur wg0 saskarni. Pēc Ŕī marÅ”ruta dzÄ“Å”anas savienojums tika atjaunots. Vai varu kaut kur atrast instrukcijas par to, kā piespiest... WireGuard Es nevarēju izvairÄ«ties no Å”o marÅ”rutu izveides. Turklāt es pat nesapratu, vai tā bija OpenWRT vai... funkcija. WireGuardNetērējot daudz laika problēmas risināŔanai, es vienkārÅ”i pievienoju rindu taimera cilpas skriptam abos marÅ”rutētājos, kas izdzēsa Å”o marÅ”rutu:

route del 192.168.30.2

Summējot

PilnÄ«ga noraidÄ«Å”ana OpenVPN Man tas vēl nav izdevies, jo man laiku pa laikam ir jāpieslēdzas jaunam tÄ«klam no klēpjdatora vai tālruņa, un gretap ierÄ«ces iestatÄ«Å”ana tajos parasti nav iespējama. Tomēr, neskatoties uz to, esmu ieguvis priekÅ”rocÄ«bas datu pārsÅ«tÄ«Å”anas ātrumā starp dzÄ«vokļiem, un, piemēram, VNC izmantoÅ”ana tagad ir bez problēmām. Ping ir nedaudz samazinājies, bet kļuvis stabilāks:

Lietojot 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

Lietojot 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

To galvenokārt ietekmē liela ping uz VPS, kas ir aptuveni 61.5 ms

Tomēr ātrums ir ievērojami palielinājies. Tātad dzÄ«voklÄ« ar marÅ”rutētāju-serveri man ir interneta pieslēguma ātrums 30 Mb/s, bet pārējos dzÄ«vokļos tas ir 5 Mb/s. Turklāt lietoÅ”anas laikā OpenVPN Saskaņā ar iperf rādÄ«jumiem man neizdevās sasniegt datu pārsÅ«tÄ«Å”anas ātrumu starp tÄ«kliem, kas pārsniedz 3,8 Mb/s, kamēr WireGuard "uzpumpēja" to lÄ«dz tiem paÅ”iem 5 Mbit/sek.

Konfigurācija WireGuard uz VPS[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <Š—ŠŠšŠ Š«Š¢Š«Š™_ŠšŠ›Š®Š§_Š”Š›ŠÆ_VPS>

[Līdzcilvēks]
Publiskā atslēga = <VPN_1_MS_PUBLIC_KEY>
Atļautie IP = 192.168.30.2/32

[Līdzcilvēks]
Publiskā atslēga = <VPN_2_MK2_PUBLIC_KEY>
Atļautie IP = 192.168.30.3/32

[Līdzcilvēks]
Publiskā atslēga = <VPN_2_MK3_PUBLIC_KEY>
Atļautie IP = 192.168.30.4/32

Konfigurācija WireGuard operētājsistēmā MS (pievienots /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'

Konfigurācija WireGuard uz MK2 (pievienots /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'

Konfigurācija WireGuard uz MK3 (pievienots /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'

AprakstÄ«tajās otrā lÄ«meņa VPN konfigurācijās es klientiem norādu WireGuard 51821. ports. Tam nevajadzētu bÅ«t nepiecieÅ”amam, jo ā€‹ā€‹klients izveidos savienojumu no jebkura brÄ«va, neprivileģēta porta, taču es to izdarÄ«ju Ŕādi, lai varētu liegt visus ienākoÅ”os savienojumus visu marÅ”rutētāju wg0 saskarnēs, izņemot ienākoÅ”os UDP savienojumus uz 51821. portu.

Ceru, ka raksts kādam noderēs.

PS Tāpat es vēlos kopīgot savu skriptu, kas man sūta PUSH paziņojumu uz manu tālruni lietojumprogrammā WirePusher, kad manā tīklā parādās jauna ierīce. Šeit ir saite uz skriptu: github.com/r0ck3r/device_discover.

UPDATE: Konfigurācija OpenVPN- serveri un klienti

OpenVPN- serveris

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-klients

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

Sertifikātu Ä£enerÄ“Å”anai izmantoju easy-rsa.

Avots: www.habr.com

Iegādājieties uzticamu mitināŔanu vietnēm ar DDoS aizsardzÄ«bu, VPS VDS serveriem šŸ”„ Iegādājieties uzticamu tÄ«mekļa vietņu mitināŔanu ar DDoS aizsardzÄ«bu, VPS VDS serveriem | ProHoster