80 ve 443 numaralı bağlantı noktası kuralları tarayıcıyı VPN'den geçirmez

Biri tarayıcının tüneli kullanmasını ister ve yanıt, hedef bağlantı noktaları 80 ve 443 ile eşleşen bir güvenlik duvarı kuralı olarak döner. Kesin görünür ve kesin değildir. Bağlantı noktası eşleşmesi paketleri taşıma başlıklarına göre seçer, soketi hangi programın açtığına göre değil ve modern gezinme TCP üzerindeki bu iki bağlantı noktasıyla sınırlı değildir. Kural, dahil etmek istediğiniz trafiğin bir kısmını kaçırır ve hiç dokunmayı düşünmediğiniz trafiği yakalar. Yazmadan önce, üç farklı sınırdan hangisini gerçekten istediğinize karar verin.

Kural bir taşıma sınıfını tanımlar, bir uygulamayı değil

Linux'ta hedef bağlantı noktası eşleşmesi TCP başlığını inceler ve üstünde hiçbir şeye bakmaz. Bu paketleri işaretlemek ve bir politika rotasıyla yönlendirmek tam olarak belgelendiği gibi çalışır ve bu mekanizmaların hiçbiri yükün ne anlama geldiğini ya da hangi sürecin gönderdiğini bilmez. İşaret, pakete iliştirilmiş bir sayıdır, uygulamaya iliştirilmiş bir kimlik değil.

nft add rule inet mangle output tcp dport { 80, 443 } meta mark set 0x1
ip rule add fwmark 0x1 table 100
ip route add default dev wg0 table 100

Hemen iki sonuç gelir. TCP 443'e bağlanan bir yazılım güncelleyicisi tarayıcıyla aynı muameleyi görür; bu iyi olabilir ya da bir sonraki güncelleme döngüsünü bekleyen bir kesinti olabilir. Ve bilerek başka bir bağlantı noktasında, diyelim 8443'te yayımlanan bir web hizmeti, kullanıcının önemsediği web trafiği olmasına rağmen kuralın tamamen dışında kalır.

Gereksinim gerçekten o bağlantı noktalarıyla ilgili olduğunda sayılar meşru seçicilerdir. Kayıtta «tarayıcı» yazıp kural kümesinde bir bağlantı noktası aralığı uygulandığında kurgu olurlar. Bu boşluk bir belge ayrıntısı değildir. Bir incelemede savunabileceğiniz bir kural ile kimsenin test edemeyeceği bir kural arasındaki farktır.

HTTP/3 TCP kuralınızı sessizce terk eder

HTTP/3, QUIC üzerinde çalışır ve QUIC UDP içinde taşınır. Yalnızca TCP ile eşleşen bir kural bunu göremez, bu yüzden test sayfanızı geçen aynı tarayıcı sonraki isteği UDP üzerinden gönderip tüneli atlayabilir; kimse bir ayarı değiştirmez. RFC 9114, HTTP/3'ü QUIC tabanlı bir protokol olarak tanımlar ve QUIC, yaygın kurulumda varsayılan bağlantı noktası 443 olan UDP kullanır.

Belirli bir tarayıcının HTTP/3 deneyip denemeyeceği yapılandırmasına, siteye ve önceki denemenin başarılı olup olmadığına bağlıdır. Bu da onu bellekte akıl yürütmek için kötü bir şey yapar. Bunun yerine araca sorun:

curl --http3 -sS -o /dev/null -w '%{http_version} %{time_total}\n' https://example.com
ss -tunp | grep -E ':443\b'

curl satırı anlaşılan sürümü yazdırır, yani 3 UDP yolunun kullanıldığını doğrular. Ardından soket listesi bu bağlantının tünel arayüzüne mi yoksa fiziksel olana mı bağlı olduğunu gösterir. curl derlemenizde HTTP/3 yoksa bayrak sessizce geri çekilmek yerine yüksek sesle başarısız olur; bu da kendi küçük merhametidir.

DNS, vermeniz gereken ayrı bir karar

