Beralih daripada OpenVPN kepada WireGuard untuk menggabungkan rangkaian menjadi satu rangkaian L2

Beralih daripada OpenVPN kepada 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

OpenVPN pada mulanya dipilih sebagai protokol untuk melaksanakan tugas ini, kerana, pertama, ia boleh mencipta peranti ketik yang boleh ditambah pada jambatan tanpa masalah, dan kedua, OpenVPN menyokong operasi melalui protokol TCP, yang juga penting, kerana tiada satu pun. daripada pangsapuri mempunyai alamat IP khusus, dan saya tidak dapat menggunakan STUN, kerana pembekal saya atas sebab tertentu menyekat sambungan UDP masuk daripada rangkaian mereka, manakala protokol TCP membenarkan saya memajukan port pelayan VPN kepada VPS yang disewa menggunakan SSH. Ya, pendekatan ini memberikan beban yang besar, kerana data disulitkan dua kali, tetapi saya tidak mahu memperkenalkan VPS ke dalam rangkaian peribadi saya, kerana masih terdapat risiko pihak ketiga mendapat kawalan ke atasnya, oleh itu, mempunyai peranti sedemikian pada rangkaian rumah saya adalah sangat tidak diingini dan telah diputuskan membayar untuk keselamatan dengan overhed yang besar.

Untuk memajukan port pada penghala di mana ia dirancang untuk menggunakan pelayan, program sshtunnel telah digunakan. Saya tidak akan menerangkan selok-belok konfigurasinya - ia dilakukan dengan agak mudah, saya hanya akan ambil perhatian bahawa tugasnya adalah untuk memajukan port TCP 1194 dari penghala ke VPS. Seterusnya, pelayan OpenVPN telah dikonfigurasikan pada peranti tap0, yang disambungkan ke jambatan br-lan. Setelah menyemak sambungan ke pelayan yang baru dibuat dari komputer riba, menjadi jelas bahawa idea pemajuan port adalah wajar dan komputer riba saya menjadi ahli rangkaian penghala, walaupun ia tidak secara fizikal di dalamnya.

Hanya ada satu perkara kecil yang perlu dilakukan: adalah perlu untuk mengedarkan alamat IP di pangsapuri yang berbeza supaya ia tidak bercanggah dan mengkonfigurasi penghala sebagai pelanggan OpenVPN.
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 menetapkan alamat ini dengan tepat kepada penghala pelanggan pelayan OpenVPN dengan menambah baris 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 membuat sijil untuk menyambung ke OpenVPN

Seterusnya, klien OpenVPN telah dikonfigurasikan pada penghala, peranti tap0 pada kedua-duanya telah ditambahkan pada jambatan br-lan. Pada peringkat ini, semuanya kelihatan baik kerana ketiga-tiga rangkaian dapat melihat satu sama lain dan berfungsi sebagai satu. Walau bagaimanapun, butiran yang tidak begitu menyenangkan muncul: kadangkala peranti boleh menerima alamat IP bukan dari penghala mereka, dengan semua akibat yang berikutnya. Atas sebab tertentu, penghala di salah satu pangsapuri tidak mempunyai masa untuk bertindak balas kepada DHCPDISCOVER dalam masa dan peranti menerima alamat yang tidak dimaksudkan. Saya menyedari bahawa saya perlu menapis permintaan sedemikian dalam tap0 pada setiap penghala, tetapi ternyata, iptables tidak boleh berfungsi dengan peranti jika ia adalah sebahagian daripada jambatan dan ebtables mesti datang untuk membantu saya. Saya menyesal, ia tiada dalam perisian tegar saya dan saya terpaksa membina semula imej untuk setiap peranti. Dengan melakukan ini dan menambah baris ini ke /etc/rc.local setiap penghala, masalah 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: Memperkenalkan WireGuard

Baru-baru ini, orang di Internet semakin mula bercakap tentang WireGuard, mengagumi kesederhanaan konfigurasinya, kelajuan penghantaran yang tinggi, ping rendah dengan keselamatan yang setanding. Mencari maklumat lanjut mengenainya menjelaskan bahawa tidak bekerja sebagai ahli jambatan mahupun bekerja melalui protokol TCP disokong olehnya, yang membuatkan saya berfikir bahawa masih tiada alternatif kepada OpenVPN untuk saya. Jadi saya menangguhkan mengenali WireGuard.

