Yönlendiricide sızıntısız bir VPN yedekleme politikası nasıl kurulur
Tercih edilen tünel düştüğünde trafiğin ne yapacağına karar verin: yedek tünel, düz WAN veya engelleme. Sonra bunu yönlendiricide kurup test edin.
Yedekleme tam olarak yapılandırıldığı gibi çalıştı ve sorun da buydu. Birincil tünel düştüğünde yönlendirici varsayılan rotayı kablo modemine taşıdı, dizüstü bilgisayarlar gezinmeye devam etti ve kimse aramadı. İki gün sonra biri finans paylaşımının altı saat boyunca açık internet yolundan erişilebilir olduğunu fark etti. Yönlendiricide VPN yedekleme politikası bir yönlendirme hilesi değildir; tercih edilen yol kaybolduğunda trafiğin ne yapacağına dair bir karardır ve bu karar yol kaybolmadan önce var olmalıdır.
Detektörü seçmeden önce sonucu belirleyin
Genellikle masada üç sonuç vardır: etkilenen istemcileri yedek tünelden göndermek, normal WAN kullanmalarına izin vermek veya tamamen engellemek. Hangisinin hangi VLAN, SSID veya cihaz sınıfına uygulandığını yazın. Tek bir düz «WAN'a geç» kuralı, yukarıdaki finans paylaşımının herkese açık bir yola düşmesine neden oldu.
Bu üçü birbirinin yerine geçmez. WAN'a dönüş, destek masasının telefonlara bakmasını sağlar ama iç adları yerel çözümleyiciye açık eder. Yedek tünel politikayı korur ama karşı tarafın kabul etmediği bir çıkış adresine inebilir. Engelleme, bordro VLAN'ı için doğru, tüneli hiç kullanmamış bir misafir ağı için yanlıştır.
| Outcome | Right for | What breaks |
|---|---|---|
| Backup tunnel | Policy must hold, remote access required | New exit address, return route, slower rekey |
| Plain WAN | Guest or public-only traffic | Internal names, DNS and IPv6 exposure |
| Block | Payroll, admin, anything VPN-only | Users lose all access and call you |
Detektörü gerçekten korktuğunuz arızayla eşleştirin
El sıkışma durumu, arayüz durumu ve kullanılabilir yönlendirme üç farklı sinyaldir ve kullanıcı için yalnızca sonuncusu önemlidir. Sağlayıcının üst ağı paketleri düşürürken bir WireGuard eşi yeni bir el sıkışma gösterebilir. OpenVPN istemcisi, ilettiği rota çözümlenmeyi bıraktıktan sonra «bağlı» durumunda kalabilir.
pfSense'te pratik düzenleme, dpinger tarafından beslenen bir ağ geçidi grubudur; dpinger bir izleme adresini yoklar ve kayıp veya gecikme eşiklerini aştığında ağ geçidini devre dışı olarak işaretler. Bu izlemeyi tünelin ötesinde bir şeye yöneltin, örneğin uzak LAN'daki bir ana bilgisayar veya tünel üzerinden ulaştığınız genel bir adres. Tünelin kendi eş adresine yöneltmek, zaten canlı olduğunu bildiğiniz kısmı ölçer.
Grubu, yedek son çare olacak şekilde kurun
Tek düz bir üye listesi yerine katmanlar kullanın. Birincil katman 1'de, yedek tünel katman 2'de, WAN katman 3'te yalnızca politikası buna izin veren VLAN'lar için. pfSense'te bu System > Routing > Gateway Groups altındadır: iki ağ geçidini de ekleyin, onlara farklı katmanlar verin, Trigger Level'ı üye devre dışı artı paket kaybı olarak ayarlayın, kaydedin ve ardından grubu arayüzün varsayılanı olarak veya ihtiyaç duyan güvenlik duvarı kurallarının Gateway alanında uygulayın.
pfSense 2.5 ve sonrasında bir OpenVPN istemci örneği için örneğin Default Gateway ayarı, tünelin sistem varsayılan rotasını değiştirip değiştirmeyeceğine karar verir. Kurala göre yönlendirme, ancak varsaydığınız rota gerçekten kuruluysa beklediğiniz gibi davranır. Değişiklikten sonra tünel durumu simgesine güvenmek yerine Status > Gateways kontrol edin.
Çoğu dalgalanmaya iki ayar neden olur. Biri sağlayıcının kendi yeniden yakınsamasından kısa bir yoklama aralığıdır. Diğeri, birincil ve yedeğin aynı katmanı paylaştığı gruptur; böylece ikisi de her zaman uygun kalır. Kullanıcılar geçişleri sizin yerinize hissetmeden önce kayıp ve gecikme eşikleriyle histerezis ekleyin.
Tünelin hiç sahip olmadığı yolları kapatın
Önce DNS sızıntıları. Çözümleyici WAN üzerinde yanıt vermeye ve oradan iletmeye devam eder, bu yüzden trafik tünele sabitlenmişken adlar hâlâ ISS üzerinden çözümlenir. Çözümleyicinin giden arayüzlerini kısıtlayın, iç çözümleyiciyi istemcilere itin ve yalnızca VPN olan VLAN'larda geri kalan her şey için 53 numaralı bağlantı noktasını engelleyin.
IPv6 kendi kararını gerektirir. Çift yığınlı bir LAN tüneli kaybedip çalışan bir genel IPv6 varsayılan rotasını koruyabilir, bu yüzden tarayıcılar IPv6'yı tercih eder ve WAN üzerinden çıkar, IPv4 ise tamamen kapalı görünür. Ya IPv6'yı tünele yönlendirin ya da tünel kapalıyken genel bir öneki duyurmayı bırakın. Yarım politika hiç yoktan kötüdür, çünkü çalışıyor gibi görünür.
Sonra dönüş yolu. Yedek çıkış farklı bir kaynak adresi kullanıyorsa, karşı taraf trafiği ona nasıl geri göndereceğini bilmelidir ve eski adrese bağlı her durum zaten ölmüştür. Birincil düştüğünde açılan oturumlar taşınmaz; zaman aşımına uğrayana ve uygulama ne yapacağına karar verene kadar takılırlar.
Düşüşü, dalgalanmayı ve geri dönüş yolunu test edin
Zararsız trafik akarken birincili çekin, sonra dört şeyi okuyun: grubun üye durumları için Status > Gateways, hâlâ eski ağ geçidine sabitlenmiş durumlar için pfctl -ss, çıkış yolu için bir istemciden traceroute ve hangi sunucunun yanıt verdiğini görmek için bir çözümleyici sorgusu.
Şimdi dalgalandırın. Birincili otuz saniye yukarı, otuz saniye aşağı, iki kez alın. Trafik her geçişi kovalıyorsa eşikler çok sıkı veya katmanlar yanlış. Bunu kendi programınızda düzeltin, yoksa bir sağlayıcı bunu kendi programında yapar.
Son olarak, yönlendiriciyi hâlâ yönetebildiğinizi doğrulayın. Konsol kablosu, yönetim VLAN'ı veya hücresel modem gibi bant dışı bir yol tutun. Sizi dışarıda kilitleyen bir yedekleme testi tamamlayamayacağınız bir testtir ve erişilemeyen bir yönlendirici kendi kendine geri dönemez.
Politikayı bitmiş ilan etmeden önce, terminal açmadan dört soruyu yanıtlayabilmelisiniz: tünel kapalıyken hangi VLAN'lar WAN kullanabilir, detektör neyi izler ve ne kadar bekler, hangi ad sunucuları ve IPv6 rotaları yolla birlikte hareket eder ve yedek de başarısız olursa nasıl geri girersiniz. Herhangi bir yanıt «varsayılan neyse o» ise politika hâlâ yönlendiriciye aittir, size değil.