pfSense OpenVPN: başqa marşrutlaşdırıcının arxasındakı şəbəkəyə çatmaq

Noutbukunuz VPN üzərindən pfSense LAN-na çatır və yenə də iki hopp daha içəridə olan xidmətə çata bilmir, fərq isə hər sahib üçün bir marşrut qərarıdır. Paket gediş-dönüşünü tamamlamazdan əvvəl üç cihaz razılaşmalıdır: müştəri, firewall və təyinat şəbəkəsinə həqiqətən sahib olan marşrutlaşdırıcı. Onlardan hər hansı birini qaçırsanız, simptom eyni görünür.

Bir qaydanı dəyişməzdən əvvəl bir paketi bu üç qərardan keçirin, çünki hər sahibin fərqli nəzarəti və fərqli uğursuzluq rejimi var.

Bir paket, üç marşrut qərarı

Müştəri təyinatın tunelə aid olub-olmadığını qərarlaşdırır və yalnız bildiklərinə əsaslanaraq qərar verə bilər: itələnmiş marşrut, yerli marşrut və ya artıq hər şeyi əhatə edən defolt. pfSense paketin sonra hara göndəriləcəyini qərarlaşdırır, bu isə başqa marşrutlaşdırıcının arxasındakı şəbəkə üçün düzgün interfeysdə çatıla bilən şlüz vasitəsilə statik marşrut deməkdir. Aşağı axındakı marşrutlaşdırıcı VPN hovuzuna geri yol bilib-bilmədiyini qərarlaşdırır və bilmirsə, cavab atılır və ya faydasız bir yerə göndərilir. Hər qərar digər ikisindən asılı deyil.

Hər hansı birinin uğursuzluğu eyni istifadəçi hesabatını yaradır. Buna görə sazlama sırası alətlərdən daha vacibdir.

Müştəriyə prefiks verin, təxmin yox

IPv4 tunel şəbəkəsi /30-dan böyük olan pfSense SSL/TLS serverində IPv4 Local network(s) sahəsi qoşulduqda marşrutları müştərilərə paylayır. Aşağı axındakı prefiksi müştərinin birini uydurmasına güvənmək əvəzinə ora əlavə edin. Sonra qoşulduqdan sonra müştərinin faktiki cədvəlini oxuyun, çünki route-nopull olan profil və ya marşrut filtri serverin göndərdiyini görməzlikdən gələ bilər. Server tamamilə düzgün ola bilər, halbuki müştəri heç nə quraşdırmır.

Digər server rejimləri və topologiyaların fərqli məhdudiyyətləri var və hər müştəri və ya bağlantı siyasəti müəyyən müştərinin nə aldığını dəyişə bilər. Əhəmiyyətli olan müştəridə yoxlayın, hansı müştərini ilk sınaqdan keçirdiyinizdən asılı olmayaraq.

pfSense-i daxili marşrutlaşdırıcıya yönəldin

pfSense-də statik marşrut üçün müəyyən edilmiş və çatıla bilən şlüz lazımdır və həmin şlüz üçün seçilən interfeys ona həqiqətən çatan interfeys olmalıdır, Netgate statik marşrut bələdçisi bunu təsvir edir. İllüstrativ bir sxemdə tranzit keçidi firewall-da 192.168.77.1 və daxili marşrutlaşdırıcıda 192.168.77.2-dir, xidmət şəbəkəsi isə onun arxasında 172.16.30.0/25-dir. Sonra marşrut prefiksi və növbəti hoppu adlandırır, xidmət ünvanını yox. Uzaq şəbəkədən bir ünvanı şlüz kimi istifadə etmək düzgün görünən və heç yerə yönləndirməyən marşrut qurmağın geniş yayılmış yoludur.

İnterfeysə ad vermək onun arxasındakı şəbəkələri təsvir etmir. Statik marşrut həmin təsvirdir.

Uzaq tərəf hovuzu bilməlidir

Aşağı axındakı marşrutlaşdırıcıya hovuz üçün geri marşrut lazımdır, bu nümunədə 192.168.77.1 vasitəsilə 10.55.0.0/24, əgər defolt və ya dinamik protokol artıq birini təmin etmirsə. Xidmət hostunun öz şlüzü həmin marşrutlaşdırıcıya doğru aparmalıdır, bu adətən marşrutlaşdırıcı onun defolt şlüzü olduqda doğrudur və host əl ilə konfiqurasiya edildikdə yanlışdır. Firewall-dakı siyasət marşrutlaşdırması da müəyyən trafik üçün cədvəli üstələyə bilər, buna görə marşrutun yanlış olduğu qənaətinə gəlməzdən əvvəl bir qaydanın fərqli şlüz seçib-seçmədiyini yoxlayın.

Bu dizayn üçün tərcümə tələb olunmur və müştərinin mənbə ünvanını görünən saxlamaq aşağı axındakı şəbəkəyə öz siyasətini tətbiq etməyə imkan verir.

Qəbul üçün bir təzə sorğunu tunel girişindən, firewall-un daxili çıxışından və təyinatdan gələn cavabdan keçirin. Əvəzində tərcümə qəsdən istifadə olunursa, aşağı axındakı şəbəkənin gördüyü mənbəni və cavabın necə geri gəlməsinin gözləndiyini qeyd edin.

Üç sahibin planını icazə verilən tətbiqlə birlikdə saxlayın ki, növbəti administrator yolu yenidən kəşf etmək əvəzinə onu bərpa edə bilsin.