Yukarı akış VPN'nin arkasındaki aşağı akış istemcileri: yol mu NAT mi?

Bir geçit kendi cihazlarınız için WireGuard, başkasının ağına doğru da bir OpenVPN istemcisi çalıştırır. İki iç arayüz arasındaki yönlendirme çalışır ve aşağı akış alt ağının artık yukarı akış hizmetinin parçası olduğu sonucuna varmak kolaydır. Değil. İstemcinin çektiği yol, geçidinize isteklerin nereye gönderileceğini söyler; uzak ağın hiç duymadığı cihazlara trafiği nasıl geri gönderdiği hakkında hiçbir şey söylemez. Tek bir kural eklemeden önce yukarı akışın gerçekten desteklediği bir dönüş modeli seçin.

Yönlendirmeye dokunmadan önce dönüş modeline karar verin

Bu anlatımda aşağı akış istemcileri 10.90.0.0/24 kullanır, geçide atanan yukarı akış tünel adresi 10.80.0.6 ve onaylanmış uzak kaynak 172.20.0.30. Bu biçime iki model uyar: aşağı akış kaynağını koruyup uzak tarafın onu yönlendirmesini sağlamak ya da kaynağı geçidin kendi tünel adresine çevirmek. Bu karardan sonraki her şey mekaniktir ve kararın kendisi hizmetin sahibini gerektirir. Yukarıdaki satırlardan biri uzak tarafla yönlendirme anlaşmasıdır; diğeri tek başınıza yapabileceğiniz yerel bir politika değişikliğidir. İkisini karıştırmak, on dakikalık bir değişikliği müzakereye çeviren şeydir.

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

Bir satır seçin ve ona bağlı kalın. Satırlar adım değil alternatiftir ve karıştırılmaları incelemede kimsenin açıklayamayacağı bir tasarım üretir.

Yol ile kaynak koruma

Uzak taraf aşağı akış adresinden bir istek alır, bu yüzden o alt ağ için desteklenen bir yol ve peer sahipliği, ayrıca onu kabul etme yetkisi gerekir. Bunlar uzak ayarlardır ve hiçbir yerel Linux yolu bunları oluşturmaz. Bunları açıkça ve yazılı olarak isteyin; öneki ve onu taşıyacak tünel peer'ını ekleyin ve yanıtın hizmetin siteden siteye düzenlemeleri destekleyip desteklememesine bağlı olacağını bekleyin.

Yanıt evet ise yerel yapılandırma küçüktür: iletim açık, aşağı akış aralığını kapsayan WireGuard peer'ının allowed-ips değerleri ve geçişe iki yönde izin veren güvenlik duvarı politikası.

Bilinçli kaynak çevirisi

Hizmet trafiği yalnızca bağlı istemci adresine geri gönderiyorsa, çıkışta kaynağı o adrese çevirin ve yanıtlar için onu tersine çeviren conntrack durumunu koruyun. Kuralı amaçlanan aşağı akış kaynaklarına, amaçlanan uzak hedeflere ve yukarı akış arayüzüne sınırlayın. Her arayüzden çıkan her şeyi çeviren bir kural bu gereksinimden çok daha büyük bir politikadır ve sizi sonra şaşırtacaktır.

IPv6 kendi tasarımını gerektirir; bir IPv4 masquerade satırını kopyalamak mimari değildir. Çevrilen yolu önbelleğe alınmış değil, yeni bir bağlantıyla test edin.

Yerel veri yolu yine de çalışmak zorunda

Çeviri yerel işi ortadan kaldırmaz: geçit yine aşağı akış hedeflerine bir yol, doğru WireGuard peer kaynak sahipliği, açık iletim ve arayüzler arasında dar bir güvenlik duvarı politikası gerektirir. Geçidin kendisinde oluşturulan bir istek bu izinlerin hiçbirini denemez, bu yüzden geçitteki yerel testler geçerken aşağı akış cihazları hâlâ başarısız olur.

Geçitten değil, gerçek bir aşağı akış cihazından test edin. Kaynak adresi bu alıştırmanın bütün amacıdır.

Tek kaynak tek oturum kimliği demektir

Uzak hizmet, her aşağı akış cihazı için bağımsız kimlik doğrulama değil, geçidin kimliği doğrulanmış oturumunu ve çevrilmiş adresini görür. Cihaz başına izinleri ve uygulama kimliklerini açık tutun ve birkaç cihaz adına hareket eden bir geçide izin verilip verilmediğini hizmetin sahibiyle doğrulayın. Çeviri, cihaz başına kayıt koşulunu atlatmanın yolu değildir; hizmet her cihazın kaydolmasını istiyorsa o modeli kullanın ya da siteden siteye bir düzenleme için görüşün.

Bu doğrulamayı kuralın yanına runbook'a yazın, çünkü bir sonraki gözden geçiren tasarımın onaylanıp onaylanmadığını yoksa yalnızca elverişli mi olduğunu soracaktır.

Bağlantı kesildiğinde durumu tanımlayın, sonra üç isteği test edin

Yukarı akış tüneli düştüğünde ne olacağına karar verin. Yetkili uzak trafik, yasak olan yerde sıradan bir WAN yedek yolunu sessizce izlememelidir, bu yüzden geçişe izin veren güvenlik duvarı politikası da kapalı olarak başarısız olmalıdır. Ardından gerçek bir aşağı akış cihazından üç durumu test edin: çalışan izinli bir istek, başarısız olan izinsiz bir istek ve izinli olanı durduran bir yukarı akış arızası.

Geri almayı her kural için tek satırda kaydedin, böylece değişiklik niyet yeniden kurulmadan geri alınabilsin.