ProHoster > blog > administrasi > Migrasi dari OpenVPN ke WireGuard untuk menggabungkan jaringan menjadi satu jaringan L2

Migrasi dari OpenVPN ke WireGuard untuk menggabungkan jaringan menjadi satu jaringan L2

Migrasi dari OpenVPN ke WireGuard untuk menggabungkan jaringan menjadi satu jaringan L2

Saya ingin berbagi pengalaman menggabungkan jaringan di tiga apartemen yang jauh secara geografis, yang masing-masing menggunakan router dengan OpenWRT sebagai gateway, menjadi satu jaringan umum. Saat memilih metode untuk menggabungkan jaringan antara L3 dengan subnet routing dan L2 dengan bridging, ketika semua node jaringan akan berada di subnet yang sama, preferensi diberikan ke metode kedua, yang lebih sulit dikonfigurasi, tetapi memberikan lebih banyak peluang, karena transparan penggunaan teknologi direncanakan dalam jaringan yang dibuat Wake-on-Lan dan DLNA.

Bagian 1: Latar Belakang

OpenVPN awalnya dipilih sebagai protokol untuk mengimplementasikan tugas ini, karena, pertama, dapat membuat perangkat tap yang dapat ditambahkan ke jembatan tanpa masalah, dan kedua, OpenVPN mendukung operasi melalui protokol TCP, yang juga penting, karena tidak ada apartemen yang memiliki alamat IP khusus, dan saya tidak dapat menggunakan STUN, karena untuk beberapa alasan ISP saya memblokir koneksi UDP yang masuk dari jaringan mereka, sedangkan protokol TCP memungkinkan saya untuk meneruskan port server VPN pada VPS sewaan menggunakan SSH. Ya, pendekatan ini memberikan beban besar, karena data dienkripsi dua kali, tetapi saya tidak ingin memasukkan VPS ke jaringan pribadi saya, karena masih ada risiko pihak ketiga mendapatkan kendali atasnya, oleh karena itu, memiliki a perangkat di jaringan rumah sangat tidak diinginkan dan diputuskan untuk membayar keamanan dengan biaya overhead yang besar.

Untuk meneruskan port pada router yang direncanakan untuk menyebarkan server, program sshtunnel digunakan. Saya tidak akan menjelaskan seluk-beluk konfigurasinya - ini dilakukan dengan cukup mudah, saya hanya mencatat bahwa tugasnya adalah meneruskan TCP port 1194 dari router ke VPS. Selanjutnya, server OpenVPN dikonfigurasikan pada perangkat tap0, yang terhubung ke jembatan br-lan. Setelah memeriksa koneksi ke server yang baru dibuat dari laptop, menjadi jelas bahwa ide port forwarding membenarkan dirinya sendiri dan laptop saya menjadi anggota jaringan router, meskipun secara fisik tidak ada di dalamnya.

Masalahnya tetap kecil: perlu untuk mendistribusikan alamat IP di apartemen yang berbeda sehingga mereka tidak berkonflik dan mengkonfigurasi router sebagai klien OpenVPN.
Alamat IP router dan rentang server DHCP berikut dipilih:

  • 192.168.10.1 dengan jangkauan 192.168.10.2 - 192.168.10.80 untuk server
  • 192.168.10.100 dengan jangkauan 192.168.10.101 - 192.168.10.149 untuk router di apartemen No. 2
  • 192.168.10.150 dengan jangkauan 192.168.10.151 - 192.168.10.199 untuk router di apartemen No. 3

Itu juga diperlukan untuk menetapkan alamat ini dengan tepat ke router klien dari server OpenVPN dengan menambahkan baris ke konfigurasinya:

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

dan menambahkan baris berikut ke file /etc/openvpn/ipp.txt:

flat1_id 192.168.10.100
flat2_id 192.168.10.150

di mana flat1_id dan flat2_id adalah nama perangkat yang ditentukan saat membuat sertifikat untuk terhubung ke OpenVPN

Selanjutnya, klien OpenVPN dikonfigurasi pada router, perangkat tap0 pada keduanya ditambahkan ke jembatan br-lan. Pada tahap ini, semuanya tampak beres, karena ketiga jaringan saling melihat dan bekerja secara keseluruhan. Namun, ternyata detail yang tidak terlalu menyenangkan: terkadang perangkat bisa mendapatkan alamat IP bukan dari router mereka, dengan semua konsekuensi selanjutnya. Untuk beberapa alasan, router di salah satu apartemen tidak punya waktu untuk merespons DHCPDISCOVER tepat waktu dan perangkat menerima alamat yang salah. Saya menyadari bahwa saya perlu memfilter permintaan seperti itu di tap0 pada masing-masing router, tetapi ternyata, iptables tidak dapat bekerja dengan perangkat jika itu adalah bagian dari jembatan dan ebtables harus membantu saya. Saya menyesal, itu tidak ada di firmware saya dan saya harus membangun kembali gambar untuk setiap perangkat. Dengan melakukan ini dan menambahkan baris berikut ke /etc/rc.local dari setiap router, masalah terpecahkan:

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.

