ProHoster > Blog > Pentadbiran > Peralihan daripada OpenVPN pada WireGuard untuk menggabungkan rangkaian menjadi satu rangkaian L2

Peralihan daripada OpenVPN pada WireGuard untuk menggabungkan rangkaian menjadi satu rangkaian L2

Peralihan daripada OpenVPN pada WireGuard untuk menggabungkan rangkaian menjadi satu rangkaian L2

Saya ingin berkongsi pengalaman saya menggabungkan rangkaian dalam tiga pangsapuri terpencil secara geografi, yang setiap satunya menggunakan penghala OpenWRT sebagai pintu masuk, ke dalam satu rangkaian biasa. Apabila memilih kaedah untuk menggabungkan rangkaian antara L3 dengan penghalaan subnet dan L2 dengan penyambungan, apabila semua nod rangkaian akan berada dalam subnet yang sama, keutamaan diberikan kepada kaedah kedua, yang lebih sukar untuk dikonfigurasikan, tetapi memberikan peluang yang lebih besar, kerana penggunaan teknologi yang telus telah dirancang dalam rangkaian yang dicipta Wake-on-Lan dan DLNA.

Bahagian 1: Latar Belakang

Protokol yang dipilih untuk melaksanakan tugasan ini pada mulanya OpenVPN, kerana, pertama, ia boleh mencipta peranti pili yang boleh ditambah pada jambatan tanpa sebarang masalah, dan kedua, OpenVPN Ia menyokong TCP, yang juga penting, kerana tiada satu pun pangsapuri mempunyai alamat IP khusus. Saya tidak dapat menggunakan STUN kerana ISP saya, atas sebab tertentu, menyekat sambungan UDP masuk dari rangkaiannya. TCP membenarkan saya menghantar port pelayan VPN ke VPS yang disewa menggunakan SSH. Walaupun pendekatan ini menghasilkan overhed yang ketara, kerana data disulitkan dua kali ganda, saya tidak mahu mengintegrasikan VPS ke dalam rangkaian peribadi saya, kerana terdapat risiko pihak ketiga mendapat kawalan ke atasnya. Oleh itu, mempunyai peranti sedemikian di rangkaian rumah saya sangat tidak diingini, jadi saya memutuskan untuk membayar overhed yang besar untuk keselamatan.

Untuk meneruskan port pada penghala tempat pelayan dirancang untuk digunakan, saya menggunakan program sshtunnel. Saya tidak akan menerangkan secara terperinci konfigurasinya—ia agak mudah. ​​Saya cuma ingin menyatakan bahawa tujuannya adalah untuk meneruskan port TCP 1194 dari penghala ke VPS. Seterusnya, saya mengkonfigurasi pelayan. OpenVPN Pada peranti tap0, yang disambungkan ke jambatan br-lan. Selepas menguji sambungan ke pelayan yang baru dibuat daripada komputer riba saya, menjadi jelas bahawa idea penghantaran port telah berjaya, dan komputer riba saya telah menjadi ahli rangkaian penghala, walaupun ia bukan sebahagian daripadanya secara fizikal.

Satu-satunya perkara yang perlu dilakukan ialah mengedarkan alamat IP di pangsapuri yang berbeza supaya ia tidak bercanggah dan mengkonfigurasi penghala sebagai OpenVPN-pelanggan.
Alamat IP penghala dan julat pelayan DHCP berikut telah dipilih:

  • 192.168.10.1 dengan julat 192.168.10.2 - 192.168.10.80 untuk pelayan
  • 192.168.10.100 dengan julat 192.168.10.101 - 192.168.10.149 untuk penghala di apartmen No. 2
  • 192.168.10.150 dengan julat 192.168.10.151 - 192.168.10.199 untuk penghala di apartmen No. 3

Ia juga perlu untuk memberikan alamat ini kepada penghala klien. OpenVPN-server, dengan menambah baris berikut pada konfigurasinya:

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

dan menambah baris berikut pada fail /etc/openvpn/ipp.txt:

flat1_id 192.168.10.100
flat2_id 192.168.10.150

di mana flat1_id dan flat2_id ialah nama peranti yang dinyatakan semasa mencipta sijil untuk menyambung ke OpenVPN

