ProHoster > Blogs > Administrācija > Migrācija no OpenVPN uz WireGuard, lai konsolidētu tīklus vienā L2 tīklā

Migrācija no OpenVPN uz WireGuard, lai konsolidētu tīklus vienā L2 tīklā

Migrācija no OpenVPN uz WireGuard, lai konsolidētu 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 kā Ŕī uzdevuma Ä«stenoÅ”anas protokols tika izvēlēts OpenVPN, jo, pirmkārt, tas var izveidot pieskārienu ierÄ«ci, ko var bez problēmām pievienot tiltam, un, otrkārt, OpenVPN atbalsta darbÄ«bu pār TCP protokolu, kas arÄ« bija svarÄ«gi, jo nevienam no dzÄ«vokļiem nebija speciālas IP adreses, un es nevarēju izmantot STUN, jo mans ISP nez kāpēc bloķē ienākoÅ”os UDP savienojumus no viņu tÄ«kliem, savukārt TCP protokols ļāva pārsÅ«tÄ«t VPN servera portu uz Ä«rētu VPS, izmantojot SSH. Jā, Ŕī pieeja rada lielu slodzi, jo dati tiek Å”ifrēti divreiz, bet es nevēlējos ieviest VPS savā privātajā tÄ«klā, jo joprojām pastāvēja risks, ka treŔās personas pārņems kontroli pār to, tāpēc ir Ŕāda ierÄ«ce. mājas tÄ«klā bija ārkārtÄ«gi nevēlama, un tika nolemts maksāt par droŔību ar lielām pieskaitāmām izmaksām.

Lai pārsÅ«tÄ«tu portu marÅ”rutētājā, kurā bija plānots izvietot serveri, tika izmantota programma sshtunnel. Es neaprakstÄ«Å”u tā konfigurācijas smalkumus - tas tiek darÄ«ts diezgan vienkārÅ”i, es tikai atzÄ«mēju, ka tā uzdevums bija pārsÅ«tÄ«t TCP portu 1194 no marÅ”rutētāja uz VPS. Pēc tam OpenVPN serveris tika konfigurēts tap0 ierÄ«cē, kas bija savienota ar br-lan tiltu. Pārbaudot savienojumu ar jaunizveidoto serveri no klēpjdatora, kļuva skaidrs, ka portu pāradresācijas ideja sevi attaisno un mans klēpjdators kļuva par marÅ”rutētāja tÄ«kla dalÄ«bnieku, lai gan fiziski tajā nebija.

Lieta palika maza: bija nepiecieÅ”ams izplatÄ«t IP adreses dažādos dzÄ«vokļos, lai tās nekonfliktētu, un konfigurēt marÅ”rutētājus kā OpenVPN klientus.
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

Tāpat bija nepiecieÅ”ams pieŔķirt tieÅ”i Ŕīs adreses OpenVPN servera klientu marÅ”rutētājiem, pievienojot rindu tā konfigurācijai:

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, ģenerējot sertifikātus savienojumam ar OpenVPN

Pēc tam marÅ”rutētājos tika konfigurēti OpenVPN klienti, abos tap0 ierÄ«ces tika pievienotas br-lan tiltam. Å ajā posmā viss Ŕķita kārtÄ«bā, jo visi trÄ«s tÄ«kli redz viens otru un darbojas kopumā. Tomēr izrādÄ«jās ne pārāk patÄ«kama detaļa: dažreiz ierÄ«ces varēja iegÅ«t IP adresi nevis no sava 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 nepaguva laikus atbildēt 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ā, taču, kā izrādÄ«jās, iptables nevar strādāt ar ierÄ«ci, ja tā ir daļa no tilta, un ebtables vajadzētu man palÄ«dzēt. Diemžēl tas nebija manā programmaparatÅ«rā, un man bija jāpārveido attēli katrai ierÄ«cei. To darot un pievienojot Ŕīs rindas katra marÅ”rutētāja /etc/rc.local, 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īstieties ar WireGuard

Pēdējā laikā internetā arvien vairāk tiek runāts par WireGuard, apbrÄ«nojot tā konfigurācijas vienkārŔību, lielu pārsÅ«tÄ«Å”anas ātrumu, zemu ping ar salÄ«dzināmu droŔību. Meklējot vairāk informācijas par to, kļuva skaidrs, ka tas neatbalsta ne darbu kā tilta dalÄ«bnieks, ne darbu pār TCP protokolu, kas lika man domāt, ka man joprojām nav alternatÄ«vu OpenVPN. Tāpēc es atliku iepazÄ«Å”anos ar WireGuard.