Bagian 2: Memperkenalkan WireGuard

Baru-baru ini, Internet semakin membicarakan WireGuard, mengagumi kesederhanaan konfigurasinya, kecepatan transfer tinggi, ping rendah dengan keamanan yang sebanding. Mencari informasi lebih lanjut tentang hal itu membuat jelas bahwa tidak bekerja sebagai anggota jembatan atau bekerja melalui protokol TCP didukung olehnya, yang membuat saya berpikir bahwa masih belum ada alternatif untuk OpenVPN bagi saya. Jadi saya menunda untuk mengenal WireGuard.

Beberapa hari yang lalu, berita menyebar melalui sumber daya yang terkait dengan TI bahwa WireGuard akhirnya akan dimasukkan ke dalam kernel Linux, dimulai dengan versi 5.6. Artikel berita, seperti biasa, memuji WireGuard. Saya kembali terjun ke dalam pencarian cara untuk menggantikan OpenVPN lama yang bagus. Kali ini saya bertemu artikel ini. Itu berbicara tentang membuat terowongan Ethernet melalui L3 menggunakan GRE. Artikel ini memberi saya harapan. Masih belum jelas apa yang harus dilakukan dengan protokol UDP. Pencarian membawa saya ke artikel tentang menggunakan socat bersama dengan terowongan SSH untuk meneruskan port UDP, namun, mereka mencatat bahwa pendekatan ini hanya berfungsi dalam mode koneksi tunggal, yang berarti bahwa beberapa klien VPN tidak mungkin dilakukan. Saya mendapatkan ide untuk menyiapkan server VPN di VPS, dan menyiapkan GRE untuk klien, tetapi ternyata, GRE tidak mendukung enkripsi, yang akan mengarah pada fakta bahwa jika pihak ketiga mendapatkan akses ke server , semua lalu lintas antar jaringan saya ada di tangan mereka yang sama sekali tidak cocok untuk saya.

Sekali lagi, keputusan dibuat untuk mendukung enkripsi yang berlebihan, dengan menggunakan VPN melalui VPN menurut skema berikut:

Lapisan XNUMX VPN:
VPS adalah server dengan alamat internal 192.168.30.1
MS adalah klien VPS dengan alamat internal 192.168.30.2
MK2 adalah klien VPS dengan alamat internal 192.168.30.3
MK3 adalah klien VPS dengan alamat internal 192.168.30.4

Lapisan XNUMX VPN:
MS adalah server dengan alamat eksternal 192.168.30.2 dan internal 192.168.31.1
MK2 adalah klien MS dengan alamat 192.168.30.2 dan memiliki IP internal 192.168.31.2
MK3 adalah klien MS dengan alamat 192.168.30.2 dan memiliki IP internal 192.168.31.3

* MS - router-server di apartemen 1, MK2 - router di apartemen 2, MK3 - router di apartemen 3
* Konfigurasi perangkat dipublikasikan di spoiler di akhir artikel.

Jadi, ping antara node jaringan 192.168.31.0/24 pergi, saatnya beralih ke pengaturan terowongan GRE. Sebelumnya, agar tidak kehilangan akses ke router, ada baiknya menyiapkan terowongan SSH untuk meneruskan port 22 ke VPS, sehingga, misalnya, router dari apartemen 10022 akan tersedia di port 2 VPS, dan a router dari apartemen 11122 akan tersedia di port 3 VPS router dari apartemen XNUMX. Yang terbaik adalah mengonfigurasi penerusan dengan sshtunnel yang sama, karena ini akan memulihkan terowongan jika jatuh.

Terowongan dikonfigurasi, Anda dapat terhubung ke SSH melalui port yang diteruskan:

ssh root@МОЙ_VPS -p 10022

Selanjutnya, nonaktifkan OpenVPN:

/etc/init.d/openvpn stop

Sekarang mari kita siapkan terowongan GRE di router dari apartemen 2:

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

Dan tambahkan antarmuka yang dibuat ke jembatan:

brctl addif br-lan grelan0

Mari lakukan prosedur serupa di router server:

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

Dan, juga, tambahkan antarmuka yang dibuat ke bridge:

brctl addif br-lan grelan0

mulai saat ini, ping mulai berhasil masuk ke jaringan baru dan saya, dengan puas, pergi minum kopi. Kemudian, untuk melihat bagaimana jaringan di ujung lain kabel bekerja, saya mencoba SSH ke salah satu komputer di apartemen 2, tetapi klien ssh membeku tanpa meminta kata sandi. Saya mencoba untuk terhubung ke komputer ini melalui telnet pada port 22 dan melihat garis dari mana Anda dapat memahami bahwa koneksi sedang dibuat, server SSH merespons, tetapi untuk beberapa alasan tidak menawarkan saya untuk masuk.

$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1

