DNS yanıtı durumsuz VPN kenar güvenlik duvarında neden başarısız olur

Tünel ayakta, istemciler VPN ana bilgisayarına ulaşabiliyor ama ana bilgisayar hiçbir şeyi çözemiyor. Kendi giden sorguları arayüzü temiz biçimde terk ediyor, yani arıza dönüş yolunda: ana bilgisayarın az önce gönderdiğini hatırlamadan gelen trafiği süzen bir üst kenarda. Tünel portuna izin vermek bu alışverişi hiç anlatmıyor. DNS sorgusuna verilen yanıt ayrı bir akıştır ve kenar durumsuzsa, ona geri dönme iznini hiçbir şey vermemiştir.

İki alışveriş aynı alışveriş değildir

Demetleri yazın, hata apaçık ortaya çıkar. İsteğin hedef portu yanıtın kaynak portu olur; bu, 53 numaralı port için gelen kural eklerken çoğu kişinin sandığının tam tersidir:

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

Hedef port 53'ü şart koşan bir gelen kural, ana bilgisayarda çalışan bir DNS dinleyicisine yönelen trafiği anlatır ve bu tamamen başka bir hizmettir. O adresler belge örnekleridir ve kaynak portu istemci her sorgu için seçer, dolayısıyla bu, bir kurala kopyalayıp çalışmaya devam edeceğini umabileceğiniz bir değer değildir.

Durumsuz kenar ile durumlu ana bilgisayar güvenlik duvarı

Durumsuz kenar süzgeci her gelen paketi, arkasında hiçbir bağlantı tablosu olmadan kural listesine göre değerlendirir. Başarıyla çıkan bir giden sorgu, gelen yanıtı için hiçbir izin oluşturmaz, çünkü cihazda bir sorgunun hiç olduğuna dair kayıt yoktur. Durumlu ana bilgisayar güvenlik duvarı bunun tersidir: bağlantı izlemesi izin verilen bir alışverişin dönüş trafiğini tanır ve yanıt için kural olmadan geçirir. Tipik bir yolda iki sınır da vardırve ikisi de amaçlanan pakete izin vermek zorundadır.

Karşılaştırma önemlidir çünkü iki cihaz farklı biçimde başarısız olur. Yanıtı reddeden durumlu güvenlik duvarı bir düşürme kaydeder; durumsuz kenar bunu sessizce reddeder, bu yüzden ana bilgisayar sadece zaman aşımına uğrar.

İzni port numarası değil, protokol etrafında kurun

Kuralı gerçek çözümleyici adreslerine, hedef ana bilgisayara ve ürünün desteklediği alma portu politikasına daraltın. DNS'nin TCP yolunu da unutmayın, çünkü büyük bir yanıt ya da kesilme nedeniyle geri çekilme alışverişi TCP'ye taşır ve yalnızca UDP kuralı bunu kapsamaz. Kenar tanımlı bir akış için durumlu denetimi destekliyorsa, elle yazılmış bir yanıt kuralı yerine onu tercih edin, çünkü durumlu yol istemcinin seçtiği portları kendiliğinden izler.

Ardından yoldaki hangi ürünün trafiği gerçekten süzdüğünü doğrulayın. Belgelenmiş IPv4 kenar kapsamı IPv6 politikası kurmaz ve sağlayıcı içi trafik aynı süzgeçten hiç geçmeyebilir.

Herhangi bir kaynak port 53'e izin vermek neden düzeltme değildir

Kaynak port 53 taşıdığını iddia eden her şeyi kabul eden kural, gönderenin başlık alanına yazdığını kabul eden kuraldır. Port numarası göndereni doğrulamaz ve yükün geçerli bir yanıt olduğunu kanıtlamaz, bu yüzden kural çözümlemeyi daha güvenilir kılmadan ana bilgisayarın maruziyetini genişletir. Erişim listesini basitleştirmek için bunları kapatmak yerine kaynak kısıtlamalarını ve istemcinin kendi yanıt denetimlerini, kaynak port rastgeleleştirmesi dahil, koruyun.

Çözümleyici denetlediğiniz bir hizmetse, onu adresleriyle sınırlamak yeterlidir. Genel bir çözümleyiciyse, onayladığınız adreslerle sınırlayın ve bunları kuralın yorumuna yazın.

Doğru sınırda, doğru yönde doğrulayın

Aynı sorgu için ana bilgisayarda ve kenarda yakalayın, paket sayıları yerine demetleri karşılaştırın. İki tarafta da görünen ama ana bilgisayar tarafında yanıtı görünmeyen sorgu gelen süzgece işaret eder; yalnızca ana bilgisayar tarafında görünen sorgu yönlendirmeye ya da çözümleyicinin kendisine işaret eder. Yalnızca UDP izniniz varsa TCP sorgusuyla yineleyin, çünkü ilk testin göremediği boşluk tam olarak budur.

Bunu düzeltmek, ana bilgisayarın gerçekten ihtiyaç duyduğu DNS alışverişini tamamlar. Ana bilgisayarı genel bir çözümleyiciye dönüştürmez, iletilen VPN akışlarına izin vermez ve DNS'in alakasız bir tünel sorununun nedeni olduğunu kanıtlamaz.