StrongSwan, Mac'in ulaşamadığı bir DNS adresi gönderiyor

Birisi bir MacBook açana kadar her şey çalışır. Tünel kurulur, iç ana bilgisayarlar adresle yanıt verir ve ad çözümlemesi ölür. iPhone'da aynı profil aynı şekilde davranırken Windows ve Linux istemcileri sorunsuzdur. Gönderilen DNS özniteliği genellikle suçludur: sunucu kendi genel arayüz adresini dağıtır ve Apple'ın IKEv2 istemcisi sorguları tünel üzerinden oraya göndermez. Çözümleyiciyi havuzun içine taşıyın, istemciye dokunmadan belirti kaybolur.

Belirti gönderilen adresi işaret ediyor

Yalnızca bazı platformlar başarısız olduğunda tünel ve kimlik bilgileri neredeyse kesinlikle sorunsuzdur, çünkü bunlar ortaktır. Fark, her istemcinin aldığı yapılandırma yükünü, iç DNS sunucusu dahil, nasıl uyguladığıdır. Adresi kabul edip sorguları tünelin dışına yönlendiren istemci, gördüğü ama kullanamadığı bir çözümleyiciyle kalır.

Genel adres olağan seçimdir çünkü yöneticinin zaten bildiği adres odur. Aynı zamanda tünelin kendi önekinden kesinlikle dışarıda olması garanti edilen tek adrestir ve Apple istemcilerini bozan özellik tam da budur.

Herhangi bir şeyi değiştirmeden önce değere bakın. Gönderilen çözümleyici sunucunun WAN adresiyse sorunun şeklini buldunuz ve kalan tahminleri atlayabilirsiniz. Havuz önekiyle de karşılaştırın, çünkü havuzun içinde ama kiralama aralığının dışında duran bir adres, düzeltmenin tam olarak nasıl görüneceğidir. Yapılandırmayla geçirilen iki dakika, istemcide bir öğleden sonra paket yakalamaktan daha iyidir.

Çözümleyiciyi kiralama aralığından ayırın

Tünele, çözümleyicinin havuzun kendi alt ağının üyesi olduğu bir adres planı verin, sonra o adresi ayırın ki hiçbir istemciye asla kiralanmasın. Bu örnekte havuz 10.180.7.0/24, sunucu 10.180.7.1'i tutuyor ve kiralamalar 10.180.7.2'de başlıyor.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Havuz öneki ile çözümleyici aynı alt ağı paylaşır, bu yüzden tünel trafiğini zaten taşıyan yol sorguları da taşır. Düzeltmeyi istemciler arasında taşınabilir kılan tam olarak bu tek özelliktir. Bir swanctl yapılandırmasında aynı iki gerçek, bağlantıda bir havuz tanımı ve bir DNS ayarı olarak görünür, ipsec.conf sözdiziminde değil.

Sunucunun bunun için yeni bir fiziksel arayüze ihtiyacı yoktur. 10.180.7.1'i loopback arayüzüne eklemek, bir çözümleyicinin bağlanıp yanıt vermesi için yeterlidir, çünkü istemciler ona zaten var olan havuz yolu üzerinden ulaşır. Adresi kiralama aralığının dışında tutun ki hiçbir istemci onu yanlışlıkla alamasın. Havuz harici bir DHCP veya RADIUS hizmeti tarafından yönetiliyorsa adresi orada da ayırın, yoksa ilk soran istemci onu alır.

Çözümleyiciyi bağlayın ve 53 numaralı bağlantı noktasını kapatın

Bir adres atamak, o adreste dinlemekle aynı şey değildir. Yalnızca LAN adresinde dinleyen bir çözümleyici, havuz adresine gönderilen sorguları reddeder veya yok sayar ve istemci yönlendirme arızası gibi görünen bir zaman aşımı görür.

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

O unbound parçası tünel havuzundan gelen sorguları kabul eder ve diğer her şeyi reddeder, ki bu çoğu kurumsal çözümleyicinin istediği politikadır. Aynı örnek LAN istemcilerine de yanıt veriyorsa, dinlemeyi tüm kaynaklara genişletmek yerine LAN önekini açıkça ekleyin.

Güvenlik duvarı kuralları o zaman çözümleyicinin kendi erişim denetimiyle uyuşmalıdır. Havuzdan 53 numaralı bağlantı noktasını kabul edin ve diğer her yerden düşürün, ama önce zincirin sırasını kontrol edin.

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 önceki, daha geniş bir kabul kuralı son iki satırı süs yapar ve çözümleyici internetten erişilebilir kalır. Amaçladığınız sıraya güvenmek yerine etkin kural kümesini sayaçlarla birlikte okuyun. Alternatif politika, yani genel adresi göndermek ve her kaynaktan sorguya izin vermek, birçok istemci için çalışır ama çözümleyiciyi internete koyar ve kendi hız sınırlaması ile izlenmesini gerektirir.

İstemcinin gerçekte ne aldığını doğrulayın

Önce sunucunun görünümüne, sonra istemcininkine bakın, çünkü ikisi öğretici biçimde uyuşmaz. Havuz listesi hangi adresin kiralandığını gösterir, güvenlik ilişkisi listesi ise bağlantının beklenen kimlikle ayakta olup olmadığını gösterir.

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

Doğrudan sorgu, çözümleyicinin havuz adresinde ona ulaşabilen bir ana bilgisayardan yanıt verdiğini kanıtlar. Mac'in o sunucuyu seçtiğini kanıtlamaz. macOS'te scutil --dns çözümleyicileri kapsamlı hizmete göre listeler ve özet panelinden daha bilgilendiricidir; Windows'ta Get-DnsClientServerAddress tünel bağdaştırıcısının gönderilen değeri kabul edip etmediğini gösterir.

İstemci havuz adresini gösteriyor ve sorgular hâlâ zaman aşımına uğruyorsa, sorun tünel yolunda ya da güvenlik duvarı zincirindedir. Çözümleyici bildirmeyen bir istemci, yapılandırma yükünün hiç ulaşmadığı anlamına gelir, bu yüzden ağa değil, o platformun gönderilen ayarları nasıl uyguladığına bakın. Başka bir şeyi değiştirmeden önce bu ikisinden hangisini gözlemlediğinizi yazın. Bu iki arıza bir destek kaydında aynı görünür ve zıt onarımlara götürür.