İki sayt, bir subnet, bir WireGuard hub: işlək hala gətirin

Hər iki sayt eyni LAN aralığından istifadə edir və dizaynı əslində pozan şey üst-üstə düşmə deyil. Hub saytı yalnız təyinat ünvanına görə seçməlidir və iki eyni təyinat ona seçim üçün heç nə vermir. İşləyən bir ofisi tunelə uyğunlaşdırmaq üçün yenidən nömrələmək, adətən, hər dərc olunan xidmətə tunelin daşıya biləcəyi ayrıca ünvan verməkdən daha pis bir mübadilədir. Aşağıdakı dizayn hər sayt üçün bir HTTPS xidməti dərc edir, başqa heç nə.

Niyə üst-üstə düşmə əsl problem deyil

WireGuard təyinata görə yönləndirir: peer-in AllowedIPs dəyərləri paketi hansı peer-in alacağını müəyyən edir. İki peer eyni anda 10.10.7.0/24 elan edə bilməz, biri hər axtarışı qazanmadan. Bu, tunelin deyil, peer cədvəlinin xassəsidir; buna görə buradakı həll marşrut hiyləsi deyil, ünvan planıdır.

Plan LAN-ı ümumiyyətlə elan etməyi dayandırmaqdır. Əvəzində hər xidmət üçün bir ləqəb elan edin, hər sayt üçün bir ünvan, və hər saytın şlüzü həmin ləqəbi öz real tətbiqinə çevirsin.

İstifadəçi iki unikal ünvanı marşrutlaşdırır, qeyri-müəyyən prefiksi heç vaxt görmür və iki ofisin heç birində heç nə dəyişmir. Bu həm də sərhədi dürüst qoyur: siz hər saytdan bir HTTPS xidməti dərc edirsiniz, iki şəbəkəni birləşdirmirsiniz. Ardınca gələn qaydalar kiçik qalır, çünki ifadə dardır. Daha geniş ifadə daha geniş qaydalar tələb edərdi və bu dizaynlar məhz belə mürəkkəbləşir.

Hər sayta istifadəçinin marşrutlaşdıra biləcəyi bir ləqəb verin

Ünvanları istifadəçinin maşınında, hubda və ya iki LAN-ın heç birində heç nə ilə ziddiyyət təşkil etməyən aralıqdan seçin. Burada hub 10.66.0.1, istifadəçi 10.66.0.10, şlüzlər 10.66.0.21 və 10.66.0.22, iki ləqəb isə 10.77.1.20 və 10.77.2.20-dir. Hub hər ləqəbi ona sahib olan peer vasitəsilə dərc edir, buna görə bir ləqəbə ünvanlanmış çıxan paket yalnız uyğun saytdan çıxa bilər:

[Interface]
Address = 10.66.0.1/32
ListenPort = 51820
PrivateKey = HUB_KEY

[Peer]
PublicKey = USER_PUBLIC_KEY
AllowedIPs = 10.66.0.10/32

[Peer]
PublicKey = SITE_A_PUBLIC_KEY
AllowedIPs = 10.66.0.21/32, 10.77.1.20/32

[Peer]
PublicKey = SITE_B_PUBLIC_KEY
AllowedIPs = 10.66.0.22/32, 10.77.2.20/32

İstifadəçi tərəfinə yalnız iki ləqəb lazımdır, bu da müştəri konfiqurasiyasını hər iki LAN prefiksindən azad saxlayır. Həmin konfiqurasiyada heç nə real LAN-ların heç birini qeyd etmir:

[Interface]
Address = 10.66.0.10/32
PrivateKey = USER_KEY

[Peer]
PublicKey = HUB_PUBLIC_KEY
Endpoint = hub.example.net:51820
AllowedIPs = 10.77.1.20/32, 10.77.2.20/32
PersistentKeepalive = 25

Hər şlüz hubu və istifadəçi mənbəyini elan edir, başqa heç nə, buna görə bir sayt heç vaxt digər saytın LAN-ını öyrənmir. Keepalive saytın yuxarı kanalında NAT uyğunlaşdırmasını saxlayır; o, trafikə icazə vermir və firewall hələ də nəyin qəbul ediləcəyinə qərar verir. Bir şlüzün konfiqurasiyasını digərinə köçürmək, özəl açar, interfeys ünvanı və ləqəb hamısı dəyişdiyi müddətcə qaydasındadır.

Hub iki peer-i arasında nəyə icazə verməlidir

Hub paketləri öz peer-lərindən ikisi arasında ötürür, bu da giriş qərarı deyil, forward zəncirində qərardır. IPv4 yönləndirməsini platformanın adi mexanizmi ilə aktivləşdirin, sonra dizaynın ehtiyac duyduğu cütlərə dəqiq icazə verin.