Beberapa hari yang lalu, berita tersebar merentasi sumber entah bagaimana berkaitan dengan IT bahawa WireGuard akhirnya akan dimasukkan ke dalam kernel Linux, bermula dengan versi 5.6. Artikel berita, seperti biasa, memuji WireGuard. Saya sekali lagi terjun ke dalam pencarian cara untuk menggantikan OpenVPN lama yang baik. Kali ini saya terserempak 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 harus 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 menjalankan OpenVPN pada penghala di apartmen 2 dan memastikan rangkaian berfungsi seperti yang diharapkan semula dan sambungan tidak terputus. Dengan mencari, saya terjumpa forum di mana orang ramai mengadu tentang masalah yang sama, di mana mereka dinasihatkan untuk menaikkan MTU. Tidak cepat berkata daripada selesai. Walau bagaimanapun, sehingga MTU ditetapkan cukup tinggi - 7000 untuk peranti gretap, sama ada sambungan TCP terputus atau kadar pemindahan rendah diperhatikan. Disebabkan oleh MTU yang tinggi untuk gretap, MTU untuk sambungan WireGuard Lapisan 8000 dan Lapisan 7500 ditetapkan kepada XNUMX dan XNUMX masing-masing.

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 pelanggan, saya mendapati bahawa atas sebab tertentu mereka tidak menyambung ke pelayan. Setelah disambungkan ke SSH mereka (nasib baik, saya sebelum ini telah mengkonfigurasi sshtunnel untuk ini), didapati bahawa WireGuard atas sebab tertentu mencipta laluan untuk titik akhir, tetapi ia tidak betul. Jadi, untuk 192.168.30.2, jadual laluan menunjukkan laluan melalui antara muka pppoe-wan, iaitu, melalui Internet, walaupun laluan ke sana sepatutnya telah dihalakan melalui antara muka wg0. Selepas memadamkan laluan ini, sambungan telah dipulihkan. Saya tidak dapat mencari arahan di mana-mana tentang cara memaksa WireGuard untuk tidak membuat laluan ini. Lebih-lebih lagi, saya tidak faham sama ada ini adalah ciri OpenWRT atau WireGuard itu sendiri. Tanpa perlu menangani masalah ini untuk masa yang lama, saya hanya menambah baris pada kedua-dua penghala dalam skrip bermasa yang memadamkan laluan ini:

route del 192.168.30.2

Ringkasan

Saya masih belum mencapai pengabaian sepenuhnya OpenVPN, kerana kadang-kadang saya perlu menyambung ke rangkaian baru dari komputer riba atau telefon, dan menyediakan peranti gretap padanya secara amnya mustahil, tetapi walaupun ini, saya mendapat kelebihan dalam kelajuan pemindahan data antara pangsapuri dan, sebagai contoh, menggunakan VNC tidak lagi menyusahkan. Ping menurun 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, kelajuan telah meningkat dengan ketara. Jadi, di apartmen dengan penghala pelayan saya mempunyai kelajuan sambungan Internet 30 Mbit/s, dan di pangsapuri lain ia adalah 5 Mbit/sec. Pada masa yang sama, semasa menggunakan OpenVPN, saya tidak dapat mencapai kelajuan pemindahan data antara rangkaian lebih daripada 3,8 Mbit/saat mengikut bacaan iperf, manakala WireGuard "meningkatkan"nya kepada 5 Mbit/saat yang sama.

Konfigurasi WireGuard pada 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

Konfigurasi WireGuard pada MS (ditambahkan 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 peringkat kedua, saya mengarahkan pelanggan WireGuard ke port 51821. Secara teorinya, ini tidak perlu, kerana pelanggan akan mewujudkan sambungan dari mana-mana port tanpa hak percuma, tetapi saya membuatnya supaya ia mungkin untuk melarang 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 pelayan dan pelanggan OpenVPN

Pelayan 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

Pelanggan 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

Saya menggunakan easy-rsa untuk menjana sijil

Sumber: www.habr.com

Tambah komen