Wi-Fi'den hücresel ağa geçiş sonrası kill switch: ne kırılır

Bir anda dizüstü bilgisayar ofisin Wi-Fi ağındadır, bir sonraki anda bir telefona bağlıdır ve siz pencereleri değiştirmeyi bitirmeden tünel göstergesi yine yeşildir. Yeşil ışık yalnızca tünelin yeniden bağlandığını bildirir; o boşluk boyunca yönlendirme ve engelleme ilkesinin ne yaptığı başka bir sorudur. Bu ilke, son kurulumda derlenen eşleşme koşulları kümesidir ve geçişin az önce kaldırdığı arayüzü, adresi ve adres ailesini adlandırır. Bu yüzden aynı geçiş, aynı görünen üç sonuç üretir: engelleme sürer, ilke kendi kurtarışını engeller ya da hiçbir şeyin kapsamadığı bir yol açılır.

Ekranda bu üç durumu ayıran bir şey yok, bu yüzden gösterge hangi rengi gösteriyor diye değil, kurallar hangi tanımlayıcılara sabitlenmişti diye sorun. Linux'ta bir kural bir arayüzü veya ondan doldurulmuş bir ipset'i adlandırabilir; Android'de bir VpnService'e setUnderlyingNetworks üzerinden hangi alt ağların izleneceği söylenebilir. Her bağ her an değiştirilecek bir bağlantıya işaret eder ve her biri sonradan yeniden değerlendirilmelidir.

Geçiş aslında neyi yeniden yazar

Eski bağlantı kaybolunca çekirdek onun adreslerini kaldırır, üzerinden geçen yolları geri çeker ve kalanlardan kaynak adres seçimini yeniden kurar. Varsayılan yol yeni ağ geçidine taşınır ve eski kuralların başvurduğu arayüz dizini ya kaybolmuştur ya da başka bir aygıt için geri dönüştürülmüştür. Bağlantı başına çözümleyiciler de tazelenir, ancak yollarla aynı anda değil. Bütün bunlar VPN istemcisinin altında olur, bu yüzden yalnızca kendi tünelinin durumunu izleyen bir istemci bunların hiçbirini görmez.

Sorun, bir kuralın arkasındaki niyet yerine belirli bir tanımlayıcıyı kodlamasıdır. Tünel arayüzünden çıkmayan her şeyi düşüren kural bir arayüz adı kodlar; uç noktaya izin veren kural, yeni ağın başka bir yere yönlendirebileceği bir adres kodlar. Tanımlayıcı kaybolunca kural görünür biçimde yanlış olmaz: ya hiçbir şeyle eşleşmeyi bırakır ya da yanlış şeyle eşleşmeye başlar.

Delik açmadan dış tüneli yeniden kurmak

Dış taşıma eski kaynak adresine bağlıydı, bu yüzden yenisinden yeni bir soket açması gerekir. Uç nokta gerçek bir adres değil de ana makine adı olduğunda, engelleme hâlâ yürürlükteyken bir aramanın başarılı olması gerekir. Bu, sıra tuzağıdır: uç nokta dışında her şeyi düşürecek kadar katı bir ilke, onu bulmak için gereken aramayı da düşürür; meğer ki çözümleme engel kaldırılmadan önce gerçekleşsin ya da hâlâ canlı bir tünelden taşınsın. İki sıranın ikisi de işleyebilir, ama yalnızca istemci hangi sırada olduğunu biliyorsa.

İstemciler burada, tanı koyarken önem taşıyan biçimde farklılaşır. Kimileri önce çözümler sonra kuralları kurar, bu yüzden geçiş görünür bir kesintiye mal olur ve ardından kendiliğinden toparlanır; kimileri engellemeyi ayakta tutar ve aramayı taşımak için hayatta kalan tünele güvenir, bu ise tünel bağlantıyla birlikte öldüğünde tamamen başarısız olur. Bağlantıyı geri getirmek için geniş bir doğrudan varsayılan yol eklemek testi her zaman geçirir ve önlemeye çalıştığınız sızıntıyı her zaman bırakır.

Hâlâ eski ağ geçidini gösteren bir yol, başka bir nedenden aynı tıkanmış kurtarışı verir, bu yüzden istemciyi suçlamadan önce tabloyu okuyun. Aşağıdaki komutlar çekirdeğin gerçekte kullanacağı arayüzü ve kaynak adresi adlandırır; bu da eski yolun hâlâ kurulu olup olmadığını tek satırda çözer.

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

