UFW, tünel açılır açılmaz VPN'in DNS sunucusunu düşürüyor

VPN bağlandığı anda adlar çözülmeyi bırakıyor, oysa genel bir adrese ping hâlâ yanıt veriyor ve güvenlik duvarı durumu yanlış görünen bir şey göstermiyor. Politikada hiçbir şey değişmedi; değişen, yeni bir arayüzün ortaya çıkması ve varsayılan reddin onu ilk paketten itibaren kapsaması. UFW yön ve arayüze göre karar verir, bu yüzden kablosuz bağlantı için yazılmış bir kural tünelden çıkan trafik hakkında hiçbir şey söylemez. Onarım, belirli bir sırayla uygulanan bir avuç dar kuraldır.

Belirti ancak tünel açıldıktan sonra ortaya çıkar

Varsayılan red politikası kendisine söyleneni tam olarak yapar: eşleşen kuralı olmayan her şey, var olan her arayüzde reddedilir. Kurallar yazıldığında tünel yoktu, bu yüzden hiçbiri onu yakalayamaz ve her zaman orada olan ret artık ad çözümüne uygulanır. Gerçek bir adrese doğrudan trafik, daha geniş bir izin onu kapsadığında hâlâ çalışabilir ve bu yüzden genel bir çözümleyiciye ping başarılı olurken ad arama başarısız olur. Boşluk, politikanın hiç görmediği bir arayüz için yazılmış kuraldır.

Bu aynı zamanda arızanın neden temiz biçimde tersine döndüğünü açıklar: tüneli kaldırın ve adlar yeniden çözülür, çünkü sorgu kuralları olan bir arayüze geri döner. Yalnızca tünel açıkken başarısız olan bir politika DNS sorunu değildir ve çözümleyicinin kendisini ayarlamak burada en çok zaman kaybettirir. Çözümleyici yapılandırmasını okumadan önce arayüz listesini okuyun.

Üç yön, üç farklı kural kümesi

Tek bir oturum kurallara birden fazla yönde dokunur ve bir tünel neredeyse hepsine ikinci bir arayüz ekler. Trafiği önce yön ve arayüze göre sıralamak geri kalanı mekanik hale getirir, çünkü aşağıdaki her satır kendi yerinde kendi kuralına ihtiyaç duyar. Örnekler tun0 ve 10.8.0.0/24 havuzunu kullanır, bu yüzden adları ve aralıkları istemcinin kendi çıktısındakilerle değiştirin.

İki satır sık sık karıştırılır çünkü ikisi de tünelden söz eder. Çözümleyici kuralı, istemcinin tünele gönderdiği trafiğe izin verir; SSH kuralı ise sunucunun oradan aldığı trafiğe izin verir; farklı makinelerde yaşarlar ve bağımsız olarak başarısız olurlar. En sık unutulan satır ikincisidir, çünkü istemci, trafiği sunucunun genel adresine izin verilene kadar tüneli hiç kuramaz. Yukarıdan aşağıya çalışın ve her arızanın bir olası nedeni vardır.

İtilen çözümleyicinin kendi kuralı gerekir

Tünelin DNS taşıyıp taşımadığı sunucunun ne gönderdiğine bağlıdır. Çözümleyici seçeneğini iten bir sunucu, istemcinin yapılandırmasına özel bir adres kurar ve o adres yalnızca tünel üzerinden yönlendirilebilir. Sunucu hiçbir şey itmezse istemci zaten sahip olduğu çözümleyiciyi korur ve aşağıdaki kuralların izin vereceği bir şey kalmaz. Herhangi bir şey yazmadan önce itilen durumu ve geçerli sorgu sonucunu kontrol edin:

dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numbered

Durum çıktısı kullanılan çözümleyiciyi ve ona bağlı olduğu bağlantıyı adlandırır; arkasındaki rota araması ise o adrese bir sorguyu hangi arayüzün taşıyacağını gösterir. Çözümleyici başka bir bağlantıda oturuyorsa sorun güvenlik duvarından daha erkendir ve hiçbir kural yardımcı olmaz. İkisi de tünel konusunda anlaşıyorsa iki kural gerekir, çünkü sorguların çoğunu UDP taşır ve yanıt kısaltıldığında TCP devreye girer. Her iki değeri de not edin, çünkü kuralların adlandıracağı değerler onlardır:

sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'

Dış yolu iç yoldan önce açın

İstemci, bir tünel var olmadan önce sunucunun genel adresine ulaşmalıdır, bu yüzden bunun kuralı fiziksel bağlantıda oturur ve önce yerinde olmalıdır. Çözümleyiciye izin verip sunucuyu unutan bir politika, istemciyi tüneli kuramaz durumda bırakır ve bu belirti genellikle bir kill switch'e yüklenir. Sonra gerçekten tünelden istediğiniz hizmetlere izin verin, her seferinde bir dar kural, arayüzü tümüyle açmak yerine. Dar kurallar, reddin yerinde kalabilmesinin nedenidir.

sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'

Test ederken sıra önemlidir, çünkü tünelin açılmasına izin veren ilk kuraldır. Onu ekleyin, bağlanın ve hizmet kuralını eklemeden önce tünelin açık olduğunu doğrulayın, çünkü ikisini birden yapmak bir arızanın hangi yarısının yanlış olduğunu söylememesi demektir. Yukarıdaki belge adresini istemcinin kullanmak üzere yapılandırıldığı uç noktayla değiştirin.

İstemci tarafını bilerek bağlantıyı keserek bitirin. Ret, bilerek dışladığınız trafiği yine de reddetmelidir, çünkü tünel açıkken yanıt veren bir çözümleyici, kuşku duyulduğunda reddeden bir politikanın yalnızca yarısını kapsar.

Bağlanan istemci henüz kabul edilmedi

Sunucunun dikkate alması gereken kendi yönü vardır ve el sıkışmayı tamamlayan istemci, sunucu onu kabul edene kadar sunucuda çalışan hiçbir şeye ulaşamaz. Genel dinleyici kuralı yalnızca tünelin var olmasına izin verir; tünelin trafiğini içeri almaz. Sunucuda bu, iki kural artı hizmetin gerçekten dinlediğine dair bir kontroldür:

sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'

Kuraldaki havuz, sunucunun ayırdığı aralığa eşit olmalı ve tünel numarası sunucunun oluşturduğuyla eşleşmelidir, çünkü başka bir arayüz için kural, kural olmamasından ayırt edilemez. limit yönetici bağlantı noktası için bilinçlidir, çünkü tekrarlanan bağlantıları sınırsız kabul etmek yerine sınırlar. Dinleyici kontrolü kapalı bir bağlantı noktasını düşürülmüş bir paketten ayırır; bunlar istemci tarafından aynı görünür. Numaralı kurallar da tüm resim değildir: UFW'nin before kuralları ve elle yazılmış herhangi bir nftables satırı daha önce eşleşir ve listenin izin verdiği görünen bir paketi yine de reddedebilir.