Her biri ağ geçidi olarak OpenWRT'li yönlendiriciler kullanan, coğrafi olarak birbirinden uzak üç dairedeki ağları tek bir ortak ağda birleştirme deneyimimi paylaşmak istiyorum. Alt ağ yönlendirmeli L3 ve köprülemeli L2 arasındaki ağları birleştirmek için bir yöntem seçerken, tüm ağ düğümleri aynı alt ağda olacaksa, yapılandırılması daha zor olan ancak şeffaf olduğu için daha fazla fırsat sağlayan ikinci yöntem tercih edildi. oluşturulan ağ Wake-on-Lan ve DLNA'da teknolojilerin kullanımı planlandı.
Bölüm 1: Arka Plan
OpenVPN başlangıçta bu görevi gerçekleştirmek için protokol olarak seçildi, çünkü ilk olarak köprüye sorunsuz bir şekilde eklenebilen bir dokunma cihazı oluşturabilir ve ikincisi, OpenVPN TCP protokolü üzerinden çalışmayı destekler ki bu da önemliydi, çünkü dairelerin hiçbirinin özel bir IP adresi yoktu ve ben STUN'u kullanamadım, çünkü bir nedenden dolayı ISP'm kendi ağlarından gelen UDP bağlantılarını bloke ederken, TCP protokolü kiralık VPS'deki VPN sunucu portunu SSH kullanarak iletmeme izin verdi. Evet, bu yaklaşım büyük bir yük getiriyor, çünkü veriler iki kez şifreleniyor, ancak VPS'yi özel ağıma dahil etmek istemedim, çünkü hala üçüncü tarafların kontrolü ele geçirme riski vardı, bu nedenle böyle bir şeye sahip olmak ev ağındaki cihaz son derece istenmeyen bir durumdu ve güvenlik için büyük bir ek yük ile ödeme yapılmasına karar verildi.
Sunucuyu dağıtmanın planlandığı yönlendiricideki bağlantı noktasını iletmek için sshtunnel programı kullanıldı. Yapılandırmasının inceliklerini açıklamayacağım - bu oldukça kolay bir şekilde yapılır, sadece görevinin yönlendiriciden VPS'ye 1194 numaralı TCP bağlantı noktasını iletmek olduğunu not ediyorum. Ardından, br-lan köprüsüne bağlı olan tap0 cihazında OpenVPN sunucusu yapılandırıldı. Dizüstü bilgisayardan yeni oluşturulan sunucuya bağlantıyı kontrol ettikten sonra, bağlantı noktası yönlendirme fikrinin haklı çıktığı ve dizüstü bilgisayarım fiziksel olarak içinde olmasa da yönlendiricinin ağına üye olduğu anlaşıldı.
Mesele küçük kaldı: IP adreslerini çakışmamaları ve yönlendiricileri OpenVPN istemcileri olarak yapılandırmamaları için farklı dairelere dağıtmak gerekiyordu.
Aşağıdaki yönlendirici IP adresleri ve DHCP sunucu aralıkları seçildi:
- 192.168.10.1 menzilli 192.168.10.2 - 192.168.10.80 sunucu için
- 192.168.10.100 menzilli 192.168.10.101 - 192.168.10.149 2 numaralı dairedeki bir yönlendirici için
- 192.168.10.150 menzilli 192.168.10.151 - 192.168.10.199 3 numaralı dairedeki bir yönlendirici için
Yapılandırmasına bir satır ekleyerek OpenVPN sunucusunun istemci yönlendiricilerine tam olarak bu adresleri atamak da gerekliydi:
ifconfig-pool-persist /etc/openvpn/ipp.txt 0ve /etc/openvpn/ipp.txt dosyasına şu satırları ekleyin:
flat1_id 192.168.10.100
flat2_id 192.168.10.150
burada flat1_id ve flat2_id, OpenVPN'e bağlanmak için sertifikalar oluşturulurken belirtilen cihaz adlarıdır.
Ardından, yönlendiricilerde OpenVPN istemcileri yapılandırıldı, her ikisindeki tap0 cihazları br-lan köprüsüne eklendi. Bu aşamada, her üç ağ da birbirini gördüğü ve bir bütün olarak çalıştığı için her şey yolunda görünüyordu. Bununla birlikte, çok hoş olmayan bir ayrıntı ortaya çıktı: bazen cihazlar, sonraki tüm sonuçlarla birlikte yönlendiricilerinden olmayan bir IP adresi alabilir. Nedense, apartmanlardan birindeki yönlendiricinin DHCPDISCOVER'a zamanında yanıt verecek vakti olmadı ve cihaz yanlış adres aldı. Bu tür istekleri her yönlendiricide tap0'da filtrelemem gerektiğini fark ettim, ancak ortaya çıktı ki, iptables bir köprünün parçasıysa bir cihazla çalışamaz ve imdadıma ebtables gelir. Maalesef donanım yazılımımda yoktu ve her cihaz için görüntüleri yeniden oluşturmak zorunda kaldım. Bunu yaparak ve bu satırları her yönlendiricinin /etc/rc.local dosyasına ekleyerek sorun çözüldü:
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
Bu yapılandırma üç yıl sürdü.
Bölüm 2: WireGuard Tanıtımı
Son zamanlarda, İnternet, yapılandırmasının basitliğine, yüksek aktarım hızına, karşılaştırılabilir güvenlikle düşük ping'e hayran kalarak WireGuard hakkında giderek daha fazla konuşuyor. Bununla ilgili daha fazla bilgi aramak, ne köprü üyesi olarak çalışmayı ne de TCP protokolü üzerinden çalışmayı desteklemediğini açıkça ortaya koydu, bu da benim için hala OpenVPN'in alternatifi olmadığını düşündürdü. Bu yüzden WireGuard'ı tanımayı erteledim.
Birkaç gün önce, WireGuard'ın 5.6 sürümünden başlayarak nihayet Linux çekirdeğine dahil edileceği haberi BT ile ilgili kaynaklarda öyle ya da böyle yayıldı. Haber makaleleri, her zaman olduğu gibi, WireGuard'ı övdü. Yine eski güzel OpenVPN'i değiştirmenin yollarını aramaya koyuldum. bu sefer rastladım . GRE kullanarak L3 üzerinden bir Ethernet tüneli oluşturmaktan bahsediyordu. Bu yazı bana umut verdi. UDP protokolü ile ne yapılacağı belirsizliğini koruyordu. Arama beni, bir UDP bağlantı noktasını iletmek için bir SSH tüneli ile birlikte socat kullanma hakkında makalelere götürdü, ancak, bu yaklaşımın yalnızca tekli bağlantı modunda çalıştığını, yani birden çok VPN istemcisinin imkansız olacağı anlamına geldiğini belirttiler. Bir VPS'de bir VPN sunucusu kurma ve istemciler için GRE kurma fikrini buldum, ancak ortaya çıktığı gibi, GRE şifrelemeyi desteklemiyor, bu da üçüncü tarafların sunucuya erişmesi durumunda , ağlarım arasındaki tüm trafik onların elinde ve bu bana hiç uymuyordu.
Yine, aşağıdaki şemaya göre VPN üzerinden VPN kullanılarak yedekli şifreleme lehine karar verildi:
Katman XNUMX VPN'i:
VPS olduğunu sunucu dahili adres 192.168.30.1 ile
MS olduğunu müşteri Dahili adresi 192.168.30.2 olan VPS
MK2 olduğunu müşteri Dahili adresi 192.168.30.3 olan VPS
MK3 olduğunu müşteri Dahili adresi 192.168.30.4 olan VPS
Katman XNUMX VPN'i:
MS olduğunu sunucu harici adres 192.168.30.2 ve dahili 192.168.31.1 ile
MK2 olduğunu müşteri MS 192.168.30.2 adresli ve 192.168.31.2 dahili IP'li
MK3 olduğunu müşteri MS 192.168.30.2 adresli ve 192.168.31.3 dahili IP'li
* MS - daire 1'deki yönlendirici-sunucu, MK2 - daire 2'deki yönlendirici, MK3 - daire 3'teki yönlendirici
* Cihaz konfigürasyonları yazının sonundaki spoiler kısmında yayınlanmıştır.
Ve böylece, 192.168.31.0/24 ağının düğümleri arasındaki pingler gider, GRE tünelini kurmaya geçme zamanı. Bundan önce, yönlendiricilere erişimi kaybetmemek için, 22 numaralı bağlantı noktasını VPS'ye iletmek için SSH tünelleri kurmaya değer, böylece, örneğin, VPS'nin 10022 numaralı bağlantı noktasında daire 2'den bir yönlendirici mevcut olacaktır Daire 11122'deki yönlendirici, VPS'nin 3 numaralı bağlantı noktasında mevcut olacaktır. Daire XNUMX'teki yönlendirici. Düşmesi durumunda tüneli geri yükleyeceğinden, yönlendirmeyi aynı sshtunnel ile yapılandırmak en iyisidir.
Tünel yapılandırıldı, yönlendirilen bağlantı noktası üzerinden SSH'ye bağlanabilirsiniz:
ssh root@МОЙ_VPS -p 10022Ardından, OpenVPN'i devre dışı bırakın:
/etc/init.d/openvpn stopŞimdi daire 2'deki yönlendiricide bir GRE tüneli oluşturalım:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up
Ve oluşturulan arayüzü köprüye ekleyin:
brctl addif br-lan grelan0
Sunucu yönlendirici üzerinde benzer bir prosedür gerçekleştirelim:
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up
Ayrıca, oluşturulan arayüzü köprüye ekleyin:
brctl addif br-lan grelan0
bu andan itibaren pingler yeni ağa başarıyla gitmeye başlıyor ve ben memnuniyetle kahve içmeye gidiyorum. Ardından, kablonun diğer ucundaki ağın nasıl çalıştığını görmek için, apartman 2'deki bilgisayarlardan birine SSH girmeye çalışıyorum, ancak ssh istemcisi bana parola sormadan donuyor. Bu bilgisayara 22 numaralı bağlantı noktasında telnet üzerinden bağlanmaya çalışıyorum ve bağlantının kurulduğunu anlayabileceğiniz bir satır görüyorum, SSH sunucusu yanıt veriyor ama nedense girmemi teklif etmiyor.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
VNC üzerinden bağlanmaya çalışıyorum ve siyah bir ekran görüyorum. Sorunun uzaktaki bilgisayarda olduğuna kendimi ikna ediyorum çünkü dahili adresi kullanarak bu daireden yönlendiriciye kolayca bağlanabiliyorum. Ancak, yönlendirici aracılığıyla bu bilgisayara SSH yapmaya karar verdim ve bağlantının başarılı olduğunu ve uzak bilgisayarın iyi çalıştığını ancak bilgisayarıma da bağlanamadığını görünce şaşırdım.
Grelan0 cihazını köprüden çıkarıp 2. apartmandaki yönlendiricide OpenVPN'i başlatıyorum ve ağın tekrar düzgün çalıştığından ve bağlantıların kesilmediğinden emin oluyorum. Arama yaparken, insanların aynı sorunlardan şikayet ettikleri, MTU'yu yükseltmelerinin önerildiği forumlarla karşılaşıyorum. Daha erken olmaz dedi ve bitirdi. Bununla birlikte, MTU gretap cihazları için yeterince büyük bir değer olan 7000'e ayarlanana kadar, ya TCP bağlantılarının kesildiği ya da yavaş iletimler gözlemlendi. Gretap için yüksek MTU nedeniyle, birinci ve ikinci seviyelerin WireGuard bağlantıları için MTU'lar sırasıyla 8000 ve 7500 olarak ayarlandı.
Daire 3'teki yönlendiricide benzer bir kurulum yaptım, tek fark, br-lan köprüsüne de eklenen sunucu yönlendiricisine grelan1 adlı ikinci bir gretap arabiriminin eklenmesiydi.
Her şey çalışıyor. Artık gretap düzeneğini otomatik yüklemeye koyabilirsiniz. Bunun için:
Bu satırları, daire 2'deki yönlendiricide /etc/rc.local dizinine yerleştirdim:
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
Bunu apartman 3'teki yönlendiricide /etc/rc.local dosyasına ekledi:
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
Ve sunucu yönlendiricisinde:
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
İstemci yönlendiricilerini yeniden başlattıktan sonra, herhangi bir nedenle sunucuya bağlanmadıklarını gördüm. SSH'lerine bağlanarak (neyse ki bunun için daha önce sshtunnel'i yapılandırmıştım), WireGuard'ın bir nedenden dolayı uç nokta için bir rota oluşturduğu, ancak yanlış olduğu keşfedildi. Yani, 192.168.30.2 için, rota tablosunda pppoe-wan arabirimi, yani İnternet üzerinden yönlendirme tablosu belirtildi, ancak ona giden yolun wg0 arabirimi üzerinden yönlendirilmesi gerekiyordu. Bu rotayı sildikten sonra bağlantı yeniden sağlandı. WireGuard'ı bu rotaları oluşturmamaya zorlama konusunda hiçbir yerde talimat bulamadım. Üstelik bunun OpenWRT'nin mi yoksa WireGuard'ın mı bir özelliği olduğunu anlamadım. Bu sorunla uzun süre uğraşmak zorunda kalmadan, her iki yönlendiriciye de bir zamanlayıcı tarafından döngülenen bir betikte, bu rotayı silen bir satır ekledim:
route del 192.168.30.2
Özetleme
Bazen bir dizüstü bilgisayardan veya telefondan yeni bir ağa bağlanmam gerektiğinden ve bunlara bir gretap cihazı kurmak genellikle imkansız olduğundan, henüz OpenVPN'i tamamen reddetmedim, ancak buna rağmen veri aktarımında bir avantajım var daireler arasında hız ve örneğin VNC kullanmak artık elverişsiz değil. Ping biraz azaldı, ancak daha kararlı hale geldi:
OpenVPN kullanırken:
[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
WireGuard'ı kullanırken:
[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
Çoğunlukla, yaklaşık 61.5 ms olan yüksek VPS pinginden etkilenir.
Ancak hız önemli ölçüde arttı. Yani, yönlendirici-sunucusu olan bir apartman dairesinde 30 Mbps ve diğer dairelerde 5 Mbps İnternet bağlantı hızım var. Aynı zamanda, OpenVPN kullanırken, iperf'e göre ağlar arasında 3,8 Mbps'den fazla veri aktarım hızı elde edemezken, WireGuard bunu aynı 5 Mbps'ye "pompaladı".
VPS'de WireGuard yapılandırması[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
MS'te WireGuard yapılandırması (/etc/config/network'e eklendi)
#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'
MK2'de WireGuard yapılandırması (/etc/config/network'e eklendi)
#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'
MK3'de WireGuard yapılandırması (/etc/config/network'e eklendi)
#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'
İkinci seviye VPN için açıklanan yapılandırmalarda, WireGuard istemcilerine bağlantı noktası 51821'i belirtiyorum.Teorik olarak, istemci ayrıcalıklı olmayan herhangi bir ücretsiz bağlantı noktasından bağlantı kuracağından bu gerekli değildir, ancak gelen tüm bağlantıların olmasını sağladım 0 numaralı bağlantı noktasında gelen UDP bağlantıları dışında tüm yönlendiricilerin wg51821 arabirimlerinde reddedilebilir.
Umarım makale birileri için faydalı olur.
PS Ayrıca, ağımda yeni bir cihaz göründüğünde WirePusher uygulamasında telefonuma PUSH bildirimi gönderen scriptimi paylaşmak istiyorum. İşte betiğin bağlantısı: .
GÜNCELLEME: OpenVPN sunucusu ve istemci yapılandırması
OpenVPN sunucusu
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-lzoOpenVPN istemcisi
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
Sertifika oluşturmak için easy-rsa kullandım.
Kaynak: habr.com