WireGuard əl sıxması işləyir, amma ofis alt şəbəkəsi cavab vermir

Əl sıxması tamamlanır, wg show son ötürmə barədə məlumat verir və serverin tunel ünvanı ping-ə cavab verir. Serverin LAN-dakı host isə cavab vermir. Üç şərt eyni vaxtda ödənməlidir: müştəri LAN prefiksini tunelə yönləndirməlidir, server paketləri yönləndirməlidir və cavabın geri qayıtma yolu olmalıdır. Üçündən biri çatışmadıqda simptom eyni olur.

AllowedIPs həm giriş siyahısı, həm də marşrut cədvəlidir

Müştəridə AllowedIPs siyahısı həm həmin peer-ə nəyin göndərilə biləcəyini, həm də WireGuard-ın hansı marşrutları quraşdıracağını müəyyən edir. Yalnız serverin tunel ünvanını sadalayan peer qeydi bir host marşrutu quraşdırır, buna görə LAN təyinatları heç vaxt tunelə daxil olmur. LAN prefiksini əlavə etmək ilk yoxlanmalı şeydir və kopyalanmış konfiqurasiyadan sonra ən çox çatışmayan dəyişiklik də elə budur. Default marşruta genişləndirilmiş peer fərqli bir dizayndır və müştərinin internet trafikini də köçürəcək.

Host marşrutunu və LAN prefiksini ayrı qeydlər kimi saxlayın. Ofisin iki alt şəbəkəsi varsa, hər ikisi siyahıya aiddir və çatışmayan ikinci prefiks ümumi deyil, seçici görünən nasazlıq yaradır.

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.66.0.1/32, 192.168.50.0/24

Yönləndirmə və tərcümə serverdə olmalıdır

Serverdə IP yönləndirmə aktiv olmalı, tuneldən gələn trafiki qəbul edən yönləndirmə qaydası və LAN interfeysinə doğru tərcümə qaydası olmalıdır. Tərcümə ofis şəbəkəsindəki hər hosta toxunmadan dizaynı işlədən şeydir. Sonra cavablar LAN-ın heç vaxt eşitmədiyi ünvana deyil, serverə qayıdır. Bu olmadan hər host tunel alt şəbəkəsi üçün marşrut və ona icazə verən firewall qaydası tələb edər, bu isə başqasının idarə etdiyi şəbəkədə nadir hallarda məqbuldur.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Əl ilə əlavə edilən qaydalar yenidən başlatmada yox olur, ona görə onları server konfiqurasiyasındakı hook əmrləri ilə interfeysə bağlayın. İnterfeysindən daha uzun yaşayan qayda dəsti bir maşının artıq mövcud olmayan tunel üçün trafiki tərcümə etməsi ilə nəticələnir.

LAN köçəndə, qayda isə köçməyəndə

Ofis alt şəbəkəsini yenidən nömrələyən router dəyişdirilməsi bu nasazlığın klassik variantıdır. Tunel qalır, əl sıxması təzə qalır və serverin arxasında heç nə cavab vermir, çünki tərcümə qaydası hələ də köhnə ünvanı göstərir. Quraşdırma skriptləri çox vaxt serverin LAN ünvanını POSTROUTING qaydasına həkk edir və yenidən nömrələmədən sonra o ünvan heç bir interfeysdə mövcud olmur. Sonra paketlər cavab verə bilməyən təyinat ünvanına yenidən yazılır.

iptables -t nat -n -L POSTROUTING
ip -br addr show

İki çıxışı müqayisə edin. İnterfeys siyahısında görünməyən tərcümə hədəfi nasazlığın özüdür və onu düzəltmək, gördükdən sonra bir sətirlik dəyişiklikdir. Qayda WireGuard konfiqurasiyasında deyil, yaradılmış unit-də ola bilər, ona görə redaktədən sonra o unit-i yenidən yükləyin və növbəti açılışın dəyişikliyinizi yenidən yazmadığını təsdiqləyin.

NAT arxasındakı iki saytın görüşəcək yerə ehtiyacı var

Tərəflərdən heç biri gələn bağlantıları qəbul etmədikdə, praktik cavab ictimai ünvana və iki WireGuard interfeysinə malik kiçik bir hostdur. Hər sayt xaricə qoşulur, orta host hər peer-in LAN-ını öz AllowedIPs، və yönləndirmə paketləri iki tunel arasında daşıyır. Heç bir saytın firewall-unda heç nə dəyişməməlidir, buna görə bu dizayn asanlıqla yayılır.

Saytlar arasında marşrutlaşdırma orijinal mənbə ünvanlarını saxlayır və buna görə hər host üzrə jurnallaşdırmanı mənalı saxlayır. İki LAN üst-üstə düşdükdə orta hostda tərcümə etmək daha sadədir, lakin jurnallarda mənbə kimliyi itir. Seçim etməzdən əvvəl hansı xüsusiyyətin vacib olduğuna qərar verin.

Qatları dörd yoxlama ilə ayırın

Üç şeyi dəyişib ümid etmək əvəzinə hər qat üçün bir yoxlama aparın. Birinci hər peer üçün əl sıxmasının yaşını və sayğacları göstərir. İkinci müştərinin həmin təyinatı həqiqətən tunelə yönləndirdiyini göstərir. Üçüncü və dördüncü sorğunun gəlib-gəlmədiyini və gəldikdən sonra hansısa siyasətin onu atıb-atmadığını bildirir.

wg show
ip route get 192.168.50.20
tcpdump -ni wg0 icmp
iptables -vnL FORWARD --line-numbers

Gəlib cavab doğurmayan sorğu cavab yolunu və ya LAN hostunu göstərir. Heç gəlməyən sorğu isə AllowedIPs və ya müştərinin marşrutunu göstərir. Bu iki nəticə fərqli düzəlişlər tələb edir və onları ayıran şey tutmadır.