Seterusnya, penghala telah dikonfigurasikan OpenVPN- klien, peranti tap0 pada kedua-duanya telah ditambahkan pada jambatan br-lan. Pada ketika ini, semuanya kelihatan baik-baik saja, kerana ketiga-tiga rangkaian dapat melihat antara satu sama lain dan berfungsi sebagai satu unit. Walau bagaimanapun, satu perincian yang agak tidak menyenangkan muncul: kadangkala peranti akan menerima alamat IP daripada penghala yang salah, dengan semua akibat yang berlaku. Atas sebab tertentu, penghala di salah satu apartmen gagal bertindak balas kepada DHCPDISCOVER tepat pada masanya, dan peranti tersebut menerima alamat yang salah. Saya sedar saya perlu menapis permintaan sedemikian dalam tap0 pada setiap penghala, tetapi ternyata, iptables tidak boleh berfungsi dengan peranti jika ia merupakan sebahagian daripada jambatan, jadi saya perlu menggunakan ebtables. Malangnya, firmware saya tidak menyertakannya, jadi saya terpaksa membina semula imej untuk setiap peranti. Selepas melakukan ini dan menambah baris berikut pada /etc/rc.local pada setiap penghala, masalahnya telah diselesaikan:

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

Konfigurasi ini berlangsung selama tiga tahun.

Bahagian 2: Mengenali WireGuard

Akhir-akhir ini, terdapat perbincangan yang semakin hangat di internet tentang WireGuard, mengagumi kemudahan konfigurasinya, kelajuan pemindahan yang tinggi, ping yang rendah dan keselamatan yang setanding. Carian untuk maklumat tambahan mengenainya mendedahkan bahawa ia tidak menyokong sama ada sokongan ahli jambatan atau protokol TCP, yang membuatkan saya percaya bahawa tiada alternatif lain. OpenVPN bagi saya ia masih belum ada. Jadi saya menangguhkan untuk mengenali WireGuard.

Beberapa hari yang lalu, berita tersebar melalui sumber yang berkaitan dengan IT dalam satu atau lain cara yang WireGuard akhirnya akan dimasukkan ke dalam kernel Linux, bermula dengan versi 5.6. Artikel berita, seperti biasa, dipuji WireGuardSaya sekali lagi terjerumus mencari jalan untuk menggantikan yang lama OpenVPNKali ini saya terserempak dengan artikel ini. Ia bercakap tentang mencipta terowong Ethernet melalui L3 menggunakan GRE. Artikel ini memberi saya harapan. Ia masih tidak jelas apa yang perlu dilakukan dengan protokol UDP. Pencarian membawa saya ke artikel tentang menggunakan socat bersama terowong SSH untuk memajukan port UDP, bagaimanapun, mereka menyatakan bahawa pendekatan ini hanya berfungsi dalam mod sambungan tunggal, iaitu, kerja beberapa pelanggan VPN adalah mustahil. Saya datang dengan idea untuk memasang pelayan VPN pada VPS dan menyediakan GRE untuk pelanggan, tetapi ternyata, GRE tidak menyokong penyulitan, yang akan membawa kepada fakta bahawa jika pihak ketiga mendapat akses ke pelayan , semua trafik antara rangkaian saya akan berada di tangan mereka, yang tidak sesuai dengan saya sama sekali.

Sekali lagi, keputusan dibuat memihak kepada penyulitan berlebihan, dengan menggunakan VPN melalui VPN menggunakan skema berikut:

VPN Tahap XNUMX:
VPS adalah pelayan dengan alamat dalaman 192.168.30.1
MS adalah pelanggan VPS dengan alamat dalaman 192.168.30.2
MK2 adalah pelanggan VPS dengan alamat dalaman 192.168.30.3
MK3 adalah pelanggan VPS dengan alamat dalaman 192.168.30.4

VPN tahap kedua:
MS adalah pelayan dengan alamat luaran 192.168.30.2 dan dalaman 192.168.31.1
MK2 adalah pelanggan MS dengan alamat 192.168.30.2 dan mempunyai IP dalaman 192.168.31.2
MK3 adalah pelanggan MS dengan alamat 192.168.30.2 dan mempunyai IP dalaman 192.168.31.3

* MS — penghala-pelayan di apartmen 1, MK2 - penghala di apartmen 2, MK3 - penghala dalam apartmen 3
* Konfigurasi peranti diterbitkan dalam spoiler pada akhir artikel.

