OpenWrt ilke yönlendirmesi: yerel DNS'i yakalayan zincir

LAN'daki istemciler tünel üzerinden çözüyor, yönlendiricinin kendi sorguları ise sessizce bunu yapmıyor. Paket güncellemeleri, saat eşitleme ve dinamik DNS hepsi olağan uplink'ten çıkıyor, oysa iletilen her sorgu VPN'i alıyor, ve arayüzde iki farklı yolun var olduğunu ima eden hiçbir şey yok. Açıklama ilkedeki bir hata değil, hangi kancanın paketi gördüğü sorusudur. İki akış, tek çözümleyici adresi ve yalnızca biri yönlendiriciyi geçiyor. Onları ayırmak bütün düzeltmedir.

İki akış, tek çözümleyici adresi

İlk akış insanların hayal ettiği akıştır. Bir istemci yönlendiricinin çözümleyicisine sorar, çözümleyici yukarıya iletir ve bu iletilen paket çıkarken yönlendiriciden geçer. Bu paket, iletilen trafiği izleyen her şey tarafından görülebilir.

İkinci akış hiçbir yerden asla gelmez. Yönlendirici onu oluşturur, dolayısıyla gelen paket ve eşleştirilecek bir iletme adımı yoktur.

İkisi de aynı çözümleyici adresini hedefleyebilir, ve farkın kolayca gözden kaçmasının nedeni tam olarak budur. Aynı hedef, farklı köken, farklı zincir. Kökeni gördüğünüzde tanının geri kalanı gelir.

İletilen ve yerel olarak oluşturulan paketler farklı biçimde girer

İletilen trafik başka bir arayüzden geldiğinde değerlendirilir. İlke yönlendirme paketleri bunu bir prerouting zinciri olarak ortaya koyar ve oraya yerleştirilen bir kural yönlendiriciyi geçen her paketi görür. Bu yüzden istemci sorguları ilkenin tanımladığı gibi davranır ve bu yüzden yönlendirici onu yok sayar. Kural yanlış değil, yalnızca yönlendiricinin asla ulaşmadığı bir kancaya bağlı. Onu taşıyın, aynı eşleşme çalışmaya başlar.

Yerel olarak oluşturulan trafik yönlendiricideki bir süreç tarafından yaratılır ve çıkış yoluna girer. Yönlendiricinin kendi kararıyla yönlendirilir ve ilkeyle yalnızca ilke o zinciri kapsıyorsa karşılaşır. Eşleştirilecek gelen arayüz ve gözlemlenecek iletme kararı yoktur.

Bu, paketlerin nerede doğduğuna dair bir özelliktir, belirli bir paketin değil. Bir zincir için yazılmış kuralın diğeri hakkında hiçbir fikri yoktur. Hiçbir kural ayarı bunu değiştirmez.

Çıkış zincirini seçin, sonra eşleşmeyi daraltın

Düzeltme aynı niyeti çıkış zincirine de bağlamak veya yönlendiricinin kendi sorguları önemliyse kuralı oraya taşımaktır. İlke yönlendirme paketi üzerine kurulu bir OpenWrt kurulumunda bu, kuralın zincir ayarında prerouting yerine output seçmek anlamına gelir. Her iki kitle de kapsama ihtiyaç duyuyorsa iki kuralı da tutun.

Sonra kuralın neyle eşleştiğini daraltın. Çözümleyicinin gerçekten kullandığı bağlantı noktasındaki hedef çözümleyici adresleri, yönlendiricinin oluşturduğu her şeyi tünele göndermekten çok daha küçük bir karardır.

İki zinciri kapsayan tek bir kural yazmaya çalışmak yerine iki kuralı açık tutun. Ayrı kurallar okunması daha kolaydır ve hata ayıklarken istemci trafiğini rahatsız etmeden yönlendiricinin yolunu devre dışı bırakmanızı sağlar. Ayrıca sayaçları tek tek anlamlı kılar.

Tünelin kendi taşımasını kuralın dışında tutun

Tünelin dış bağlantısı da yönlendirici tarafından oluşturulur. Yerel olarak oluşturulan tüm trafiği tünele gönderen bir kural tüneli kendi içinden yönlendirir ve tünel hiç açılmaz.

Yönetim erişimi ikinci kayıptır. Yönlendiriciden kaynaklanan yönetim oturumları veya bunlara verilen yanıtlar, aşırı geniş bir yerel kural tarafından tünele çekilebilir ve LAN'dan erişilemez hale gelebilir.

Tünelin uç noktasını eşleşmenin dışında bırakın ve kuralı çözümleyici adresleriyle sınırlı tutun. Bu DNS gereksinimi için yeterlidir ve üzerinde düşünmek için yeterince küçüktür.

Bir değil iki kitleyi de test edin

Yönlendiricinin kendi sorgusunu yapmasını izleyin ve hangi arayüzün onu taşıdığını not edin. Sorguyu bir LAN ana bilgisayarından tekrarlayın ve hangi yolu izlediğini not edin. İlke kurallarındaki sayaçlar iki yanıtı da tahmin etmeden görünür kılar.

Sonuçları iki ayrı bulgu olarak ele alın. Tünel üzerinden çözen bir istemci yönlendirici hakkında hiçbir şey söylemez ve doğru çözen bir yönlendirici başka bir dinleyicideki istemci hakkında hiçbir şey söylemez. Bunları değişiklik kaydına ayrı satırlar olarak yazın.

Bağlantı noktasını da kontrol edin: hedef bağlantı noktası 53 ile eşleşen bir kural, 853'teki DNS over TLS veya bir HTTPS uç noktası üzerinden ulaşılan bir çözümleyiciyi kaçırır. Yapılandırılmış upstream'in gerçekten kullandığı taşımayla eşleştirin, sızıntı doğru nedenle kapanır.