Uç nokta adresi değiştiğinde VPN için UFW istisnası

İstemci yeniden bağlanmayı deniyor ve makineden hiçbir şey çıkmıyor, oysa aynı profil geçen hafta çalışıyordu. Uç nokta ana bilgisayar adı artık farklı bir adrese çözümleniyor ve giden istisna hâlâ eskisini adlandırıyor. Bu tek eskimiş izin, çalışan bir kill switch'i tam bir kesintisine dönüştürmeye yeter ve masaüstünün gösterdiği hiçbir durum göstergesinde görünmez. Onarım, tek satırlık bir düzenleme değil küçük bir iş akışıdır.

Tünel yeniden bağlanıyor, sonra hiçbir şey çıkmıyor

Hedef adresi adlandıran bir giden kural bir anlık görüntüdür ve DNS yanıtları öyle değildir. Sağlayıcı bir adresi döndürdüğünde, istemcinin yeni peer'a gönderdiği paket hiçbir şeyle eşleşmez ve varsayılan ret tarafından düşürülür. İstemci ardından zaman aşımı bildirir; bu da güvenlik duvarı değil sunucu sorunu gibi görünür.

Herkese açık bir sorgunun döndürdüğü adresi sabitlemek bugünü çalıştırır ve yarını bozuk bırakır. Bu tek seferlik bir düzenlemedir, bakım politikası değil.

Gerçekten kastettiğiniz istisnayı tanımlayın

Kuralın ihtiyaç duyduğu dört değeri yazarak başlayın: onaylanmış uç nokta adı veya adres kümesi, taşıma, hedef bağlantı noktası ve paketin çıktığı arayüz. Dördü de iznin parçasıdır ve bunlardan herhangi biri yanlış olabilirken kural hâlâ makul görünebilir. Üçünde doğru olan bir kural, dördünde de yanlış olan bir kuralla tam olarak aynı şekilde başarısız olur. Komutu yazmadan önce bunları yazın, çünkü bir kural ancak arkasındaki tanım kadar iyidir.

Aşağıdaki komut kablolu bir uplink üzerinde tek bir IPv4 UDP uç noktası için biçimi gösterir. İki değeri dağıtıma karşı doğruladıklarınızla değiştirin.

sudo ufw allow out on enp3s0 proto udp to 192.0.2.44 port 1194
sudo ufw status verbose

Bu izin aynı bağlantı noktasında keyfi hedeflere yetki vermez, bir dinleyici oluşturmaz ve TCP'yi kapsamaz. UFW kılavuz sayfası adres, arayüz ve protokolün bir kuralı nasıl daralttığını açıklar ve bütün mesele bu daraltmadır.

Tek bir iş akışı olarak yenileyin

İstisnayı sahibi ve geçişi olan bir kaynak olarak ele alın, birinin çalıştırmayı hatırladığı bir komut olarak değil. Önce dağıtımın kendi çözümleyicisinden ve uç nokta envanterinden bir aday edinin ve tünel var olmadan önce bu adın nasıl çözümleneceğini bilinçli olarak tanımlayın. Ardından kural kümesine dokunmadan önce adayı amaçlanan protokol, bağlantı noktası ve adres ailesine göre doğrulayın.

Önce yeni dar izni kurun ve yüklendiğini doğrulayın, çünkü istemciden güvenlik duvarının hâlâ engellediği bir adresi kullanmasını istemek sunucu arızası gibi görünen bir hataya yol açar. Değişiklik sırasında ilgisiz kuralları ellemeyin.

İstemcinin desteklenen yeniden bağlanma yolu üzerinden geçişini gözlemleyin ve hangi uzak adresi seçtiğini doğrulayın. Yalnızca DNS'i güncellemek mevcut bir soketi taşımaz ve uç nokta kalıcılığı ayarı, kayıt değiştikten çok sonra bile istemciyi eski peer'da tutabilir.

Son olarak eskimiş izni bilinçli olarak geri çekin ve eski oturum hâlâ etkinken onaylanmış örtüşme penceresine izin verin. Eski girdiyi çok erken kaldırmak kısa bir kesinti üretir; sonsuza dek bırakmak ise kimsenin açıklayamayacağı bir izin bırakır.

Eski izni bilinçli olarak geri çekin

Kaldırma, riskin çoğunun bulunduğu yerdir, çünkü eski kural şu anda çalışan tek şeydir. Adayın kurulumu başarısız olduysa devam etmeyin ve hâlâ trafik taşıyan girdiyi silmeyin. Kaldırmanın kendisi başarısız olursa, politikayı güncel ilan etmek yerine eskimiş izni eskimiş olarak kaydedin.

Uplink Ethernet'ten Wi-Fi'ye geçtiğinde, taşıma değiştiğinde veya bir hizmet birkaç adres arasında döndüğünde tüm incelemeyi yineleyin. Arayüze özgü bir kuralın ağ değişikliğinden sonra eşleşmeyi bırakması gerekir ve bu davranış bir gerileme gibi görünse de doğrudur.

Ardından sözleşmeyi zararsız trafikle kanıtlayın. Onaylanmış uç nokta kurulum sırasında erişilebilir olmalı, korunan uygulama bağlandıktan sonra çalışmalı ve ilgisiz doğrudan trafik bir kesinti sırasında engelli kalmalıdır. Her iki adres ailesini ve bilinçli olarak başarısız olan bir güncelleme denemesini dahil edin, çünkü sabitlenmiş bir adreste tek bir değişiklikten sonra başarılı olan bir bağlantı bu durumların hiçbirini kanıtlamaz.