Oleh itu, ping berjalan di antara nod rangkaian 192.168.31.0/24, sudah tiba masanya untuk meneruskan untuk menyediakan terowong GRE. Sebelum ini, agar tidak kehilangan akses kepada penghala, adalah wajar menyediakan terowong SSH untuk memajukan port 22 ke VPS, supaya, sebagai contoh, penghala dari apartmen 10022 akan dapat diakses pada port 2 VPS, dan penghala dari pangsapuri 11122 akan boleh diakses pada penghala port 3 dari pangsapuri XNUMX. Adalah lebih baik untuk mengkonfigurasi pemajuan menggunakan sshtunnel yang sama, kerana ia akan memulihkan terowong jika ia gagal.

Terowong dikonfigurasikan, anda boleh menyambung ke SSH melalui port yang dimajukan:

ssh root@МОЙ_VPS -p 10022

Seterusnya anda perlu melumpuhkan OpenVPN:

/etc/init.d/openvpn stop

Sekarang mari kita sediakan terowong GRE pada penghala dari pangsapuri 2:

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

Dan tambahkan antara muka yang dibuat ke jambatan:

brctl addif br-lan grelan0

Mari lakukan prosedur yang sama pada penghala pelayan:

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

Dan juga tambahkan antara muka yang dibuat pada jambatan:

brctl addif br-lan grelan0

bermula dari saat ini, ping mula berjaya pergi ke rangkaian baru dan saya, dengan kepuasan, pergi untuk minum kopi. Kemudian, untuk menilai bagaimana rangkaian berfungsi pada hujung talian yang lain, saya cuba SSH ke salah satu komputer di pangsapuri 2, tetapi pelanggan ssh membeku tanpa meminta kata laluan. Saya cuba menyambung ke komputer ini melalui telnet pada port 22 dan saya melihat satu baris dari mana saya boleh memahami bahawa sambungan sedang diwujudkan, pelayan SSH bertindak balas, tetapi atas sebab tertentu ia tidak menggesa saya untuk log dalam.

$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1

Saya cuba menyambung kepadanya melalui VNC dan melihat skrin hitam. Saya meyakinkan diri saya bahawa masalahnya adalah dengan komputer jauh, kerana saya boleh dengan mudah menyambung ke penghala dari apartmen ini menggunakan alamat dalaman. Walau bagaimanapun, saya memutuskan untuk menyambung ke SSH komputer ini melalui penghala dan terkejut apabila mendapati sambungan itu berjaya, dan komputer jauh berfungsi seperti biasa, tetapi ia juga tidak dapat menyambung ke komputer saya.

Saya mengeluarkan peranti grelan0 dari jambatan dan menjalankannya OpenVPN Pada penghala di apartmen 2, saya mengesahkan bahawa rangkaian berfungsi dengan betul semula dan sambungan tidak terputus. Semasa mencari, saya terjumpa forum di mana orang ramai mengadu tentang isu yang sama, dan di mana mereka dinasihatkan untuk menaikkan MTU. Tidak lama kemudian, saya telah melakukannya. Walau bagaimanapun, sehingga MTU ditetapkan cukup tinggi—7000 untuk peranti gretap—saya mengalami sama ada sambungan TCP terputus atau kelajuan pemindahan yang rendah. Disebabkan oleh MTU yang tinggi untuk gretap, MTU untuk sambungan WireGuard Aras pertama dan kedua masing-masing ditetapkan pada 8000 dan 7500.

Saya menjalankan persediaan yang sama pada penghala dari apartmen 3, dengan satu-satunya perbezaan ialah antara muka gretap kedua bernama grelan1 telah ditambahkan pada penghala pelayan, yang juga telah ditambahkan pada jambatan br-lan.

Semuanya berfungsi. Kini anda boleh meletakkan pemasangan gretap ke dalam permulaan. Untuk ini:

Saya meletakkan baris ini dalam /etc/rc.local pada penghala di apartmen 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

Menambah ini pada /etc/rc.local pada penghala dalam apartmen 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

Dan pada penghala pelayan:

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