Web trafiği için bir bağlantı noktası kuralı ad çözümlemesi hakkında hiçbir şey söylemez. Tarayıcı sistem çözümleyicisini, tarayıcı içinde yapılandırılmış bir çözümleyiciyi veya son bağlantının ittiği birini kullanabilir. Bunların her biri sorguları kuralınızın seçtiğinden farklı bir yoldan gönderebilir; bu da klasik ayrışmayı üretir: sayfa yüklenir, ad beklemediğiniz bir yerde çözülür ve iç site ya genel bir adrese çözülür ya da hiç çözülmez.

Buna açıkça karar verin. İç adların tünel üzerinden çözülmesi gerekiyorsa çözümleyici onun içinde olmalı ve kural kümesi o çözümleyiciye DNS izni verirken diğer sorguları dışarıda tutmalıdır. Tarayıcı genel bir sağlayıcıya DNS over HTTPS kullanıyorsa sorgu çözümleyicinizi tamamen atlar ve bağlantı noktası kuralı yardımcı olamaz. Seçimi yönlendirme kuralıyla aynı değişiklik kaydına yazın, çünkü ikisini birlikte okuyacak olan bir sonraki arızayı ayıklayan kişidir.

Ardından sayfayla değil çözümleyiciyle doğrulayın:

resolvectl query intranet.example.internal
resolvectl status | grep -A3 'Current DNS Server'

Yanıtın gelmemesi, tarayıcının hata iletisi ağı suçlasa bile bir çözümleme sorunudur. Bu iki arıza kullanıcıya aynı görünür ve tamamen farklı kayıtlardır.

Üç sınır, üç farklı mekanizma

İstediğiniz sınırı adlandırdığınız anda karışıklığın çoğu kaybolur. Birbirlerinin yerine geçmezler ve her birinin tünel kesintisinde farklı bir arıza biçimi vardır.

Ayrı bir tarayıcı profili orta satırdaki tuzaktır. Çerezleri ve geçmişi ayırır ve ana makinenin yönlendirme tablosunda hiçbir şeyi değiştirmez, bu yüzden iki profil de aynı yolu izler. Yalıtım, çekirdeğin dayattığı bir şeyi gerektirir; yani isim alanı, konteyner veya kendi tünel arayüzüne sahip bir uygulama.

Hangi satır geçerli olursa olsun, tünel düştüğünde ne olması gerektiğini yazın. Arayüzle birlikte kaybolan işaret tabanlı bir rota genellikle fiziksel varsayılan rotaya geri düşer; bu fail-open davranışıdır. Bu, gezinme için kabul edilebilir ve başka her şey için kabul edilemez olabilir ve bu bir karardır, uygulama ayrıntısı değil.

Kapsadığınızı iddia ettiğiniz akışları test edin

Kabul testi, kolay olan bağlantı noktası numaralarını değil, yazdığınız sınırı izlemelidir. Tünelden geçmesi gereken bir akış, geçmemesi gereken bir başkası ve düşünmediğiniz bir taşımayı kullanan bir diğeri seçin:

ip route get 203.0.113.40
curl -sS -o /dev/null -w 'v4 %{http_version} %{remote_ip}\n' https://example.com
nft list ruleset | grep -A2 'dport'

Rota sorgusu bir hedefin gerçekte hangi arayüzü kullandığını söyler ve çoğu raporun yanlış belirttiği gerçek budur. curl satırı anlaşılan sürümü ve adres ailesini doğrular. Kural kümesi dökümü, test sırasında ekleyip kapsamını belirlemeyi unuttuğunuz kuralı yakalar ve böylece geçici bir işaret kalıcı fail-open yönlendirmeye dönüşür.

Üç çıktının hepsini zaman damgasıyla kaydedin ve değişiklikle birlikte saklayın. Sonradan biri «VPN intraneti bozdu» diye bildirdiğinde, amaçlanan ve uygulanan sınır arasındaki fark o kayıtta görünecek ve düzeltme bir tartışma değil kural değişikliği olacaktır.