Saytlararası və uzaqdan giriş VPN-i: ikisi nəyi birləşdirir

Hər iki dizayn VPN adlanır və onlar fərqli problemləri həll edir. Saytlararası tunel iki şlüzü birləşdirir, buna görə onların arxasındakı hər host heç nə quraşdırmadan qarşı tərəfdə icazə verilmiş ünvanlara çata bilir. Uzaqdan giriş tuneli ayrı-ayrı cihazları şəbəkəyə birləşdirir, hər dəfə bir müştəri. Müqayisə vacibdir, çünki yerləşdirmə səhvlərinin əksəriyyəti birini konfiqurasiya edib digərinin davranışını gözləməkdən yaranır və simptom adətən tunelin həqiqətən çatdığı xidmətdə baş verən gözləmə vaxtıdır.

İki dizayn, iki sərhəd

Dizaynların heç biri LAN yayım domenini genişləndirmir. Qarşı tərəfdəki cihazlar yerli kəşf siyahısında görünmür və onların görünməsini gözləmək ilk əl çəkilməli fərziyyədir. Qəsdən dərc etdiyiniz özəl DNS adları istənilən kəşf protokolundan daha proqnozlaşdırıla biləndir və təchizatçı dəyişikliyindən sonra da qalır.

Bir saytda 10.10.0.0/24, digərində 10.20.0.0/24 götürün. A şlüzünə 10.20.0.0/24 prefiksini tunelə göndərən marşrut və ya trafik seçicisi lazımdır, B şlüzünə isə bunun güzgü əksi lazımdır. Sonra hər iki tərəfdəki hostlar adi IP bağlantısından istifadə edir və tunelin mövcud olduğunu heç vaxt öyrənmir. Bu görünməzlik xüsusiyyətdir və nasazlıqların tunel xətaları kimi deyil, adi şəbəkə xətaları kimi görünməsinin səbəbi də elə budur.

Siyasət əsaslı və marşrut əsaslı eyni tunel deyil

Siyasət əsaslı IPsec yerləşdirməsində razılaşdırılmış trafik seçiciləri hansı mənbə və təyinat cütlərinin qorunduğunu dəqiq müəyyən edir. Bir şlüzün arxasında yeni alt şəbəkə yaranarsa və heç bir seçici onu əhatə etmirsə, tunel işlək qalır və yeni alt şəbəkə sadəcə daşınmır. Marşrut əsaslı dizaynda trafiki interfeys qəbul edir və qərarı marşrut cədvəli verir; buna görə prefiks əlavə etmək tuneli yenidən danışıqdan keçirmək deyil, marşrut dəyişikliyidir.

StrongSwan hər iki görünüşü birbaşa göstərir və onları birlikdə oxumaq hansı modeli həqiqətən yerləşdirdiyinizi anlamağın yoludur.

swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'

Sizi maraqlandıran prefiksi buraxan seçici siyahısı heç bir paket tutmadan nasazlığı izah edir, səhv interfeysə işarə edən marşrut isə geri yolda güzgü nasazlığını izah edir. Hər şeyi yenidən danışıqdan əvvəl hər ikisini oxuyun, çünki açar yeniləmə heç vaxt konfiqurasiya etmədiyiniz seçicini əlavə etməyəcək.

Ünvanlamanı tuneldən əvvəl planlaşdırın

Üst-üstə düşən diapazonlar konfiqurasiya ilə düzəldilə bilməyən dizayn səhvidir. Əgər hər iki sayt 192.168.1.0/24 istifadə edirsə, 192.168.1.50-yə ehtiyacı olan hostun iki namizədi var və seçim imkanı yoxdur. Tunel autentifikasiyadan keçəcək, təhlükəsizlik assosiasiyaları qurulacaq və marşrut qərarı yenə də səhv və ya qeyri-müəyyən olacaq.

Üç dürüst variantdan birini seçin: bir saytı yenidən nömrələyin, kəsişən diapazonu şlüzdə tərcümə edin ki, hər tərəf fərqli prefiks görsün, ya da bu hostlar üçün birbaşa marşrutlaşdırmadan imtina edib xidməti başqa yolla dərc edin. Hər birinin qiyməti var və birincisi adətən iki illik üfüqdə ən ucuzudur. Tunel mövcud olmadan qərar verin, çünki sonradan bu dəyişiklik köhnə ünvana malik hər cihaza toxunur.

MTU məsələsini də erkən həll edin. Tunel istifadə oluna bilən faydalı yükü azaldır və fraqmentasiyaya güvənən dizayn MSS-i şlüzlərdə sabitləyən dizayndan fərqli davranır.

Yönləndirmə və siyasət tuneldən kənardadır

Şlüz tunel interfeysi ilə LAN interfeysi arasında paketləri yönləndirməyə hazır olmalıdır və hər iki istiqamət üçün xidmətə icazə verən siyasət lazımdır. Linux-da bunlar iki ayrı ayardır, üstəlik yönləndirilmiş axına ümumiyyətlə icazə verilib-verilmədiyini müəyyən edən firewall qaydaları.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPT

Qəbul edən host üçüncü qat əlavə edir: onun öz firewall-u hələ də uzaq alt şəbəkədən gələn müştəri qəbul etməlidir. Yalnız yerli /24-ə icazə verən fayl serveri tunelin nə qədər sağlam görünməsindən asılı olmayaraq 10.20.0.7-dən gələn yönləndirilmiş trafiki rədd edəcək və bu rəddi marşrut nasazlığı kimi oxumaq asandır.

Şlüzdən deyil, hostdan test edin

Şlüzün özünün göndərdiyi ping yönləndirilmiş istifadəçi trafikindən fərqli mənbə ünvanına və fərqli siyasətə düşə bilər. Bu onu zəif testə çevirir və bəzən yanıltıcı edir: tətbiq uğursuz olarkən ping uğurlu olur, ya da tətbiq işləyərkən ping uğursuz olur.

ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/null

Real host, real mənbə ünvanı və tətbiqin istifadə etdiyi real protokoldan istifadə edin. Sonra cavab yolunu ayrıca oxuyun, çünki qayıtma marşrutu olmayan işlək irəli istiqamət bloklanmış xidmətlə eyni görünən gözləmə vaxtı yaradır.

Dizaynı cavablandırdığınız suala görə seçin: şəbəkələri birləşdirirsiniz, yoxsa cihazları qəbul edirsiniz? Qalan hər şey, o cümlədən hansı təchizatçını konfiqurasiya etdiyiniz, bu cavabdan irəli gəlir.