Proxmox'ta LXC veya VM içinde WireGuard: nerede çalışmalı?

WireGuard, arayüzünü sahiplenecek tam olarak bir çekirdeğe ihtiyaç duyar ve bu gerçek, performans konuşmaya girmeden önce Proxmox yerleşim tartışmasının çoğunu çözer. LXC konteyneri ana makine çekirdeğinin ad alanı görünümüdür, VM ise kendi çekirdeğini başlatır. Yani faydalı soru hangi seçeneğin daha hafif olduğu değil, hangi çekirdeği değiştirmeye razı olduğunuz ve hangi kurtarma yoluyla yaşayabileceğinizdir. Buna yanıt verin, ana makine, konteyner veya VM seçimi genellikle kendiliğinden oluşur.

LXC konuğu ana makine çekirdeğinin içinde çalışır

Bir konteynerin içine wireguard-tools kurmak size denetim programını verir, özel bir çekirdek değil. Oluşturduğunuz wg0 arayüzü ana makinenin ağ yığınına kaydedilir ve ana makinenin modül listesinde görünür. Bu yüzden bir konteyner tüm paket denetimlerini geçip yine de ana makine çekirdeğinde modül yoksa ilk wg komutunda başarısız olabilir. Ve Proxmox konteyner başvurusu bu paylaşılan çekirdek modelini, çalıştığınız ad alanı ve yetki sınırlarıyla birlikte belgeler.

Yetki ikinci kısıttır. Bir arayüzü ayağa kaldırıp ona adres bağlamak için onu sahiplenen ad alanının içindeki ağ yönetimi hakları gerekir ve ayrıcalıksız bir konteyner bu hakları doğrudan tutmak yerine kendi kullanıcı ad alanı üzerinden eşler. İlk yanıt olarak asla tam ayrıcalığa uzanmayın; konteynerden gerçekte ne istendiğine bakın ve sonra onu verin.

Ana makine çekirdeği de paylaşılan bir bağımlılıktır. Bir Proxmox çekirdek güncellemesi WireGuard uygulamasını her konteynerin altında aynı anda değiştirir; bu, bir güncelleme ile bir konteynerin beklentileri uzlaşana kadar kullanışlıdır.

Ana makine, konteyner, VM: her yerleşim gerçekte neyi sahiplenir

Ana makinede yerleşim VPN'i hipervizörün kendi ağına koyar. Rotalar, güvenlik duvarı kuralları ve tünel ana makine kurtarmasının parçası olur ve oradaki bir hata yönetim arayüzünü de alıp götürebilir. Bu, konsoldan erişebildiğiniz bir ana makinede altyapı yönlendirmesi için kabul edilebilir, bant dışı erişimi olmayan uzak bir makinede ise acı vericidir.

Konteyner hizmeti paketlenmiş ve yeniden başlatılabilir tutarken ana makine çekirdeğini ödünç almaya devam eder. Bilinçli olarak paylaşılan çekirdekli bir hizmete uygundur ve yeniden inşa etmek için küçük bir birim verir. Bağımsız bir çekirdek vermez, bu yüzden belirli bir modül derlemesi gerektiren her şey bu seçenekten uzağa işaret eder.

VM daha fazla bellek ve yamalanacak bir sistem daha maliyetlidir; karşılığında tünel kendi çekirdeğini, kendi yönlendirme tablosunu ve bir anlık görüntü sınırını alır. Kötü bir değişiklikten sonra geri aldığınız şey VPN ise, o anlık görüntü ek yüke değer.

Sizin yerinize seçen üç koşul

Tünel, Proxmox ana makinesinin sunmadığı bir çekirdek sürümüne veya WireGuard özelliğine ihtiyaç duyuyorsa burada durun ve VM kullanın. Bir konteynere daha yeni çekirdek kuramazsınız ve tek bir konuğu memnun etmek için hipervizör çekirdeğini değiştirmemelisiniz.

Tünel, gerçek LAN önekleri için sitenin ağ geçidiyse, dönüş rotasının zaten kime ait olduğunu sorun. Konteyner trafiği yönlendirebilir, ancak arayüzleri ana makinenin yığınında oturur, bu yüzden ana makine eninde sonunda yapılandırmanın bir kısmını taşır, planlamış olsanız da olmasanız da. Ana makinede yerleşim bu konuda dürüsttür; konteynerde yerleşim çoğu zaman değildir.

Sonra bir hatanın etki yarıçapını tartın. Konteyneri yeniden başlatmak ucuzdur, VM anlık görüntüsünü geri yüklemek öngörülebilirdir ve ana makine ağını onarmak fiziksel veya konsol erişimi gerektirebilir. Doğru seçim, en kötü durumunu olayın olduğu saatte gerçekten kurtarabildiğiniz seçenektir.

Dördüncü soru nadiren belirleyicidir ama söylenmeye değer: ana makinedeki başka bir şeyin tünel arayüzünü görmesi gerekiyor mu? Gerekiyorsa, ana makinede veya konteynerde yerleşim bu görünürlüğü yerel tutar, VM ise sizi konuk ile ana makine arasında yönlendirme yapmaya zorlar.

Trafiği içinden geçirmeden önce yerleşimi kanıtlayın

Kurulumdan sonra arayüze gerçekte hangi çekirdeğin hizmet ettiğini ve konteynere onu tutması için yeterli yetki verilip verilmediğini doğrulayın:

$ pct config 101 | grep -E 'unprivileged|features'
unprivileged: 1
$ pct exec 101 -- wg show
interface: wg0
  listening port: 51820
$ pct exec 101 -- ip -4 addr show wg0
inet 10.60.0.2/24 scope global wg0

Sonra ana makineden iletim tarafını denetleyin, çünkü yalnızca el sıkışma tünelin ayakta olduğunu kanıtlar. İstemci adresi için ip route get kullanın ve sonraki atlama ile arayüzün tasarıma uyduğunu, karşı tarafta dönüş yolunun bulunduğunu doğrulayın.

Dağıtımı yazılı bir sahiple bırakın: uygulamayı hangi çekirdek taşıyor, arayüzü hangi ad alanı tutuyor ve ağ geçidine hangi önekleri iletme izni verildi. O tek cümle, üç yerleşimin herhangi bir kıyaslama karşılaştırmasından daha fazla olayı önler.