strongSwan-də tam tunel hər iki tərəfdə 0.0.0.0/0 tələb edir

Bir şəxsi alt şəbəkə üçün işləyən strongSwan bağlantısı yalnız kimsə bir sətir dəyişdiyi üçün internet trafikini daşımaz. Tam tunel iki tərəfin child SA-nın hansı ünvanları qoruduğu barədə razılaşmasıdır və hər tərəf qarşı tərəfi özünə görə adlandırır. Bir tərəfi düzgün, digərini səhv etdikdə child SA ya qalxmır, ya da nəzərdə tutulandan daha dar qalxır. Aşağıdakı beş yoxlama bu razılaşmanı klientdən şlüzə və oradan internetə qədər izləyir.

Əvvəlcə klient selektorunu yoxlayın

Klient uzaq tərəfdə qorumaq istədiyini remote_ts kimi təsvir edir və göndərdiyi hər şey öz təyin olunmuş ünvanından çıxır. İnternet trafiki üçün bu dəyər istifadəçinin həqiqətən çatacağı təyinatları əhatə etməlidir ki, bu da praktikada bütün IPv4 fəzası deməkdir. Hələ də bir alt şəbəkə sadalayan klient, interfeysdə profil necə adlanırsa adlansın, bölünmüş tunel istəyir. Mənbə tərəfi adətən dynamic olur, çünki ünvan qoşulma anında təyin edilir. Orada yazılmış sabit mənbə hovuz dəyişən kimi pozulur.

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

Fraument tam bağlantı faylı deyil və bu fayl autentifikasiya, kimliklər və virtual ünvan hovuzunun artıq qurulduğunu güman edir. Klientin mənbə selektoru ilə serverin təyin etdiyi ünvan hələ də uyğun olmalıdır, əks halda child SA heç bir tərəfin gözləmədiyi əhatə dairəsi ilə qalxır. Onu swanctl --load-all ilə yükləyin və uğur fərz etməzdən əvvəl çıxışı oxuyun. Parserdən keçən fayl yenə də qarşı tərəfin təklifi ilə üst-üstə düşməyən selektora görə rədd edilə bilər.

Şlüzün öz tərəfindəki selektorunu yoxlayın

Şlüz eyni anlayışı əks istiqamətdən oxuyur. İnternet təyinatları şlüzə lokal olduğu üçün onun local_ts geniş olanıdır və remote_ts klient hovuzunu təsvir edir. Bu tərsinəlik tam tunel konfiqurasiyasında ən çox rastlanan səhvdir və nəzərdən keçirmədən keçir, çünki hər iki sətir tək-tək inandırıcı görünür.

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

Klient fraqmentini şlüz faylına köçürmək faydasız heç nə təsvir etməyən selektor cütü yaradır, çünki hər iki tərəf eyni rolu iddia edərdi. strongSwan yönləndirmə bələdçisi klient-şlüz cütlüyünü açıq şəkildə sənədləşdirir və onu uğursuzluqdan sonra deyil, bağlantı faylının yanında oxumağa dəyər. Şlüz faylına həm də remote_ts-in istinad etdiyi hovuz tərifi lazımdır. Mövcud olmayan hovuzu adlandıran selektor şikayətsiz yüklənir və qoşulma anında uğursuz olur.

Köhnə ipsec.conf fərqli açarlarla sol və sağ rollarından istifadə edir və rightsubnet sətri swanctl dəyərinin birbaşa əvəzi deyil. İki sintaksisi bir-birinin içinə yapışdırmaq əvəzinə ayrı fayllarda saxlayın. Onları bir kataloqda qarışdırmaq işlək bağlantının yenidən başlatmadan sonra səssizcə geri dönməsinin yoludur.

Faylı deyil, razılaşdırılmış child SA-nı yoxlayın

Saxlanmış konfiqurasiya niyyəti sübut edir, başqa heç nəyi yox. Qarşı tərəf tələb olunanı daralda bilər və mövcud child SA yalnız altındakı fayl dəyişdiyi üçün əvəz olunmur. Başqa bir şeyi dəyişməzdən əvvəl həqiqətən quraşdırılmış olanı təsdiqləyin.

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

