FORWARD, OUTPUT ve IPv6’yı kapsayan yönlendirici kill switch’i

Yönlendiriciye giriş yaparsınız, bir forum gönderisinden kill switch kural setini yapıştırırsınız ve tünel düştüğü anda LAN’da gezinme durur. İki gün sonra yönlendirici hâlâ dinamik DNS kaydını olağan WAN üzerinden günceller ve konuk dizüstü bilgisayarı hâlâ IPv6 sitelerine ulaşır. Her iki davranış da normaldir, çünkü yapıştırılan kurallar bir zinciri ve bir adres ailesini kapsıyordu ve bunların hiçbiri yönlendiricinin tamamı değildir. Paket yollarını sırayla gezmek, tam olarak neyin atlandığını gösterir.

Dizüstü bilgisayardan değil, yönlendiriciden başlayın

Yönlendirici düzeyinde bir politika küçük bir ofis için çekicidir, çünkü arkasındaki her cihaz aynı davranışı devralır ve kimse bir istemci anahtarını açmayı unutamaz. Ayrıca her firmware güncellemesinden sonra test etmek için tek bir yer verir. Vermediği şey, yönlendiricinin kendi trafiğinin veya ikinci bir adres ailesinin otomatik kapsanmasıdır ve çoğu başarısız dağıtımın arkasındaki iki boşluk bunlardır.

Herhangi bir şeyi düzenlemeden önce üç gerçeği kâğıda yazın: WAN arayüzünün adı, LAN köprüsünün adı ve VPN uç noktasının adresi ile bağlantı noktası. Üçüne de kurallarda ihtiyacınız olacak ve arayüz adlarını tahmin etmek, doğru görünen bir kural setinin hiçbir şey yapmamasının en yaygın nedenidir.

Bir paketin izleyebileceği üç yolu gezin

Dizüstü bilgisayardan internete giden trafik iletilir, bu yüzden FORWARD zincirinden geçer. Yönlendiricinin kendi ürettiği trafik, örneğin DNS iletimi, NTP sorguları, DDNS güncellemeleri ve VPN kontrol kanalı, OUTPUT üzerinden geçer. Yönlendiriciye yönlendirilen yönetim trafiği INPUT üzerinden gelir.

Bu nedenle yalnızca FORWARD’da kurulan bir kill switch istemcileri korur, başka hiçbir şeyi korumaz. Tablo, açılış sahnesindeki sızıntının neden gizemli değil öngörülebilir olduğunu gösterir.

Çoğu tasarımda INPUT’ta kill switch’e ihtiyacınız yoktur, ancak tünel kapalıyken yönetim erişimini çalışır tutmanız gerekir. Aksi halde VPN ilk kez başarısız olduğunda konsol kablosuyla ofise gidersiniz.

Kuralları tünel hâlâ kalkabilecek şekilde sıralayın

Çalışan bir kill switch, reddetmeyle biten bir izin listesidir ve onu tuğla yerine kill switch yapan sıralamadır. Önce loopback’e, VPN uç noktasına, kurulmuş akışların yanıtlarına ve tünel arayüzüne izin verin; geri kalanını en son reddedin.

iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 51820 -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o wg0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j REJECT

Uç nokta bu noktada bir adres olmalıdır, ana bilgisayar adı değil. Son ret DNS’i engellediğinde, sağlayıcının ana bilgisayar adını belirten bir kural artık çözülemez ve tünel yeniden başlatmadan sonra bir daha asla başlamaz. Sağlayıcı uç noktaları değiştiriyorsa, politika uygulanmadan önce adı çözün ve bu kuralı aynı betikten yenileyin.

İstemci trafiği için biçimi FORWARD’da yansıtın ve reddetmenin üstüne açık bir yönetim kuralı koyun. Bu yönetim kuralını dar ama erişilebilir tutun ve ilk SSH oturumunu kapatmadan önce ikinci bir oturum açarak doğrulayın. Kill switch değişikliği sırasında kendinizi kilitlemek planlanacak kadar yaygındır. WireGuard çalıştıran bir yönlendiricide, eşin allowed-ips değerleri tünele neyin girdiğine karar verirken bu kurallar onun olmadan neyin çıkabileceğine karar verir.

IPv6’nın kendi kapısı olmalı

Yukarıdakilerin tümü IPv4’tür. LAN’ınızda çalışan IPv6 varsa ve tünel yalnızca IPv4 taşıyorsa, kapsanan her cihazın yeni kurallarınızın hiç görmediği doğrudan bir internet yolu vardır. Çift yığınlı bir dizüstü bilgisayar bunu memnuniyetle tercih eder ve kill switch yalnızca IPv4 ile test eden kişiye bozuk görünür.

ip6tables -A FORWARD -i br-lan -j REJECT
ip6tables -A OUTPUT -o eth0 -j REJECT
ip6tables -A OUTPUT -o lo -j ACCEPT

Burada da sıra önemlidir: loopback izni WAN reddinden önce gelmelidir, yoksa yönlendiricideki yerel hizmetler garip şekillerde başarısız olmaya başlar. Ağ IPv6’yı hiç kullanmıyorsa, WAN ve LAN’da devre dışı bırakmak daha basittir ve unutulacak bir şey kalmaz.

Bazı VPN istemcileri yalnızca IPv4 için varsayılan bir yol kurar ve mevcut IPv6 varsayılan yolunu dokunulmadan bırakır. Tünel bağlandıktan sonra yönlendirme tablosunu kontrol edin, istemcinin hallettiğini varsaymayın.

Tünel kapalıyken bunu kanıtlayın

Tüneli yönlendiriciden durdurun ve üç yerden bu sırayla test edin:

# systemctl stop wg-quick@wg0
# ip route get 203.0.113.1
# curl -m 5 -sS http://example.com || echo blocked
# iptables -vnL OUTPUT | head
# ip6tables -vnL OUTPUT | head

Yol araması size bir paketin nereye gideceğini söyler, sayaçlar ise kurallarınızın hiç eşleşip eşleşmediğini söyler. Başarısız bir testten sonra sıfır paketli bir kural hiçbir şeyi korumaz ve olağan neden yazdığınızdan farklı bir arayüz adıdır. Yönlendiricinin ürettiği trafiği açıkça test edin, çünkü LAN tarafından yapılan bir test OUTPUT’u çalıştıramaz.

Arıza moduna ihtiyaç duymadan önce karar verin. Fail-closed, tünel geri gelene kadar istemcileri çevrimdışı tutar; fail-open olağan WAN erişimini geri getirir ve önemsediğiniz trafik için amacı boşa çıkarır. Yüksek metrikli, VPN havuzuna giden bir blackhole yol, fail-closed tasarımlar için yararlı bir ikinci katmandır, çünkü tünel yolu kaybolduğunda varsayılana geri dönmek yerine ayakta kalır.

Kurulumu yalnızca LAN istemcisi, yönlendiricinin ürettiği istek ve IPv6 isteği tünel kapalıyken başarısız olduğunda ve tünel açıldığında üçü de yeniden çalıştığında kabul edin.