Pirms dažām dienām caur resursiem, kas tā vai citādi saistÄ«ti ar IT, izplatÄ«jās ziņa, ka WireGuard beidzot tiks iekļauts Linux kodolā, sākot ar versiju 5.6. Ziņu raksti, kā vienmēr, slavēja WireGuard. Es atkal iegrimu meklējumos, kā aizstāt veco labo OpenVPN. Å oreiz es uzskrēju Å”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

Pēc tam atspējojiet 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 startēju OpenVPN marÅ”rutētājā 2. dzÄ«voklÄ« un pārliecinos, ka tÄ«kls atkal darbojas pareizi un savienojumi nekrÄ«t. Meklējot es sastopu forumus, kur cilvēki sÅ«dzas par tām paŔām problēmām, kur viņiem tiek ieteikts paaugstināt MTU. Ne ātrāk pateikts, kā izdarÄ«ts. Tomēr, lÄ«dz MTU tika iestatÄ«ts uz pietiekami lielu vērtÄ«bu 7000 gretap ierÄ«cēm, tika novēroti TCP savienojumi vai lēna pārraide. Sakarā ar lielo gretap MTU, pirmā un otrā lÄ«meņa WireGuard savienojumu MTU tika iestatÄ«ti attiecÄ«gi uz 8000 un 7500.

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 nav izveidojuÅ”i savienojumu ar serveri. Pieslēdzoties viņu SSH (par laimi, es tam iepriekÅ” biju konfigurējis sshtunnel), tika atklāts, ka WireGuard kaut kādu iemeslu dēļ izveido galapunkta marÅ”rutu, taču tas ir nepareizs. Tātad 192.168.30.2 marÅ”ruta tabula tika norādÄ«ta marÅ”ruta tabulā, izmantojot saskarni pppoe-wan, tas ir, izmantojot 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. Es nekur nevarēju atrast norādÄ«jumus, kā piespiest WireGuard neveidot Å”os marÅ”rutus. Turklāt es pat nesapratu, vai tā ir OpenWRT vai paÅ”a WireGuard funkcija. Ilgi nerisinot Å”o problēmu, es vienkārÅ”i pievienoju abiem marÅ”rutētājiem skriptā, ko cilpa taimeris, rindiņu, kas izdzēsa Å”o marÅ”rutu: 

route del 192.168.30.2

Summējot

Es vēl neesmu pilnÄ«bā noraidÄ«jis OpenVPN, jo dažreiz man ir jāpievienojas jaunam tÄ«klam no klēpjdatora vai tālruņa, un gretap ierÄ«ces iestatÄ«Å”ana tajos parasti nav iespējama, taču, neskatoties uz to, es ieguvu priekÅ”rocÄ«bas datu pārsÅ«tÄ«Å”anā. ātrums starp dzÄ«vokļiem un, piemēram, VNC lietoÅ”ana vairs nav neērta. Ping nedaudz samazinājās, bet kļuva stabilāks:

Izmantojot 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

Izmantojot 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 rÅ«teri-serveri man interneta pieslēguma ātrums ir 30 Mb/s, bet citos dzÄ«vokļos 5 Mb/s. Tajā paŔā laikā, izmantojot OpenVPN, es nevarēju sasniegt datu pārraides ātrumu starp tÄ«kliem, kas pārsniedz 3,8 Mbps saskaņā ar iperf, savukārt WireGuard to "uzsÅ«knēja" lÄ«dz tiem paÅ”iem 5 Mbps.

WireGuard konfigurācija 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 konfigurācija MS (pievienota /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 konfigurācija uz MK2 (pievienota /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 konfigurācija uz MK3 (pievienota /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 WireGuard klientiem norādÄ«ju portu 51821. Teorētiski tas nav nepiecieÅ”ams, jo klients izveidos savienojumu no jebkura bezmaksas nepriviliģētā porta, bet es izdarÄ«ju tā, lai visi ienākoÅ”ie savienojumi var liegt visu marÅ”rutētāju wg0 saskarnēs, izņemot ienākoÅ”os UDP savienojumus portā 51821.

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: OpenVPN servera un klientu konfigurācija

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

Pievieno komentāru