Router VPN işləyir, amma LAN müştərilərində internet yoxdur

Status tunelin qalxdığını deyir, routerin özündəki brauzer səhifələri açır, arxasındakı hər cihaz isə hələ də vaxt aşımı verir. Bu birləşmə problemi əksər VPN təlimatlarının heç qeyd etmədiyi bir qata daraldır: router paketləri tuneldən keçməli olan yeganə host deyil. Yerli yaranan trafik və yönləndirilən trafik eyni qutu içindən fərqli yollarla keçir. Müştəridən sınaq keçir və fərq nəzəri olmaqdan çıxır.

Nasazlığı LAN hostundan oxuyun

Uğursuz olan cihazdan başlayın, çünki routerdə diaqnostika keçirmək başqa suala cavab verir. Müştərinin defolt şlüzunun bu router olduğunu təsdiqləyin, onun mənbə ünvanını və alt şəbəkəsini qeyd edin, sonra routerin tunel interfeysindən nə çıxdığına baxın.

Müştərinin ünvanı tərcümə olunursa, uzaq tərəf tunel ünvanını görür və oradan hər şey sağlam görünür, halbuki müştəri hələ də uğursuz olur. Əgər tərcümə olunmursa, uzaq tərəf müştəri alt şəbəkəsinə geri marşrut bilməlidir və bir çox şlüzda belə marşrut defolt olaraq yoxdur. Hər iki halda routerin öz uğuru əhəmiyyətsizdir, çünki onun paketləri yerli yaranıb və yönləndirmə yolundan heç keçməyib.

Yerli trafik və yönləndirilən trafik fərqlidir

Linux və əksər router proqram təminatı qutunun özünün yaratdığı paketlərlə ondan keçən paketlərə fərqli yanaşır. Çıxış zənciri birinci növü, yönləndirmə zənciri ikinci növü görür və routerin öz trafikinə uyğunlaşdırılmış siyasət yönləndirməni toxunulmaz qoya bilər.

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

Yönləndirmənin ümumiyyətlə aktiv olduğunu yoxlayın, sonra çıxış zənciri yerinə yönləndirmə zəncirini oxuyun. Şifrələnmiş xarici bağlantıya icazə verən qayda, şifri açılmış paketlərin yönləndirilməsinə icazə verən qayda deyil və ikisini qarışdırmaq məhz bu simptomu doğurur. Tunelin qalxması yalnız birincini sübut edir.

Geri yol da mövcud olmalıdır

Mənbə tərcüməsi geri yolun lazım olub-olmadığını müəyyən edir. Tunel interfeysində maskaradla cavablar tunel ünvanına qayıdır və router onları geri tərcümə edir. Bu olmadan uzaq şlüz müştəri alt şəbəkəsinə açıq marşrut və həmin istiqamətə icazə verən öz siyasətinə ehtiyac duyur.

Nəyisə dəyişməzdən əvvəl yerləşdirmənin iki dizayndan hansını istifadə etdiyini qeyd edin, çünki düzəlişlər əks istiqamətlərə yönəlir. Tərcümə əlavə etmək çatışmayan geri marşrutu gizlədir və orijinal mənbə ünvanına ehtiyac duyan proqramları pozur. Tərcüməsiz geri marşrut əlavə etmək uzaq firewall tanış olmayan mənbəni atanda səssizcə uğursuz olur. Birini seçin, sənədləşdirin və digər tərəfi ona uyğunlaşdırın.

Müştəri DNS-i eyni baxışa aiddir. Routerin həlledicisi cavab verə bilər, halbuki başqa serverə yönəlmiş müştəri heç nə almır.

Bir icazəli və bir rədd edilmiş axını yoxlayın

Düzəlişdən sonra mövcud router sessiyası yerinə müştəridən yeni bağlantı sınayın. Sonra tuneldən istifadə etməməli olan seqmentin hələ də istifadə etmədiyini təsdiqləyin.

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

Uzaq tərəfdə müşahidə olunan mənbə ünvanını yoxlayın, çünki bu, hansı dizaynın həqiqətən işlədiyini bildirir. Ünvanla yanaşı ad sorğusunu da yoxlayın, çünki həlledici davranışı eyni qutudan keçən ayrı bir yoldur.

Qaydaları tunelə ehtiyac duyan müştəri şəbəkələri ilə məhdudlaşdırın və bir sınağı keçirmək üçün yönləndirmə filtrini söndürməyə müqavimət göstərin. Bu dəyişiklik sınağı düzəldir və tunelin təmin etməli olduğu sərhədi aradan qaldırır. Mənbə ünvanını, tərcümə qərarını və geri marşrutu tarixlə birlikdə bir qeydə yazın.