Birinci əmr daemonun nə yüklədiyini, ikincisi qurulmuş child SA-ları, üçüncüsü nüvənin tətbiq edəcəyi siyasətləri göstərir. Fayl 0.0.0.0/0 deyirsə və siyahı bir alt şəbəkə göstərirsə, danışıqlar əhatəni daraldıb və faylı yenidən oxumaq bunu izah etməyəcək. Child-ı dayandırın, yenidən başladın və hər üç çıxışı yenidən müqayisə edin. Eyni dar əhatə ilə qayıdan child yerli fayl tərəfindən deyil, uzaq tərəf tərəfindən daraldılır və bu, yerli düzəliş deyil, digər administratorla söhbətdir.

Siyasət siyahısında hər iki istiqaməti oxuyun, çünki bir istiqaməti quraşdırıb digərini quraşdırmayan tunel konfiqurasiya libasında bir marşrutlaşdırma problemidir. İrəli və əks siyasətlər eyni selektor cütünü güzgü şəklində adlandırmalıdır və çatışmayan güzgü selektor mətnində deyil, daemon və ya təklifdə qüsurdur.

Yönləndirməni və geri marşrutu yoxlayın

Selektor trafiki şlüzə buraxır; bu, şlüzün həmin trafiki irəli yönləndirməsini təmin etmir. Yönləndirmə aktiv olmalı, firewall axına icazə verməli və cavab klient hovuzuna geri yol tapmalıdır. Bunlar üç ayrı tələbdir və hər biri fərqli simptomla uğursuz olur. Çatışmayan yönləndirmə qaydası qara dəlik kimi davranır, çatışmayan geri marşrut isə birtərəfli tunel kimi.

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

Şəxsi klient ünvanları adətən açıq interfeysdən çıxmazdan əvvəl qəsdən mənbə tərcüməsinə ehtiyac duyur, açıq şəkildə marşrutlaşdırılmış təyinat isə fərqli rəftar tələb edir. NAT işə qarışırsa, tətbiqin dəstəklədiyi istisnaları saxlayın ki, təhlükəsizlik siyasətinin yoxlamalı olduğu trafik ondan yan keçərək tərcümə olunmasın. Başqa şlüzdən köçürülmüş geniş masquerade qaydası müəllifinin nəzərdə tutduğundan qat-qat çox axını dəyişir. Qaydanı yalnız klient hovuzu üçün yazın və niyə mövcud olduğunu izah edən şərh qoyun.

Klientdə fərz etdiyiniz marşrutları deyil, backendin quraşdırdığı marşrutları təsdiqləyin. Marşrut quraşdırması deaktiv olan menecer əl ilə saxlanılan marşrutlaşdırma dizaynına ehtiyac duyur və bu dizayn tunel dəyişdikcə yenilənməlidir. Marşrut cədvəlini yalnız təzə açılışdan sonra deyil, yenidən qoşulmadan sonra da yoxlayın.

Tunelin hələ əhatə etmədiklərini yoxlayın

Selektor cütü IPv4-ü əhatə edir və başqa heç nəyi. IPv6, DNS və hər hansı tətbiq səviyyəli siyasət geniş IPv4 selektorunun səssizcə görməzdən gəldiyi ayrı qərarlardır. Hər IPv4 paketini daşıyan tunel yenə də hər ad axtarışını sızdıra bilər.

Nəzərdə tutulan DNS yolunu açıq şəkildə göstərin, çünki adları hələ də yerli həlledici ilə həll edən tam tunel sorğuları tuneldən kənara sızdırır və şəxsi adları pozur. Klientə IPv6 ünvanı verilirsə, bu ünvan ailəsi də eyni rəftarı tələb edir, əks halda host tunelin qorumadığı yola üstünlük verəcək. Yalnız şəxsi tərəfin cavab verə bildiyi bir adla sınaq keçirin və açıq cavabı sızma kimi qiymətləndirin.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Zənciri bu iki əmrlə və yuxarıdakı siyahıdan razılaşdırılmış selektorlarla təsdiqləyin. Traceroute yerli marşrutlaşdırıcını birinci hop kimi göstərirsə, selektorlar nə iddia edirsə etsin, trafik tuneldən istifadə etmir. İnternet girişi yalnız seçilmiş trafik nəzərdə tutulmuş şlüzdən qəbul edilib yönləndirilib geri qaytarıldıqda tamam olur. Profildə 0.0.0.0/0 tapmaq bu zəncirin sübutu deyil, başlanğıcıdır.