İki stekli VPN hovuzları: strongSwan-da hər iki ailəyə ünvan vermək

Şluz bir səyyar istifadəçiyə həm IPv4, həm də IPv6 virtual ünvanı verə bilər, halbuki xarici tunel hələ də IPv4 üzərindən gedir. Bunlar ayrı qərarlardır və onları tək qərar kimi qəbul etmək iki stekli planların adətən dağıldığı yerdir. Müştərinin daxili ailələri, çata biləcəyi qorunan prefikslər və inkapsulyasiyanı daşıyan nəqliyyat üç ayrı seçimdir.

Qarışıqlığın çoxu “iki stek” sözünün yalnız bir yerdə iki stekli olan dizayna tətbiq edilməsindən gəlir. Xidmət daxildə iki stekli, xarici ünvanında tək stekli ola bilər və yenə də müştərilər üçün mükəmməl işləyə bilər. Edə bilmədiyi şey təsadüfən işləməkdir.

İçəridə iki ailə, çöldə bir yol

Xarici bağlantı UDP üzərindən IKE-dir və müştərinin harada olmasından asılı olmayaraq bir əlçatan ünvan ailəsi tələb edir. Daxili IPv6 ünvanı IPv6 dəstəkli provayder tələb etmir, çünki daxili paket xarici paketin içindəki yükdür. Bir çox işlək quraşdırma IPv6 prefikslərini yalnız IPv4 olan yuxarı xətt üzərindən daşıyır.

Xarici yolun məhdudlaşdırdığı şey əlçatanlıq və NAT keçididir. Əgər şluz yalnız IPv4 ünvanı elan edirsə, yalnız IPv6 olan şəbəkədəki müştəri nə qədər hovuz qursanız da ümumiyyətlə qoşula bilməz. Xarici ailəni müştəri kütlənizə görə seçin, daxili ünvan planına görə yox.

Müştəriyə hər ailədə ünvan verin

Hər iki ailəni tələb etmək müştəri tərəfində bir sətirlik ifadədir, bir şərtlə ki, şluzun paylaşacaq bir şeyi olsun. Adlandırılmış hovuzlar mənbələri xidmət şəbəkələrindən ayrı saxlayır və məhz bu xüsusiyyət firewall qaydalarını altı ay sonra oxunaqlı edir.

pools {
  pool4 { addrs = 10.90.0.0/24 }
  pool6 { addrs = fd42:90::/64 }
}
connections {
  private-access {
    version = 2
    pools = pool4, pool6
    local  { auth = pubkey  certs = gateway.pem  id = vpn.example.com }
    remote { auth = pubkey  cacerts = ca.pem  vips = 0.0.0.0, :: }
    children {
      private { local_ts = 10.60.0.0/16, fd42:60::/48  remote_ts = dynamic }
    }
  }
}

Bu vips dəyəri hər ailədən bir ünvan istəyir, hovuz siyahısı isə bu ünvanların haradan gəldiyini müəyyən edir.strongSwan virtual IP sənədləri çoxsaylı sorğuları və hovuz təyinatını əhatə edir, o cümlədən müştərinin konkret ünvan istəməsinin cavabdehin ləğv edə biləcəyi bir üstünlük olması məqamını. Müştərinin həmişə eyni dəyəri aldığını fərz edən giriş qaydası qurmayın.

Nümunədəki prefiksi köçürmək əvəzinə öz unikal-lokal prefiksinizi yaradın. Hər ikisi fd42::/16 yerləşdirən iki təşkilat ilk dəfə bir-birinə qoşulanda toqquşmanı aşkar edəcək və bunun diaqnostikası xoş deyil.

Selektorlar mənbələri deyil, təyinatları təsvir edir

Uşaq SA-nın yerli trafik selektorları şluzun arxasında hansı qorunan şəbəkələrin olduğunu bildirir, uzaq selektorlar isə müştərinin mənbə kimi nədən istifadə edə biləcəyini təsvir edir. Virtual hovuz ünvanı həmin siyasətin mənbə tərəfinə aiddir; onu təyinat siyahısına qoymaq konfiqurasiyanın geniş yayılmış səhv oxunuşudur.

Hər iki ailə şluzda geri marşrutlar və icazə verilmiş yönləndirmə tələb edir. Hovuza geri marşrut olmadan selektora prefiks əlavə etmək qurulan, trafiki bir istiqamətdə keçirən və cavabı səssizcə atan bir tunel yaradır. Selektor siyasətdir, marşrutlaşdırma deyil.

Hovuzları və xidmət prefikslərini ünvan planınızın ayrı bloklarında saxlayın. Onlar üst-üstə düşəndə qorunan hosta çatmalı olan marşrut hovuz ünvanına uyğun gələ və tunelin içində yox ola bilər.

DNS və cavab yolu bunun bitmiş görünüb-görünmədiyini müəyyən edir

Resolver cavabları resolverə çatmaq üçün istifadə olunan nəqliyyatdan asılı deyil. Ad A qeydi, AAAA qeydi və ya hər ikisini qaytara bilər və müştəri öz üstünlük qaydalarına uyğun seçim edir . Əgər daxili xidmət AAAA qeydi dərc edir, lakin heç nə o prefiksi marşrutlaşdırmırsa, iki stekli şəbəkələrdəki müştərilər əvvəlcə IPv6 yolunu sınayacaq və uğursuz olana qədər orada qalacaq. Bu baş verərkən tunel konfiqurasiyasında heç nə səhv görünmür.

Yəni hər ad üçün hansı ailələrin istifadə oluna biləcəyini qərarlaşdırın, sonra uyğun prefiksin selektorda olduğunu və geri marşrutu olduğunu yoxlayın. Bu, hər xidmət üzrə ayrıca qərardır. Hər iki qeyd növünün kütləvi dərci işlək yalnız-IPv4 xidmətinin istifadəçilərinin yarısı üçün vaxt aşımına başlamasının yoludur.

Bitmiş adlandırmadan əvvəl hər iki ailəni yoxlayın

Yüklənən konfiqurasiya işləyən konfiqurasiya deyil. Demonun bildirdiyi vəziyyəti oxuyun, hovuz təyinatlarını təsdiqləyin, sonra müştərinin həqiqətən quraşdırdığı marşrutlara baxın.

swanctl --list-sas
swanctl --list-pools
ip -6 addr show scope global
ip -6 route get fd42:60::10

İlk iki əmr qurulmuş uşaq SA-ları və hansı hovuzlarda hələ ünvan olduğunu göstərir, beləliklə ilk müştəri üçün işləyən və onuncu üçün uğursuz olan plan görünür olur. Son iki əmr müştərinin hovuzdan qlobal IPv6 ünvanı alıb-almadığını və qorunan prefiksə trafikin həqiqətən hara gedəcəyini göstərir. Təyin edilmiş ünvanı konfiqurasiya etdiyiniz hovuzla müqayisə edin, ümid etdiyiniz ünvanla yox. Əgər cavabdeh öz siyasəti çərçivəsində fərqli dəyər seçibsə, marşrutlar və firewall qaydaları yenə də onun seçiminə uyğun olmalıdır.

Sonra hər ailə üçün bir qorunan host sınayın və hər ikisinə çevrilən bir ad sınayın. Tək ailə testi planın sınaqdan keçirmədiyiniz yarısı haqqında sizə heç nə demir və itkin marşrut adətən elə o yarıda olur.