StrongSwan Mac-ın çata bilmədiyi DNS ünvanını ötürür

Hər şey kimsə MacBook açana qədər işləyir. Tünel qurulur, daxili hostlar ünvanla cavab verir, ad həlli isə ölür. iPhone-da eyni profil eyni cür davranır, Windows və Linux müştəriləri isə yaxşıdır. Adətən günahkar ötürülən DNS atributudur: server öz publik interfeys ünvanını paylayır və Apple-ın IKEv2 müştərisi sorğuları tünelin içindən ora göndərmir. Resolveri hovuzun içinə köçürün və simptom müştəriyə toxunmadan yox olur.

Simptom ötürülən ünvana işarə edir

Yalnız bəzi platformalar uğursuz olursa, tünel və etimad məlumatları demək olar ki, qaydasındadır, çünki onlar ortaqdır. Fərq hər müştərinin aldığı konfiqurasiya yükünü, o cümlədən daxili DNS serverini necə tətbiq etməsidir. Ünvanı qəbul edən, lakin sorğuları tünelin ətrafından yönləndirən müştəri görə bildiyi, amma istifadə edə bilmədiyi bir resolverlə qalır.

Publik ünvan adətən seçilir, çünki administratorun artıq bildiyi ünvandır. O, həm də tünelin öz prefiksindən kənarda olduğuna zəmanət verilən yeganə ünvandır və Apple müştərilərini məhz bu xüsusiyyət pozur.

Nəyisə dəyişməzdən əvvəl dəyərə baxın. Ötürülən resolver serverin WAN ünvanıdırsa, problemin formasını tapmısınız və qalan təxminləri atlaya bilərsiniz. Onu hovuz prefiksi ilə də müqayisə edin, çünki hovuzun içində, amma icarə diapazonundan kənarda olan ünvan düzəlişin görünəcəyi yerdir. Konfiqurasiya ilə iki dəqiqə müştəridə bütün bir günorta paket tutmağa dəyər.

Resolveri icarə diapazonundan ayırın

Tünelə elə ünvan planı verin ki, resolver hovuzun öz subnetinin üzvü olsun, sonra həmin ünvanı rezerv edin ki, heç bir müştəriyə icarəyə verilməsin. Bu nümunədə hovuz 10.180.7.0/24, server 10.180.7.1 saxlayır və icarələr 10.180.7.2-dən başlayır.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Hovuz prefiksi ilə resolver eyni subneti paylaşır, ona görə də artıq tünel trafikini daşıyan marşrut sorğuları da daşıyır. Düzəlişi müştərilər arasında portativ edən tək xüsusiyyət budur. swanctl konfiqurasiyasında eyni iki fakt ipsec.conf sintaksisində deyil, hovuz tərifi və bağlantıda DNS tənzimi kimi görünür.

Serverin bunun üçün yeni fiziki interfeysə ehtiyacı yoxdur. 10.180.7.1-i loopback interfeysinə əlavə etmək resolverin bağlanıb cavab verməsi üçün kifayətdir, çünki müştərilər ona artıq mövcud olan hovuz marşrutu ilə çatır. Ünvanı icarə diapazonundan kənarda saxlayın ki, heç bir müştəri onu təsadüfən tutmasın. Hovuz xarici DHCP və ya RADIUS xidməti ilə idarə olunursa, ünvanı orada da rezerv edin, əks halda ilk soruşan müştəri onu alacaq.

Resolveri bağlayın və 53 portunu bağlayın

Ünvan təyin etmək onu dinləməklə eyni şey deyil. Yalnız LAN ünvanında dinləyən resolver hovuz ünvanına göndərilən sorğuları rədd edəcək və ya nəzərə almayacaq, müştəri isə marşrut xətasına bənzəyən taym-aut görür.

interface: 10.180.7.1
access-control: 10.180.7.0/24 allow
access-control: 0.0.0.0/0 refuse

Bu unbound fraqmenti tünel hovuzundan gələn sorğuları qəbul edir və qalan hər şeyi rədd edir, əksər korporativ resolverlərin istədiyi siyasət budur. Eyni instans LAN müştərilərinə də cavab verirsə, dinləyicini bütün mənbələrə genişləndirmək əvəzinə LAN prefiksini açıq şəkildə əlavə edin.

Sonra firewall qaydaları resolverin öz giriş nəzarəti ilə uyğun olmalıdır. Hovuzdan 53 portunu qəbul edin və hər yerdən başqa onu atın, amma əvvəlcə zəncirin sırasını yoxlayın.

iptables -A INPUT -p udp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROP

Daha əvvəlki, daha geniş qəbul qaydası son iki sətri bəzək edir və resolver internetdən əlçatan qalır. Nəzərdə tutduğunuz sıraya güvənmək əvəzinə effektiv qayda dəstini sayğaclarla oxuyun. Alternativ siyasət, yəni publik ünvanı ötürmək və hər mənbədən sorğulara icazə vermək, bir çox müştəri üçün işləyir, lakin resolveri internetə çıxarır və öz sürət limiti ilə monitorinqini tələb edir.

Müştərinin həqiqətən nə aldığını yoxlayın

Əvvəlcə serverin görünüşünü, sonra müştərinin görünüşünü yoxlayın, çünki ikisi məlumatlı şəkildə ziddiyyət təşkil edir. Hovuz siyahısı hansı ünvanın icarəyə verildiyini göstərir, təhlükəsizlik assosiasiyalarının siyahısı isə bağlantının gözlənilən kimliklə qurulub-qurulmadığını göstərir.

swanctl --list-sas
swanctl --list-pools
dig +short @10.180.7.1 intranet.plant.example

Birbaşa sorğu resolverin hovuz ünvanında onu çata bilən hostdan cavab verdiyini sübut edir. Mac-ın o serveri seçdiyini sübut etmir. macOS-da scutil --dns hər əhatəli xidmət üzrə resolverləri sadalayır və xülasə panelindən daha məlumatlıdır; Windows-da Get-DnsClientServerAddress tünel adapterinin ötürülən dəyəri qəbul edib-etmədiyini göstərir.

Müştəri hovuz ünvanını göstərir və sorğular hələ də taym-aut verirsə, günah tünel marşrutunda və ya firewall zəncirindədir. Heç bir resolver bildirməyən müştəri konfiqurasiya yükünün heç vaxt çatmadığını bildirir, ona görə də şəbəkəyə deyil, həmin platformanın ötürülən tənzimləmələri necə tətbiq etdiyinə baxın. Başqa nəyisə dəyişməzdən əvvəl bu iki haldan hansını müşahidə etdiyinizi yazın. Bu iki nasazlıq dəstək biletində eyni görünür və əks təmir yollarına aparır.