Yeni bağlantı IPv6 getirdiğinde ve kurallar getirmediğinde

Hücresel ve konuk ağlar, ofisin kablolu LAN'ı hiç yapmamış olsa bile sıklıkla küresel bir IPv6 öneki verir. Yalnızca IPv4 kuralı olarak yazılmış bir ilke, çoğu elle yapılmış iptables ve nftables tarifinin varsayılan biçimi, bunun hiçbirini kapsamaz. Tünel bağlı kalır, IPv6 erişimi olan uygulamalar onun dışına çıkar ve gösterge farkı gösteremez çünkü tünel gerçekten ayaktadır. Ayna durumu da aynı ölçüde yaygındır: yalnızca IPv6 için bir kural kümesi, v6 sunmayan bir ağda hiçbir şey yapmaz.

Bağlantının sunduğuyla ilkenin andığını geçişin iki yanında karşılaştırın. Bu komutlar istemcinin çalıştığı aynı olguları yazdırır:

ip -4 route show default
ip -6 route show default
sudo nft list ruleset | grep -c 'ip6 '

İkinci komut varsayılan bir yol yazdırırken üçüncüsü sıfır döndürürse, yeni bağlantı makineyi hiçbir kuralın gözetlemediği bir IPv6 yolundan dışarı çıkarabilir. Değişimden sonra üçünü de yeniden çalıştırın, çünkü ilginç sayı iki çalıştırma arasındaki farktır. İkincisi hiçbir şey yazdırmazsa ters durum geçerlidir ve oradaki v6 ağırlıklı her ilke yalnızca süstür.

Çözümleyici oturum ortasında el değiştirir

Modern sistemlerde çözümleyiciler bağlantılara bağlıdır, bu yüzden yeni bağlantı yeni bir çözümleyici kümesiyle ve belki farklı bir split-DNS görünümüyle gelir. systemd-resolved her bağlantı için bir kapsam tutar ve aralarında yola göre seçim yapar; macOS ise kapsamlı çözümleyicileri dinamik depodan okur ve arayüz sırasına uyar. Kendi çözümleyicisini kuran istemci bağlantınınkiyle yarışır ve kimsenin izlemediği öncelik kuralları kazananı belirler. O zaman ad çözümlemesi bozulabilir, paket süzme ise yazıldığı işi tam olarak yapmaktadır.

Yapılandırılmış çözümleyiciyi değil etkin olanı okuyun. Bir systemd ana makinesinde status alt komutu her kapsamın hangi bağlantıdan geldiğini ve bir private-DNS adının yürürlükte olup olmadığını gösterir:

resolvectl status --no-pager
resolvectl query intranet.example.com

Sorgu tünel yerine fiziksel bağlantıdan çıkıyorsa istemci öncelik yarışını kaybetmiştir ve hiçbir güvenlik duvarı ayarı adlandırmayı düzeltmez. Sorgunun yolunu geçişin iki yanında karşılaştırıp hangisinin kaydığına bakın. Yeni ağın yönlendiremediği özel bir adrese çözülen ad üçüncü durumdur ve hata olarak değil zaman aşımı olarak görünür.

Geçişi çalışın ve kaydı tutun

Değişimi beklemek yerine bilerek yeniden üretin. Tüneli ilk bağlantıda kaldırın, uzun süreli bir aktarım ve yinelenen bir arama başlatın, sonra bağlantıyı değiştirin ve hangisinin hayatta kaldığına bakın. Eski bağlantının kaybolmasıyla tünelin bağlı olduğunu bildirmesi arasındaki aralığı not edin, çünkü ilkenin dayanıp dayanmadığı tam o pencerede belli olur. Sonuç tek yanlı olmasın diye diziyi ters yönde de çalıştırın.

İstisnalar kendi turuna ihtiyaç duyar, çünkü eski ağda haklı görülen bir atlatma yeni ağda otomatik olarak haklı değildir. Ev LAN'ındaki bir yazıcı, bir NAS ya da bir captive portal hücresel ağda karşılığı yoktur ve onlara ulaşan istisna karşılığı olmayan bir kurala dönüşür.

Her yön için arayüz adlarını, sunulan aileleri, yürürlükteki çözümleyiciyi ve kesintinin uzunluğunu yazın. Yeniden bağlanma taşımanın toparlandığını kanıtlar, boşluk boyunca engellemenin dayandığını değil; bunlar bir kayda yazılacak ayrı iddialardır. Bu kayıtla bir sonraki geçiş bellekle değil bilinen bir durumla karşılaştırılır.