WireGuard üzerinden tek uygulama: bağlamak yönlendirme değildir
Bir uygulamayı wg0'a bağlamak yalnızca kaynak adresini ayarlar. Çekirdeğin hâlâ tünel yollarını içeren bir tabloya ve o kaynağı oraya gönderen bir kurala ihtiyacı vardır.
Ayar, uygulama başına bir anahtar gibi görünür, bu yüzden insanlar istemciyi WireGuard arayüzüne bağlar ve yalnızca o istemcinin tüneli kullanmasını bekler. Bağlama aslında bir kaynak adresi seçer. Ardından çekirdek hedef için bir yol arar, olağan varsayılan yolu bulur ve paketi tünel adresi ekli olarak fiziksel bağlantıdan dışarı gönderir. Niyeti yalnızca o kaynak adres için seçilmiş bir yol tamamlar.
Mekanizmanın iki yarısı vardır: yalnızca tünelin trafiğinin kullanması gereken bir yönlendirme tablosu ve eşleşen kaynağı oraya gönderen bir kural.
Bağlama bir kaynak adresi ayarlar, fazlası değil
Linux, politika kuralları bu aramayı yönlendirme fırsatını bulduktan sonra, hedefi bir yönlendirme tablosunda arayarak çıkış arayüzünü seçer. Kurallar kaynak adrese, bir güvenlik duvarı işaretine, gelen arayüze, bir UID'ye hatta bir bağlantı noktasına göre seçim yapabilir; her biri tüm trafik yerine bu trafik demenin başka bir yoludur. VPN istemcisinin yapılandırması tünel yollarını tutan tabloyu seçer; kural hangi trafiğin ona başvurabileceğini seçer. Yalnızca bağlama ikisini de sağlamaz.
Bu yüzden arıza bu kadar tuhaf görünür. Uygulama kesinlikle tünel adresini kullanıyor, tünel kesinlikle ayakta ve trafik kesinlikle yanlış arayüzden çıkıyor. Her ifade doğrudur ve birlikte, adresi yola bağlayan hiçbir şeyin olmadığı bir sistemi anlatırlar.
Tünele kendi tablosunu verin
wg-quick yolları profil ne derse oraya kurar. [Interface] altına Table = 40 eklemek onları ana tablo yerine 40 numaralı tabloya taşır. Arayüzü kaldırın ve geldiklerini doğrulayın: ip -4 route ls table 40 tünelin yollarını göstermeli, ip -4 route get 10.66.127.142 ise çekirdeğin şu anda bunlardan birini nasıl çözdüğünü gösterir. Yollar kendi tablolarında olduğunda ana tablo geri kalan her şey için çalışmaya devam eder.
Geniş bir öneki eşleştirmek yerine aynısını IPv6 için yapın. ip -6 rule add from fd00::2/128 lookup 40 tek bir adresi sabitler; fc00::/8 ana bilgisayardaki diğer arayüzlerle çakışabilir ve amaçlanandan fazlasına uyan bir kural üretebilir.
Kaynak kuralını ekleyin ve sayaçları izleyin
Ardından iki yarıyı birleştirin: ip -4 rule add from 10.66.127.142/32 lookup 40, aynı adres WireGuard arayüzüne bağlı haldeyken. İki kuralı PostUp içine koyun ki yeniden bağlanma onları geri getirsin. Bir ayarla değil gerçek bir istekle doğrulayın: ip route get 1.1.1.1 from 10.66.127.142 tünel aygıtını adlandırmalı ve curl --interface wg0 ifconfig.me ev adresi yerine tünelin adresini bildirmelidir.
Hâlâ başarısız olursa ip -s rule çıktısını okuyun. Var olan ama hiç eşleşmemiş bir kural sıfır sayaç gösterir ve bu, yanlış kuralı hiç kural olmamasından ayırır. O tek komut, uygulamanın arayüz ayarını yok sayıp saymadığına dair pek çok tahmini ortadan kaldırır.
Ters durum: SSH'ı tünelin dışında tutun
Karşıt sorun da aynı ölçüde yaygın: wg-quick varsayılan yolun sahibidir ve sunucuya giden SSH oturumu oturum ortasında ölür. Kuralları düşük bir öncelik numarasında durur, bu yüzden bir istisna onlardan önce değerlendirilmelidir. ip rule add dport 22 ipproto tcp table main priority 123 bunu yeni bir iproute2'de yapar; seçicinin bulunmadığı yerde akışı nftables'ta işaretleyin ve bunun yerine işareti eşleştirin.
Dönüş yolunu da denetleyin. Kurulup sonra sessizleşen bir SSH oturumu genellikle asimetrik yönlendirmeye sahiptir: bir yön tünelden, diğeri fiziksel arayüzden çıkar. Sunucu adresi için ip route get yanıtın hangi yöne gideceğini söyler.
Tablo numarasını, kaynak kuralını ve istisnayı profilin kendisine yazın. Üçü de tek bir tasarıma aittir ve birlikte düzenlenecektir.