Selepas but semula penghala klien, saya mendapati bahawa atas sebab tertentu ia tidak bersambung ke pelayan. Selepas bersambung ke SSH mereka (mujurlah, saya sebelum ini telah mengkonfigurasi sshtunnel untuk ini), saya mendapati bahawa WireGuard Atas sebab tertentu, ia mencipta laluan untuk titik akhir, tetapi ia tidak betul. Contohnya, untuk 192.168.30.2, jadual laluan menentukan laluan melalui antara muka pppoe-wan, iaitu, melalui internet, walaupun laluan ke sana sepatutnya diarahkan melalui antara muka wg0. Selepas memadam laluan ini, sambungan telah dipulihkan. Bolehkah saya mendapatkan arahan di mana-mana sahaja tentang cara memaksa WireGuard Saya tidak dapat mengelak daripada mencipta laluan ini. Tambahan pula, saya tidak faham sama ada ini merupakan ciri OpenWRT atau WireGuardTanpa menghabiskan banyak masa memikirkan masalahnya, saya hanya menambah baris pada skrip berasaskan pemasa pada kedua-dua penghala yang memadamkan laluan ini:

route del 192.168.30.2

Ringkasan

Penolakan sepenuhnya OpenVPN Saya belum mencapai matlamat ini lagi, kerana saya kadangkala perlu menyambung ke rangkaian baharu daripada komputer riba atau telefon, dan menyediakan peranti gretap padanya secara amnya mustahil. Walau bagaimanapun, walaupun begitu, saya telah mendapat kelebihan dalam kelajuan pemindahan data antara pangsapuri, dan menggunakan VNC, sebagai contoh, kini bebas daripada kerumitan. Ping telah berkurangan sedikit tetapi menjadi lebih stabil:

Apabila menggunakan 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

Apabila menggunakan 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

Ia lebih dipengaruhi oleh ping tinggi ke VPS, iaitu lebih kurang 61.5 ms

Walau bagaimanapun, kelajuannya telah meningkat dengan ketara. Jadi, di apartmen dengan penghala-pelayan, saya mempunyai kelajuan sambungan internet sebanyak 30 Mbps, dan di apartmen lain ia adalah 5 Mbps. Tambahan pula, semasa penggunaan OpenVPN Saya tidak dapat mencapai kelajuan pemindahan data antara rangkaian yang lebih besar daripada 3,8 Mbps mengikut bacaan iperf, sementara WireGuard "mengepam" ia sehingga 5 Mbit/saat yang sama.

Konfigurasi WireGuard pada VPS[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>

[Rakan sebaya]
Kunci Awam = <VPN_1_MS_KEY_PUBLIC>
AllowedIPs = 192.168.30.2/32

[Rakan sebaya]
Kunci Awam = <VPN_2_MK2_KEY_PUBLIC>
AllowedIPs = 192.168.30.3/32

[Rakan sebaya]
Kunci Awam = <VPN_2_MK3_KEY_PUBLIC>
AllowedIPs = 192.168.30.4/32

Konfigurasi WireGuard pada MS (ditambah pada /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'

Konfigurasi WireGuard pada MK2 (ditambah pada /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'

Konfigurasi WireGuard pada MK3 (ditambah pada /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'

Dalam konfigurasi yang diterangkan untuk VPN tahap kedua, saya nyatakan kepada klien WireGuard Port 51821. Ini sepatutnya tidak perlu, kerana klien akan mewujudkan sambungan daripada mana-mana port percuma dan tidak bernasib baik, tetapi saya melakukannya dengan cara ini supaya saya boleh menolak semua sambungan masuk pada antara muka wg0 semua penghala, kecuali sambungan UDP masuk ke port 51821.

Saya berharap artikel itu akan berguna kepada seseorang.

PS Selain itu, saya ingin berkongsi skrip saya yang menghantar pemberitahuan PUSH kepada telefon saya dalam aplikasi WirePusher apabila peranti baharu muncul pada rangkaian saya. Berikut adalah pautan ke skrip: github.com/r0ck3r/device_discover.

UPDATE: Konfigurasi OpenVPN-pelayan dan klien

OpenVPN-pelayan

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

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

Saya menggunakan easy-rsa untuk menjana sijil

Sumber: www.habr.com

Beli pengehosan yang boleh dipercayai untuk tapak dengan perlindungan DDoS, pelayan VPS VDS 🔥 Beli pengehosan laman web yang boleh dipercayai dengan perlindungan DDoS, pelayan VPS VDS | ProHoster