Saya mencoba menyambungkannya melalui VNC dan saya melihat layar hitam. Saya meyakinkan diri sendiri bahwa masalahnya ada di komputer jarak jauh, karena saya dapat dengan mudah terhubung ke router dari apartemen ini menggunakan alamat internal. Namun, saya memutuskan untuk SSH ke komputer ini melalui router dan terkejut menemukan bahwa koneksi berhasil dan komputer jarak jauh berfungsi dengan baik tetapi juga gagal terhubung ke komputer saya.

Saya mengeluarkan perangkat grelan0 dari jembatan dan memulai OpenVPN di router di apartemen 2 dan memastikan jaringan berfungsi dengan baik lagi dan koneksi tidak terputus. Mencari Saya menemukan forum di mana orang mengeluh tentang masalah yang sama, di mana mereka disarankan untuk menaikkan MTU. Tidak lama kemudian diucapkan daripada dilakukan. Namun, hingga MTU disetel ke nilai yang cukup besar yaitu 7000 untuk perangkat gretap, koneksi TCP terputus atau transmisi lambat diamati. Karena MTU yang tinggi untuk gretap, MTU untuk koneksi WireGuard dari level pertama dan kedua masing-masing ditetapkan ke 8000 dan 7500.

Saya melakukan pengaturan serupa pada router dari apartemen 3, dengan satu-satunya perbedaan adalah antarmuka gretap kedua bernama grelan1 ditambahkan ke router server, yang juga ditambahkan ke jembatan br-lan.

Semuanya bekerja. Sekarang Anda dapat memasukkan rakitan gretap ke pengisian otomatis. Untuk ini:

Tempatkan baris ini di /etc/rc.local pada router di apartemen 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

Menambahkan ini ke /etc/rc.local di router di apartemen 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 di router server:

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

Setelah me-reboot router klien, saya menemukan bahwa karena alasan tertentu mereka tidak terhubung ke server. Menghubungkan ke SSH mereka (untungnya, saya sebelumnya telah mengonfigurasi sshtunnel untuk ini), ditemukan bahwa WireGuard karena alasan tertentu membuat rute untuk titik akhir, meskipun salah. Jadi, untuk 192.168.30.2, tabel rute ditentukan di tabel rute melalui antarmuka pppoe-wan, yaitu melalui Internet, meskipun rute ke sana seharusnya diarahkan melalui antarmuka wg0. Setelah menghapus rute ini, koneksi dipulihkan. Saya tidak dapat menemukan instruksi di mana pun tentang cara memaksa WireGuard untuk tidak membuat rute ini. Selain itu, saya bahkan tidak mengerti apakah ini fitur OpenWRT, atau WireGuard itu sendiri. Tanpa harus berurusan dengan masalah ini untuk waktu yang lama, saya cukup menambahkan ke kedua router dalam skrip yang dilingkarkan oleh penghitung waktu, baris yang menghapus rute ini: 

route del 192.168.30.2

Meringkas

Saya belum mencapai penolakan total terhadap OpenVPN, karena kadang-kadang saya perlu terhubung ke jaringan baru dari laptop atau ponsel, dan menyiapkan perangkat gretap pada umumnya tidak mungkin, tetapi meskipun demikian, saya mendapat keuntungan dalam transfer data kecepatan antar apartemen dan, misalnya, menggunakan VNC tidak lagi merepotkan. Ping sedikit menurun, tetapi menjadi lebih stabil:

Saat 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

Saat 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

Ini sebagian besar dipengaruhi oleh ping tinggi ke VPS yaitu sekitar 61.5ms

Namun, kecepatannya meningkat secara signifikan. Jadi, di apartemen dengan router-server, saya memiliki kecepatan koneksi internet 30 Mbps, dan di apartemen lain 5 Mbps. Pada saat yang sama, saat menggunakan OpenVPN, saya tidak dapat mencapai kecepatan transfer data antar jaringan lebih dari 3,8 Mbps menurut iperf, sementara WireGuard "memompa" hingga 5 Mbps yang sama.

Konfigurasi WireGuard di 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 di MS (ditambahkan ke /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 (ditambahkan ke /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 (ditambahkan ke /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 dijelaskan untuk VPN tingkat kedua, saya menentukan port 51821 untuk klien WireGuard Secara teori, ini tidak diperlukan, karena klien akan membuat koneksi dari port non-istimewa gratis mana pun, tetapi saya membuatnya agar semua koneksi yang masuk dapat ditolak pada antarmuka wg0 dari semua router, kecuali koneksi UDP yang masuk pada port 51821.

Saya harap artikel itu bermanfaat bagi seseorang.

PS Juga, saya ingin membagikan skrip saya yang mengirimi saya pemberitahuan PUSH ke ponsel saya di aplikasi WirePusher ketika perangkat baru muncul di jaringan saya. Berikut ini tautan ke skrip: github.com/r0ck3r/device_discover.

MEMPERBARUI: Server OpenVPN dan konfigurasi klien

Server 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

Klien 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 menghasilkan sertifikat.

Sumber: www.habr.com

Tambah komentar