Yönlendiricide VPN kuralları: kaynağı ve hedefi eşleştirin

Yönlendirici alışveriş sayfaları VPN yönlendirmesini tek bir onay kutusu olarak gösterir ve bu ifade üç farklı soruyu gizler. Kural, trafiği gönderen cihazla mı, onu alan sunucuyla mı, yoksa ikisiyle de mi eşleşir? Hiçbiriyle eşleşmeyen trafiğe ne olur? Ve iki kural çakıştığında hangisi kazanır? Yanıtı kaynak ve hedef çifti olarak yazmak, belirsiz bir özellik listesini test edilebilir bir tasarıma dönüştürür.

Özellik adı iki ucu gizler

Tüneli kullanması gereken medya oynatıcı bir kaynak eşleşmesidir. Tünel üzerinden erişilebilir olması gereken özel ofis öneki bir hedef eşleşmesidir. Tüneli yalnızca tek bir hizmet için kullanması gereken iş istasyonu ikisidir ve bu kesişim çoğu tüketici ürün yazılımının kötü ele aldığı durum.

Ürünleri karşılaştırmadan önce gereksinimi bir çift olarak yazın. Daha sonra test edeceğiniz şey bu çifttir.

Cihaz listesi veya genel hedef listesi sunan bir ürün «yalnızca bu cihaz, yalnızca bu hedefler» ifadesini veremeyebilir. Bu fark kozmetik değildir: genel hedef kuralı her cihazın o siteye giden trafiğini tünelden geçirir, cihaz kuralı ise o cihazın tüm trafiğini gönderir. İkisi de gereksinim değildir. Ekrana güvenmeden önce bu durumu iki cihazla test edin.

Kuralı kesişim olarak kurun

Bir tablo tasarımı dürüst tutar. Senaryoyu sola koyun, ardından gönderen eşleşmesini ve hedef eşleşmesini ayrı ayrı adlandırın:

Üçüncü satır ilginç olandır, çünkü iki yarıya aynı anda ihtiyaç duyar. Ürün yazılımı yalnızca tek bir ekseni ifade edebiliyorsa gereksinim iki kurala bölünmeli veya bunu yapabilen bir cihaza taşınmalıdır.

Kaynak kimliğini sabit tutun. DHCP rezervasyonu, özel bir segment veya cihaz kimliği mekanizması işe yarar, ancak kiralama süresi dolduktan sonra değişen adres işe yaramaz. IPv6'yı dahil edin, çünkü tek bir IPv4 adresi bir cihazın tüm trafiğini tanımlamaz.

Çakışmayı öncelik belirler

Kuralların çakışması normaldir. Geniş bir cihaz kuralı ve dar bir hedef kuralı aynı akışı tanımlayabilir ve belgelenmiş öncelik sırası hangisinin kazanacağını belirler. Çekici bir ayarlar ekranı bu sırayı size söylemez.

Sıra ve eşleşmeyen durum için kılavuzu okuyun, sonra ikisini de gözlemleyebileceğiniz trafikle test edin:

ip rule show
ip route get 203.0.113.10

Belgeler sırayı belirtmiyorsa daha dar kuralın kazanmayabileceğini varsayın ve buna göre tasarlayın. Çakışamayan iki kuralı desteklemek, önceliği belgelenmemiş tek bir akıllı kuraldan daha kolaydır.

Adların yenileme ilkesine ihtiyacı vardır

Alan adı olarak yazılan bir hedef bakım sorunu ekler. Yönlendirici bunu çözmeli, eşlemeyi yenilemeli, birden çok adresi ve alt alan adını yönetmeli ve beklenen çözümleyiciyi atlayan uygulama DNS'iyle başa çıkmalıdır.

Bir arama sonucunu IP kuralına kopyalamak anlık görüntüdür, alan adı ilkesi değildir.

Kural yanlış olmadan önce bir yanıtın ne kadar eskiyebileceğine ve çözümleme başarısız olduğunda yönlendiricinin ne yapacağına karar verin. Son bilinen adresi tutan bir kural bir hizmet geçişini atlatabilir; girdiyi atan bir kural tünellemeyi sessizce durdurabilir. İki davranış da kuralın yanına yazıldıysa kabul edilebilir.

Kullanılamaz durumu tanımlayın

Bir yol tercihi yalnızca VPN trafiğini zorunlu kılmaz. Tünel kapalıyken yönlendirici akışı engelleyebilir, doğrudan gönderebilir veya başka bir tünel kullanabilir ve her seçeneğin farklı bir arıza imzası vardır.

Gereksinimin hangisine ihtiyacı olduğuna karar verin, sonra tüneli durdurup akışı izleyerek doğrulayın:

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://service.example/
ping -c 2 203.0.113.10

Yönlendiricinin kendisinden çıkan trafik ayrı bir kapsamdır. DNS yönlendirme, güncelleme kontrolleri ve izleme, cihazın kaynak eşleşmesini devralmak yerine yönlendiricinin kendisinden yeni akışlar başlatabilir. Bu akışları açıkça hesaba katın, yoksa günlüklerde açıklanamayan sızıntılar olarak görünürler.