OpenVPN arkasında Docker ve VM trafiği: yönlendirme mi, yeniden numaralandırma mı?

OpenVPN istemcisi çalıştıran ana makinedeki konteynerler ve konuklar ya dönüş yolunu kaybeder ya da tünel önekiyle çakışır. Üç soru çözümü seçer.

Ana makine tünel üzerinden gezinir, yanındaki konteyner ise hiçbir yere ulaşamaz. Kendi VPN istemcisini çalıştıran bir konteynerden port yayımlamak daha kötüdür: istek gelir ama yanıt asla çıkmaz. İkisi de ana makinedeki yönlendirme kararlarıdır ve Docker yalnızca haberci.

Hangi iki durumdan biriyle karşı karşıya olduğunuzu üç soru belirler ve yaklaşık bir dakika sürer.

Aynı görünen iki arıza

Birincisi dönüş yolu sorunudur. Yayımlanan port konteynere çevrilir, istek gelir ve yanıt ana makinenin varsayılan yolu üzerinden yönlendirilir; bu yolu OpenVPN istemcisi tun0'a çevirmiştir. Yanıt, uzak tarafın beklemediği bir adresten çıkar ve düşürülür. İkincisi önek çakışmasıdır: Docker'ın varsayılan köprüsü 172.17.0.0/16'ya sahiptir ve kurumsal bir tünel aynı aralığı iter.

Biri yönlendirme tablosuyla, diğeri köprüyü yeniden numaralandırarak düzeltilir. Hangisinin hangisi olduğunu bilmeden düzenlemek, çalışan bir konteyneri bozmanın yoludur.

Üç soruyla karar verin

Birinci soru: VPN'i durdurduğunuzda arıza kayboluyor mu? Tünel kapalıyken her şey çalışıyorsa dönüş yolundan şüphelenin. İkinci soru: ip route show table all aynı öneki iki kez, bir kez köprüde ve bir kez tun0'da listeliyor mu? Çakışma budur. Üçüncü soru: etkilenen adres bir konteyner mi, NAT konuğu mu yoksa köprülenmiş konuk mu?

Üçüncü soru önemlidir çünkü her birinin doğru düzeltmesi farklıdır ve konteyner düzeltmesini bir libvirt konuğuna uygulamak bir akşamı boşa harcar.

ip route
ip route show table all | grep -E '172\.1[7-9]|10\.8'
docker network inspect bridge --format '{{.IPAM.Config}}'

Dönüş yolu: tek bir kaynak adresi için tablo

Konteynerin trafiği fiziksel arayüzden çıkması gerektiğinde ana makine tüneli kullanıyorsa, kaynak tabanlı yönlendirme en küçük değişikliktir. Konteynerin adresiyle eşleşen bir kural ekleyin ve onu ayrı bir tabloya gönderin. Ana makinede başka hiçbir şey hareket etmez.

ip rule add from 172.22.0.3 lookup 10
ip route add default via 172.22.0.1 table 10

Kaynağı bu adres olan her paket önce tablo 10'a bakar ve tablo 10 onu tünel yerine köprünün geçidine gönderir.

Şununla doğrulayın: ip route get 1.1.1.1 from 172.22.0.3. Yanıt köprünün arayüzünü adlandırmalı, tun0'ı değil. Bu şekilde eklenen kurallar yeniden başlatmada kaybolur, bu yüzden onları konteynere sahip olan unit veya ağ kancasına koyun.

Aynı desen bir WireGuard konteyneri için de çalışır; orada da yanıt yolunun açık bir kurala ihtiyacı vardır.

Önek çakışması: köprüyü yeniden numaralandırın

Bir yönlendirme tablosu bir öneki tek bir yere gönderir. VPN 172.17.0.0/16'yı iterken Docker'ın köprüsü zaten oradaysa, düşük metrik kazanır: Docker bağlı rotasını metrik 0'da kurar ve itilen rota 50 ile gelir. O zaman Docker çalışmaya devam ederken tünel bozuk görünür ya da tersi, kurulum sırasına göre. Metrikle savaşmak yerine köprüyü yeniden numaralandırın.

{
  "bip": "10.200.0.1/24",
  "default-address-pools": [{"base": "10.201.0.0/16", "size": 24}]
}

Değişiklikten sonra Docker'ı yeniden başlatın ve eski havuzla oluşturulmuş ağları yeniden oluşturun. Metriği değiştirmek yalnızca çakışmayı bir sonraki açılışa taşır.

VM'ler yine başka bir yanıt ister

Varsayılan NAT ağındaki bir libvirt konuğu ana makinenin yönlendirmesini devralır ve ana makinenin tüneli varsayılan rotaya sahip olduğunda dışarıya çıkamaz. Konuğu köprülenmiş veya macvtap bir aygıta taşımak ona fiziksel ağda kendi yolunu verir. virt-manager'da donanım ekleyin, Network'ü seçin, kaynağı macvtap ana makine aygıtına ayarlayın, model olarak virtio'yu koruyun ve ardından eski NAT arayüzünü devre dışı bırakın.

Bir macvtap konuğu genellikle kendi ana makinesine ulaşamaz. Bu bir arıza değil beklenen davranıştır ve arkanızda bıraktığınız nota aittir.

Yalnızca ana makinenin LAN'ına ihtiyacı olan bir konuk için sağlayıcının istemcisinde eksik anahtar olabilir: Mullvad ile mullvad lan set allow libvirt'e dokunmadan yerel erişilebilirliği geri getirir. Ve bir konteynere yalnızca tünel üzerinden erişilebilmesi gerekiyorsa, yayımlanan portu tünel adresine bağlayın, -p 10.8.0.5:8080:8080, her adreste yayımlamak yerine.

İlgili makaleler