Aşağıdakı qayda istifadəçiyə bir ləqəbə və bir porta giriş icazəsi verir və geri trafikə bağlantı izləmə vasitəsilə icazə verir. Forward yolundakı hər şeyi rədd edir, məqsəd də budur:

nft add table inet hub_transit
nft add chain inet hub_transit forward '{ type filter hook forward priority 0 ; policy drop ; }'
nft add rule inet hub_transit forward ct state established,related accept
nft add rule inet hub_transit forward iifname wg0 oifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 accept

İki detalı qeyd etməyə dəyər, çünki onlar səssiz uğursuzluqlara səbəb olur. Bir baza zəncirindəki accept digərindəki drop-u üstələmir, buna görə bunu mövcud siyasətlə birləşdirin, yanına yükləməyin. Və mənbə ünvanı şəxsi deyil, cihazı identifikasiya edir; tətbiq autentifikasiyasını şəbəkə qəbulundan ayrı saxlayın.

Ləqəbin real ünvana çevrildiyi yer

Sayt A 10.77.1.20 üçün sorğu alır, təyinatı real tətbiqə yenidən yazır və mənbəyi öz LAN ünvanına yenidən yazır ki, cavab tunelə marşrut olmadan qayıda bilsin. Hər iki tərcüməni bir yerdə etmək şəbəkənin qalan hissəsini ləqəbdən xəbərsiz saxlayır. Aşağıdakı qaydalar bütün mexanizmdir:

nft add table ip site_a_nat
nft add chain ip site_a_nat pre '{ type nat hook prerouting priority -100 ; policy accept ; }'
nft add chain ip site_a_nat post '{ type nat hook postrouting priority 100 ; policy accept ; }'
nft add rule ip site_a_nat pre iifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 dnat to 10.10.7.20:443
nft add rule ip site_a_nat post iifname wg0 oifname lan0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.10.7.20 snat to 10.10.7.2

Sayt A-nın forward siyasəti sonra tərcümə olunmuş axını tunel interfeysindən LAN interfeysinə, üstəgəl geri istiqaməti qəbul etməlidir. Forward qarmağı təyinatı təyinat tərcüməsindən sonra və mənbə yenidən yazılmasından əvvəl görür, buna görə qayda real tətbiq ünvanını adlandırır. Bir qayda heç nəyə uyğun gəlmirmiş kimi görünəndə bu iki qarmağı bu sıra ilə oxuyun. Ləqəbə qarşı yazılmış forward qaydası heç vaxt uyğun gələ bilməz, çünki ləqəb həmin qarmaqda artıq mövcud deyil.

Sayt B bunu öz ləqəbi və öz açarı ilə təkrarlayır. O, Sayt A-nın özəl açarını təkrar istifadə etməməlidir, çünki iki peer-in bir kimliyi paylaşması görməsi çətin və fayl köçürməklə yaratması asan olan konfiqurasiya səhvidir. Hər iki şlüz sənədini fərqlənməli olan dəyərlər istisna olmaqla eyni saxlayın ki, fərq baxışda seçilsin. Köçürülmüş fayl həmin nasazlığın adi mənbəyidir.

Mənbənin yenidən yazılmasının bir qiyməti var. Tətbiq şlüzü öz müştərisi kimi görür, buna görə jurnalları artıq hansı istifadəçinin qoşulduğunu göstərmir. Şlüzün audit izini saxlayın və tərcümənin aradan qaldırdığı şəbəkə kimliyini kompensasiya etmək üçün tətbiq girişini zəiflətməyin.

Hər iki dərc olunmuş adın cavab verdiyini necə sübut etmək olar

Hər ləqəbə DNS adı verin və tətbiqi və sertifikatı həmin ad üçün konfiqurasiya edin, çünki tərcümə yönləndirmələri və ya daxil edilmiş mütləq URL-ləri yenidən yazmır. Sayt başına bir ad istifadə edin ki, sertifikat uyğunsuzluğu heç vaxt marşrut nasazlığı kimi qəbul edilməsin.

Real müştəridən sınaqdan keçirin, hansı saytın cavab verdiyini təsdiqləyin və icazəsiz bir portu da sınayın. Hər hansı NAT dəyişikliyindən sonra yeni bağlantılardan istifadə edin, çünki qurulmuş vəziyyət köhnə uyğunlaşdırmanı saxlayır:

wg show wg0 allowed-ips
sudo nft list ruleset
curl -sS -o /dev/null -w "%{http_code}\n" https://site-a.example.net/

Birinci əmrdə boş və ya gözlənilməz ləqəb, hər hansı firewall qaydası vacib olmadan peer seçiminin səhv olduğunu bildirir. Ləqəb düzdürsə və ad hələ də işləmirsə, problem DNS və sertifikatlara keçmişdir. Hər iki ad cavab verən kimi və üçüncü port bağlı qaldıqca, dizayn iddia etdiyini edir: iki dar dərc olunmuş xidmət, iki birləşdirilmiş LAN deyil.