VPN və veb üçün bir ictimai host: rolları necə bölmək olar

Bir maşın hər üç ehtiyacı eyni anda ödəyə bilər: tunelləri bağlamaq, HTTPS-ə cavab vermək və iki özəl LAN arasında yönləndirmək. Bunun məqbul olub-olmaması kağız üzərində həll edə biləcəyiniz üç şeydən asılıdır: ictimai adresin sahibi kimdir, hər port və protokol cütünün sahibi kimdir və hansı prosesə paketləri yönləndirməyə icazə verilir. Bunları düzgün etsəniz, ortaq host adi bir şey olur. Səhv etsəniz, təmiz başlayan və heç vaxt cavab verməyən bir xidmətə həftə sonu sərf edəcəksiniz.

Aşağıdakılar tikinti vərəqi deyil, qərar prosedurudur. Hər addım yeni əlavə etdiyiniz rolun həqiqətən təcrid olunduğunu sübut edən yoxlama ilə bitir.

Portlardan əvvəl adresin sahibini seçin

Tunel son nöqtəsi və veb server bir nüvəni paylaşa bilər; eyni anda bir adresi, portu və protokolu paylaşmaq uğursuz olan şeydir. WireGuard adətən UDP 51820 portunu tutur, OpenVPN UDP 1194 və ya TCP 443 tutur, veb server isə TCP 443 tutur. Ağrıdan olan cüt HTTPS-in yanında TCP 443 üzərindən OpenVPN-dir, çünki ikisi də eyni soketi istəyir və nüvə onu ilk bağlanana verir. Yalnız qarşıda duran demultipleksator, məsələn sslh və ya TLS-i anlayan proksi, onlara həmin portu paylaşmağa imkan verir və bu, nasazlığı tam olaraq firewall problemi kimi görünən bir komponent əlavə edir.

Dəyişiklik etməzdən əvvəl sahiblərə baxın: ss -lntup hər dinləyən soket üçün yerli adresi, portu və prosesi çap edir. İki sətirdə 0.0.0.0:443 görünməsi ikinci xidmətin heç vaxt bağlanmadığını göstərir, init skripti nə qədər şən olsa da. Körpü sahibi də dəyişir. eth0 ilə br0 birləşdikdə, IP br0 adresinə keçir və adı eth0 olan hər firewall qaydası uyğunluğu dayandırır, ona görə xidmətləri körpüyə bağlayın və bununla təsdiqləyin: ip -br addr.

Eyni sahiblik qaydası virtual maşınlarda ortaya çıxan bir sürprizi izah edir. Eyni LAN-da qonaq daxilində işləyən tunel serveri qonağın adresini saxlayır, buna görə hostun öz adresinə yönələn bağlantılar hostda qalır və qonağın tuneli onları heç vaxt görmür, müştəri profili nə təklif edirsə etsin.

İki LAN arasında marşrutlaşdırma və ya bir tərəfi NAT etmək

Bir-birini görməyən iki LAN hər biri ictimai hosta zəng edə bilər, host da sonra tunellər arasında yönləndirir. Bu marşrutlaşdırılmış dizayn üç şey tələb edir: yönləndirmənin açılması, hər uzaq prefiksə işarə edən marşrut və tranzitə icazə verən yönləndirmə siyasəti. sysctl -w net.ipv4.ip_forward=1 birincisini, ip route add 10.20.0.0/24 dev wg1 ikincisini, və belə bir nftables sətri nft add rule inet filter forward iifname "wg0" oifname "wg1" accept üçüncüsünü örtür.

Mənbə NAT-ı əlavə etmək asan, sazlamaq çətindir. Maskaradlaşdırma müştəri adresini yenidən yazır, buna görə uzaq tərəf həqiqi hostu deyil, habı görür və onun giriş qaydaları və jurnalları aidiyyət üçün faydalı olmaqdan çıxır. Hər iki şəbəkə sizindirsə, marşrutlaşdırın. Bir tərəf geri marşrut əlavə etməyəcək üçüncü tərəfə aiddirsə, NAT bu həftə çatdırıla bilən variantdır. Hər halda adres planını yazın, çünki üst-üstə düşən iki /24 heç bir konfiqurasiya ilə marşrutlaşdırıla bilməz.

Dizüstü üçün internet çıxışı rolunu oynamaq eyni qutunun gələn tunelləri bağlamasına mane olmur. Buna yalnız üst-üstə düşən adreslər mane olur, buna görə adres planı vacib olan sənəddir.

İki rol dayandırılmış halda bölməni sınayın

Faydalı sınaq çıxmadır: iki rolu dayandırın və üçüncünün hələ də cavab verdiyini təsdiqləyin. Tunel xidməti söndürülmüş halda veb sorğusu tamamlanmalı, veb server dayandırılmış halda tunel əl sıxması tamamlanmalıdır. Əgər hər ikisi yalnız hər şey işləyəndə işləyirsə, təsadüfi asılılığınız var: ortaq firewall cədvəli, səhv marşrut və ya yanlış adresa işarə edən ad.

Üç əmr bu sınağı konkretləşdirir. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ xarici DNS olmadan yerli dinləyicinin cavab verdiyini sübut edir, wg show müştəridə əl sıxmasının tamamlandığını sübut edir və tcpdump -ni any port 51820 habda marşrut problemini açar problemindən ayırır. Tutmada heç görünməyən əl sıxması hostdan əvvəl ölüb: provayder firewall-u, səhv ictimai adres və ya yolda NAT qaydası.

Yönləndirilən LAN-lar üçün çıxmanı təkrarlayın. Bir peer ayrılmış halda hab üzərindən ping uğursuz olmalıdır; yenidən qoşulanda ping heç bir qaydaya toxunmadan bərpa olunmalıdır. Yalnız tuneli yenidən başlatdıqdan sonra bərpa olunan ping çatımlılığa deyil, siyasətə işarə edir və bu başqa bir düzəlişdir.

Rolları çıxarkən qayda dəstini oxunaqlı saxlayın. nft list ruleset həqiqətən ehtiyacınız olan hər istiqamət üçün bir qəbul qaydası göstərməlidir, hər şeyi qəbul edən forward zənciri isə ayrım deyil, işlək demodur.

Yalnız IPv6 olan giriş xətləri və IPv4 xidmətləri

Bəzi giriş xətləri yalnız IPv6 çatımlılığı verir və xidmətlər hələ də IPv4 üzərindən yayımlanmalıdır. Tunelin özü hələ trafik keçirən ailə üzərindən gedir, yayımlanan xidmət isə tunelin içindəki bir adresdə oturur. Bu, adi fərziyyəni tərsinə çevirir və monitorinqi səssizcə pozur: IPv4 yolu üçün yazılmış firewall qaydası və ya uptime yoxlaması artıq heç nə daşımayan interfeysi izləyir.

Hər ailəni ayrıca curl -4 və curl -6 ilə yoxlayın, çünki bir uğurlu sorğu sınamadığınız yol haqqında heç nə demir. Port sahibliyi ailələr arasında dəyişmir, amma dinləyici dəyişir: ss -lntup IPv4 və IPv6 soketlərini ayrı sətirlər kimi göstərir və 0.0.0.0:443 əhatə etmir [::]:443 proses ikili yığım soketi istəməsə.

Bir ailədə cavab verib digərində imtina edən xidmət adətən dinləyici problemidir, marşrut problemi deyil. Dizaynı bitmiş adlandırmazdan əvvəl təsdiqləyin ki, hər rol öz adresinə və ya portuna sahibdir, yönləndirmə açıqdır və icazəlidir, və hər rol digər ikisi dayandırılmış halda hələ də cavab verir.