Mən hər biri OpenWRT ilə marşrutlaşdırıcıları şlüz kimi istifadə edən üç coğrafi baxımdan uzaq mənzillərdə şəbəkələri bir ümumi şəbəkədə birləşdirmək təcrübəmi bölüşmək istərdim. Bütün şəbəkə qovşaqlarının eyni alt şəbəkədə olacağı zaman L3-ün alt şəbəkə marşrutlaşdırması və L2-nin körpü ilə birləşdirilməsi metodunu seçərkən, konfiqurasiya etmək daha çətin olan, lakin şəffaf olduğundan daha çox imkan verən ikinci üsula üstünlük verilir. yaradılmış Wake-on-Lan və DLNA şəbəkəsində texnologiyalardan istifadə nəzərdə tutulmuşdu.
1-ci hissə: Fon
OpenVPN əvvəlcə bu tapşırığı yerinə yetirmək üçün protokol olaraq seçildi, çünki birincisi, körpüyə heç bir problem olmadan əlavə edilə bilən bir tap cihazı yarada bilər, ikincisi, OpenVPN TCP protokolu üzərində əməliyyatı dəstəkləyir, bu da vacib idi, çünki mənzillərin heç birinin xüsusi IP ünvanı yox idi və mən STUN-dan istifadə edə bilmədim, çünki nədənsə mənim ISP öz şəbəkələrindən daxil olan UDP bağlantılarını bloklayır, TCP protokolu isə SSH istifadə edərək icarəyə götürülmüş VPS-də VPN server portunu yönləndirməyə imkan verirdi. Bəli, bu yanaşma böyük yük verir, çünki məlumatlar iki dəfə şifrələnir, lakin mən VPS-ni şəxsi şəbəkəmə təqdim etmək istəmədim, çünki üçüncü tərəflərin ona nəzarəti ələ keçirməsi riski hələ də var idi, buna görə də belə bir Ev şəbəkəsindəki cihaz son dərəcə arzuolunmaz idi və təhlükəsizlik üçün böyük bir yüklə ödəməyə qərar verildi.
Serverin yerləşdirilməsi planlaşdırılan marşrutlaşdırıcıdakı portu yönləndirmək üçün sshtunnel proqramından istifadə edilmişdir. Mən onun konfiqurasiyasının incəliklərini təsvir etməyəcəyəm - bu olduqca asanlıqla edilir, sadəcə qeyd edirəm ki, onun vəzifəsi 1194 nömrəli TCP portunu marşrutlaşdırıcıdan VPS-ə ötürmək idi. Sonra OpenVPN serveri br-lan körpüsünə qoşulmuş tap0 cihazında konfiqurasiya edildi. Noutbukdan yeni yaradılmış serverlə əlaqəni yoxladıqdan sonra məlum oldu ki, port yönləndirmə ideyası özünü doğrultdu və mənim laptopum fiziki olaraq içərisində olmasa da, marşrutlaşdırıcının şəbəkəsinin üzvü oldu.
Məsələ kiçik olaraq qaldı: IP ünvanlarını fərqli mənzillərdə yaymaq lazım idi ki, onlar bir-birinə zidd olmasın və marşrutlaşdırıcıları OpenVPN müştəriləri kimi konfiqurasiya etsinlər.
Aşağıdakı marşrutlaşdırıcı IP ünvanları və DHCP server diapazonları seçildi:
- 192.168.10.1 diapazonu ilə 192.168.10.2 - 192.168.10.80 server üçün
- 192.168.10.100 diapazonu ilə 192.168.10.101 - 192.168.10.149 2 nömrəli mənzildə marşrutlaşdırıcı üçün
- 192.168.10.150 diapazonu ilə 192.168.10.151 - 192.168.10.199 3 nömrəli mənzildə marşrutlaşdırıcı üçün
Həmçinin konfiqurasiyasına xətt əlavə etməklə OpenVPN serverinin müştəri marşrutlaşdırıcılarına məhz bu ünvanları təyin etmək lazım idi:
ifconfig-pool-persist /etc/openvpn/ipp.txt 0və /etc/openvpn/ipp.txt faylına aşağıdakı sətirləri əlavə edin:
flat1_id 192.168.10.100
flat2_id 192.168.10.150
burada flat1_id və flat2_id OpenVPN-ə qoşulmaq üçün sertifikatlar yaradılarkən göstərilən cihaz adlarıdır
Sonra, OpenVPN müştəriləri marşrutlaşdırıcılarda konfiqurasiya edildi, hər ikisində tap0 cihazları br-lan körpüsünə əlavə edildi. Bu mərhələdə hər şey qaydasında görünürdü, çünki hər üç şəbəkə bir-birini görür və bütövlükdə işləyir. Bununla belə, çox da xoş olmayan bir təfərrüat ortaya çıxdı: bəzən qurğular bütün sonrakı nəticələrlə öz marşrutlaşdırıcısından deyil, IP ünvanını ala bilirdi. Nədənsə, mənzillərin birindəki marşrutlaşdırıcının DHCPDISCOVER-a vaxtında cavab verməyə vaxtı olmadı və cihaz səhv ünvan aldı. Anladım ki, hər marşrutlaşdırıcıda tap0-da bu cür sorğuları süzgəcdən keçirməliyəm, lakin məlum oldu ki, iptables körpünün bir hissəsidirsə və ebtables mənə kömək etməlidirsə, cihazla işləyə bilməz. Təəssüf edirəm ki, bu, mənim proqram təminatımda deyildi və mən hər bir cihaz üçün şəkilləri yenidən qurmalı oldum. Bunu etməklə və bu xətləri hər bir marşrutlaşdırıcının /etc/rc.local-a əlavə etməklə problem həll olundu:
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 konfiqurasiya üç il davam etdi.
Hissə 2: WireGuard təqdimatı
Son zamanlar İnternet WireGuard haqqında getdikcə daha çox danışır, onun konfiqurasiyasının sadəliyinə, yüksək ötürmə sürətinə, müqayisə edilə bilən təhlükəsizliklə aşağı pingə heyran qalır. Bu barədə daha çox məlumat axtarmaq aydın oldu ki, nə körpü üzvü kimi işləmək, nə də TCP protokolu üzərində işləmək onun tərəfindən dəstəklənmir, bu da məni düşünməyə vadar etdi ki, OpenVPN-ə mənim üçün hələ də alternativ yoxdur. Ona görə də WireGuard ilə tanışlığı təxirə saldım.
Bir neçə gün əvvəl bu və ya digər şəkildə İT ilə əlaqəli resurslarda xəbər yayıldı ki, WireGuard nəhayət 5.6 versiyasından başlayaraq Linux nüvəsinə daxil ediləcək. Xəbər məqalələri, həmişə olduğu kimi, WireGuard-ı təriflədi. Yenidən yaxşı köhnə OpenVPN-i əvəz etməyin yollarını axtarmağa başladım. Bu dəfə rastlaşdım . GRE-dən istifadə edərək L3 üzərindən Ethernet tunelinin yaradılmasından bəhs edilirdi. Bu yazı mənə ümid verdi. UDP protokolu ilə nə edəcəyi aydın deyildi. Axtarış məni UDP portunu yönləndirmək üçün SSH tuneli ilə birlikdə socat-dan istifadə haqqında məqalələrə apardı, lakin onlar qeyd etdilər ki, bu yanaşma yalnız bir əlaqə rejimində işləyir, yəni birdən çox VPN müştərisi mümkün olmayacaq. Mən VPS-də VPN server qurmaq və müştərilər üçün GRE qurmaq ideyası ilə çıxış etdim, lakin məlum oldu ki, GRE şifrələməni dəstəkləmir, bu da üçüncü tərəflərin serverə giriş əldə etməsinə səbəb olacaq. , şəbəkələrim arasındakı bütün trafik onların əlindədir, bu da mənə heç uyğun gəlmirdi.
Yenə də, aşağıdakı sxemə uyğun olaraq VPN üzərindən VPN istifadə edərək, lazımsız şifrələmənin lehinə qərar verildi:
Layer XNUMX VPN:
VPS edir server daxili ünvanı ilə 192.168.30.1
MS edir müştəri Daxili ünvanı olan VPS 192.168.30.2
MK2 edir müştəri Daxili ünvanı olan VPS 192.168.30.3
MK3 edir müştəri Daxili ünvanı olan VPS 192.168.30.4
Layer XNUMX VPN:
MS edir server xarici ünvan 192.168.30.2 və daxili 192.168.31.1
MK2 edir müştəri MS 192.168.30.2 ünvanı ilə və 192.168.31.2 daxili IP-yə malikdir.
MK3 edir müştəri MS 192.168.30.2 ünvanı ilə və 192.168.31.3 daxili IP-yə malikdir.
* MS - mənzil 1-də marşrutlaşdırıcı-server, MK2 - 2 nömrəli mənzildə marşrutlaşdırıcı, MK3 - 3 nömrəli mənzildə marşrutlaşdırıcı
* Cihaz konfiqurasiyaları məqalənin sonundakı spoylerdə dərc olunub.
Beləliklə, 192.168.31.0/24 şəbəkəsinin qovşaqları arasında pinglər getdi, GRE tunelinin qurulmasına keçməyin vaxtı gəldi. Bundan əvvəl, marşrutlaşdırıcılara girişi itirməmək üçün 22-ci portu VPS-ə yönləndirmək üçün SSH tunellərini qurmağa dəyər ki, məsələn, 10022-ci mənzildən bir marşrutlaşdırıcı VPS-in 2 portunda mövcud olsun və 11122-ci mənzildən olan marşrutlaşdırıcı VPS-nin 3-ci portunda mövcud olacaq.Mənzil XNUMX-dən marşrutlaşdırıcı. Eyni sshtunnel ilə yönləndirməni konfiqurasiya etmək daha yaxşıdır, çünki o, düşdüyü halda tuneli bərpa edəcək.
Tunel konfiqurasiya edilib, siz ötürülən port vasitəsilə SSH-ə qoşula bilərsiniz:
ssh root@МОЙ_VPS -p 10022Sonra, OpenVPN-i deaktiv edin:
/etc/init.d/openvpn stopİndi mənzil 2-dən marşrutlaşdırıcıda GRE tuneli quraq:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up
Yaradılmış interfeysi körpüyə əlavə edin:
brctl addif br-lan grelan0
Server marşrutlaşdırıcısında oxşar proseduru yerinə yetirək:
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up
Həm də yaradılmış interfeysi körpüyə əlavə edin:
brctl addif br-lan grelan0
bu andan etibarən pinglər yeni şəbəkəyə uğurla getməyə başlayır və mən məmnuniyyətlə qəhvə içməyə gedirəm. Sonra telin o biri ucundakı şəbəkənin necə işlədiyini görmək üçün 2-ci mənzildəki kompüterlərdən birinə SSH keçirməyə çalışıram, lakin ssh müştərisi məndən parol tələb etmədən donur. Mən bu kompüterə 22 nömrəli portda telnet vasitəsilə qoşulmağa çalışıram və bağlantının qurulduğunu, SSH serverinin cavab verdiyini başa düşə biləcəyiniz bir xətt görürəm, amma nədənsə mənə daxil olmağı təklif etmir.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
Mən ona VNC vasitəsilə qoşulmağa çalışıram və qara ekran görürəm. Özümü inandırıram ki, məsələ uzaq kompüterdədir, çünki daxili ünvandan istifadə edərək bu mənzildən routerə asanlıqla qoşula bilirəm. Bununla belə, mən marşrutlaşdırıcı vasitəsilə bu kompüterə SSH tətbiq etmək qərarına gəldim və əlaqənin uğurlu olduğunu və uzaq kompüterin yaxşı işlədiyini, lakin mənim kompüterimə də qoşula bilmədiyini görəndə təəccüblənirəm.
Mən grelan0 cihazını körpüdən çıxarıram və 2-ci mənzildə marşrutlaşdırıcıda OpenVPN-i işə salıram və şəbəkənin yenidən düzgün işlədiyinə və bağlantıların kəsilmədiyinə əmin oluram. Axtarışda insanların eyni problemlərdən şikayətləndiyi forumlara rast gəlirəm, orada MTU-nu qaldırmağı məsləhət görürəm. Daha tez deyildi. Bununla belə, MTU gretap cihazları üçün kifayət qədər böyük olan 7000 dəyərinə təyin olunana qədər ya TCP bağlantıları azaldı, ya da yavaş ötürülmə müşahidə edildi. Qretap üçün yüksək MTU səbəbindən birinci və ikinci səviyyəli WireGuard əlaqələri üçün MTU-lar müvafiq olaraq 8000 və 7500 olaraq təyin edildi.
Mən 3-cü mənzildən marşrutlaşdırıcıda oxşar quraşdırma etdim, yeganə fərq odur ki, grelan1 adlı ikinci gretap interfeysi server marşrutlaşdırıcısına əlavə edildi və bu da br-lan körpüsünə əlavə edildi.
Hər şey işləyir. İndi gretap montajını avtomatik yükləməyə qoya bilərsiniz. Bunun üçün:
Bu xətləri 2-ci mənzildəki marşrutlaşdırıcıda /etc/rc.local-a yerləşdirin:
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 mənzil 3-dəki marşrutlaşdırıcıda /etc/rc.local-a əlavə etdi:
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
Və server marşrutlaşdırıcısında:
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
Müştəri marşrutlaşdırıcılarını yenidən işə saldıqdan sonra onların nədənsə serverə qoşulmadığını gördüm. Onların SSH-yə qoşulduqda (xoşbəxtlikdən, mən əvvəllər bunun üçün sshtunnel konfiqurasiya etmişdim), məlum oldu ki, WireGuard nədənsə səhv olduğu halda son nöqtə üçün marşrut yaradır. Beləliklə, 192.168.30.2 üçün marşrut cədvəli pppoe-wan interfeysi vasitəsilə, yəni İnternet vasitəsilə marşrut cədvəlində göstərildi, baxmayaraq ki, ona marşrut wg0 interfeysi vasitəsilə yönəldilməli idi. Bu marşrut silindikdən sonra əlaqə bərpa olundu. WireGuard-ı bu marşrutları yaratmamağa məcbur etmək barədə heç bir yerdə təlimat tapa bilmədim. Üstəlik, bunun OpenWRT və ya WireGuard-ın bir xüsusiyyəti olduğunu belə başa düşmədim. Uzun müddət bu problemlə məşğul olmaq məcburiyyətində qalmadan, sadəcə olaraq hər iki marşrutlaşdırıcıya taymer tərəfindən dövrələnmiş skriptdə bu marşrutu silən bir xətt əlavə etdim:
route del 192.168.30.2
Ümumiləşdirərək
Mən hələ OpenVPN-dən tamamilə imtina etməmişəm, çünki bəzən noutbukdan və ya telefondan yeni bir şəbəkəyə qoşulmalı oluram və onlarda qretap cihazı qurmaq ümumiyyətlə mümkün deyil, lakin buna baxmayaraq məlumat ötürülməsində üstünlük əldə etdim. mənzillər arasında sürət və məsələn, VNC-dən istifadə etmək artıq əlverişsiz deyil. Ping bir qədər azaldı, lakin daha sabit oldu:
OpenVPN istifadə edərkən:
[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 istifadə edərkən:
[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
Əsasən təxminən 61.5ms olan VPS-ə yüksək ping-dən təsirlənir
Bununla belə, sürət əhəmiyyətli dərəcədə artıb. Beləliklə, marşrutlaşdırıcı-server olan bir mənzildə İnternetə qoşulma sürətim 30 Mbps, digər mənzillərdə isə 5 Mbps-dir. Eyni zamanda, OpenVPN-dən istifadə edərkən iperf-ə görə şəbəkələr arasında 3,8 Mbit/s-dən çox məlumat ötürmə sürətinə nail ola bilmədim, WireGuard isə onu eyni 5 Mbit/s-ə qədər “pompaladı”.
VPS-də WireGuard konfiqurasiyası[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-də WireGuard konfiqurasiyası (/etc/config/network-ə əlavə edilib)
#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-də WireGuard konfiqurasiyası (/etc/config/network-ə əlavə edilib)
#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-də WireGuard konfiqurasiyası (/etc/config/network-ə əlavə edilib)
#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 səviyyəli VPN üçün təsvir edilən konfiqurasiyalarda mən WireGuard müştəriləri üçün 51821 portunu təyin edirəm.Nəzəri olaraq bu lazım deyil, çünki müştəri hər hansı bir pulsuz qeyri-imtiyazlı portdan əlaqə quracaq, lakin mən bunu elə etdim ki, bütün daxil olan əlaqələr 0 portunda daxil olan UDP əlaqələri istisna olmaqla, bütün marşrutlaşdırıcıların wg51821 interfeyslərində rədd edilə bilər.
Ümid edirəm ki, məqalə kimsə üçün faydalı olacaq.
PS Həmçinin, şəbəkəmdə yeni cihaz görünəndə WirePusher proqramında telefonuma PUSH bildirişi göndərən skriptimi paylaşmaq istəyirəm. Budur skriptə keçid: .
UPDATE: OpenVPN server və müştərilərin konfiqurasiyası
OpenVPN Server
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 müştəri
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
Sertifikatlar yaratmaq üçün easy-rsa istifadə etdim.
Mənbə: www.habr.com