JIT WireGuard teknolojisi

Fly.io'nun WireGuard iyileştirmeleri

• Fly.io, container'ları VM'lere dönüştürerek bunları dünya genelinde donanım üzerinde Firecracker'ın gücüyle çalıştırır.
• WireGuard'ı yoğun biçimde kullanır ve artık bu, müşteri API'sinin bir parçasıdır.
• flyctl CLI her çalıştığında bir TCP/IP stack oluşturur ve benzersiz bir IPv6 adresi kullanarak Fly Machines ile doğrudan iletişim kurar.
• Bu yaklaşımın artıları ve eksileri vardır ve bazı iyileştirmeler yapılmıştır.

Önceki durum

• Dünya genelindeki "gateway" sunucuları WireGuard bağlantılarını kabul eder ve bunları uygun özel ağa bağlama görevini üstlenirdi.
• flyctl her çalıştığında bir arka plan agent süreci oluşturur ya da buna bağlanırdı.
• Agent, GraphQL API'de yeni bir WireGuard peer yapılandırması oluştururdu.
• API, uygun gateway'e peer yapılandırmasını NATS mesajlaşma sistemi üzerinden gönderirdi.
• Gateway tarafındaki wggwd servisi yapılandırmayı alır, SQLite veritabanına kaydeder ve çekirdeğe eklerdi.
• API, GraphQL isteğine yanıt vererek yapılandırmayı iletir ve flyctl WireGuard peer'ine bağlanırdı.
• NATS hızlıdır, ancak teslimatı garanti etmez ve gateway'lerde kalan eski peer'leri temizlemez.

Daha iyi bir yöntem

• WireGuard peer'lerini saklamak için karmaşık bir veritabanı gerekmez.
• Sistem, gateway'lerin ihtiyaç duyduklarında yapılandırmayı API'den alacağı şekilde değiştirildi.
• İstemci yalnızca bağlantı istediğinde peer çekirdeğe eklenebilir, gerekmiyorsa kaldırılabilir.

JIT WireGuard peer'leri mümkün

• Linux çekirdeğindeki WireGuard yapılandırma arayüzü Netlink kullanır.
• WireGuard bağlantı isteği paketleri BPF filtreleri ve packet socket ile tanımlanıp yakalanabilir.
• WireGuard'da "client" ve "server" kavramları yoktur; bu, point-to-point bir protokoldür.
• flyctl gateway'e bir UDP paketi gönderdiğinde bu bir handshake initiation olur.
• Gelen bağlantılar BPF filtresi kullanılarak yakalanabilir.
• Noise protocol framework temel alındığından, isteği tanımlamak için şifre çözme gerekir.
• Gateway'e bağlanmayı deneyen tüm kullanıcıların açık anahtarlarını almak için bir event feed oluşturulabilir.
• Her yeni peer görüldüğünde, dahili bir HTTP API isteği üzerinden ilgili peer bilgisi alınıp kurulabilir.

Uygulamaları dakikalar içinde yayına almak

• Fly.io'da uygulamaları hızlıca deploy edip kendi JIT WireGuard peer'inizi elde edebilirsiniz.

Grafiğe göz atmak

• Bu sistem birkaç hafta boyunca çalıştırıldı ve gateway'lerde kalan eski WireGuard peer sayısı belirgin biçimde azaltıldı.
• Gateway'ler daha az state tutuyor ve peer yapılandırmaları daha hızlı hale geliyor.
• Geçiş günündeki başarılı sonuçlar bir Grafana grafiğiyle paylaşılıyor.

GN⁺'un görüşü

• Fly.io'nun WireGuard iyileştirmeleri, ağ performansı ve güvenilirliğini önemli ölçüde artıran iyi bir örnek.
• Bu yaklaşım, özellikle bulut tabanlı hizmetlerde ağ trafiği yönetimini ve güvenliği güçlendirmeye yardımcı olabilir.
• Benzer işlevler sunan diğer projeler arasında Tailscale ve ZeroTier bulunuyor; bunlar da bireysel ve kurumsal kullanıcılara VPN alternatifleri sunuyor.
• WireGuard'ı devreye alırken ağ yapılandırması, güvenlik politikaları ve uyumluluk gibi konular dikkate alınmalı.
• Bu teknolojiyi seçmenin avantajları yüksek performans ve basit yapılandırma olsa da, mevcut altyapıyla entegrasyon ve yönetim açısından zorluklar yaratabilir.

[GN⁺]

Hacker News görüşleri

• Linux çekirdeğindeki WireGuard'ın istek üzerine peer kurma özelliği olmadığı için tasarımın uygulanmasında sorunlar çıktığı söyleniyor.

  • Linux çekirdeğindeki WireGuard'ın, isteğe göre peer kurma özelliğinin olmaması nedeniyle tasarımda zorluklar yaşandığı belirtiliyor.
  • Çalışma anında peer eklenebiliyor, ancak gereksiz girdileri önlemek için peer'ı arayüze eklemeden önce kimlik doğrulamasından geçirmek istiyorlar gibi görünüyor.
  • eBPF filtresi kullanarak kimliği doğrulanmış karşı taraflarla kriptografik anahtar yönlendirmesine dayalı bağlantıları doğrudan yönetiyor, doğrulama tamamlanınca peer'ı arayüze ekleyip zaman aşımından sonra kaldırıyorlar.

• HTTP isteklerinin mesaj kuyruğu üzerinden yönlendirmeden daha güvenilir olduğuna katılıyorum, ancak NATS yüzünden kaybolan mesajların hizmeti bu kadar büyük etkilemesine şaşırdım.

  • Doğrudan HTTP isteklerinin mesaj kuyruğundan daha güvenilir olduğu görüşüne katılıyor, ancak NATS'teki mesaj kaybının hizmet üzerinde bu kadar büyük etki yaratmasına şaşırdığını söylüyor.
  • Mesaj kaybı olduğunda NATS'in yeniden gönderim deneyeceğinin bekleneceğini, buna rağmen neden bu kadar belirgin bir güvenilirlik sorunu yaşandığını merak ediyor.

• Son dönemdeki deneysel bir projemi tanıtmak istiyorum. User-space WireGuard peer'ı olarak çalışan bir Go uygulaması geliştirmekle ilgileniyorsanız, göz atın.

  • User-space WireGuard peer'ı olarak çalışan bir Go uygulaması geliştirmek isteyenler için kendi projesini tanıtıyor.
  • wireguard-go'nun başarılı çalışmalarını temel alıyor, ancak bunu kütüphane olarak kullanıma daha uygun hale getirmek için sadeleştirmek istiyor.
  • Service mesh kurmaya ilgi duyuyor; farklı dil desteğinin zor olabileceğini ama bir socket API uygulanabileceğini düşünüyor.
  • WireGuard şifrelemesi için donanım hızlandırmasının henüz görünmediğini, bu yüzden mTLS ile rekabet etmesinin zor olabileceğini belirtiyor.
  • Yüksek hızlı/güvenli ağ iletişimi alanında freelancer olarak çalıştığını ve ilgilenenlerin iletişime geçebileceğini ekliyor (e-posta profilinde).

• WireGuard'ı WebSockets üzerinden tünellemenin varsayılan ayar olması ilginç. Performans için iyi değil ama flyctl kullanılan DevOps işleri için uygun olacaktır.

  • WireGuard'ın WebSockets üzerinden tünellenmesinin varsayılan olması dikkat çekici bulunuyor.
  • Performans açısından ideal olmasa da flyctl kullanılan DevOps işleri için sorun yaratmayacağı düşünülüyor.
  • QUIC/HTTP3'ün geleceğini merak ediyor ve ağ operatörlerinin UDP'yi 443 portunda engellemek yerine düzgün şekilde işleme ihtimalini sorguluyor.

• Gönderen taraf olarak peer'ı kurabiliyoruz ve flyctl yanıtlayan taraf oluyor. Linux çekirdeği flyctl'e WireGuard bağlantısını başlatıyor. Bu yöntem çalışıyor ve protokol, sunucunun ya da istemcinin kim olduğu konusunda çok da hassas değil. Yeni bağlantı mümkün olan en kısa sürede kuruluyor.

  • Gönderen taraf olarak peer kurulup, flyctl yanıtlayıcı olurken Linux çekirdeğinin WireGuard bağlantısını başlatması şeklindeki yaklaşım açıklanıyor.
  • Protokolün sunucu ve istemci rollerine çok takılmadığı, yeni bağlantıların da çok hızlı kurulabildiği belirtiliyor.

• Startup'ım yaklaşık bir yıldır Fly kullanıyor. Kodu bir dakikadan kısa sürede dağıtılmış koda dönüştüren temel özellik harika. Yeni node'ları birkaç saniye içinde ayağa kaldırıp kapatabiliyorsunuz.

  • Startup'ının yaklaşık bir yıldır Fly kullandığı deneyimini paylaşıyor.
  • Kodun hızlı dağıtılabilmesini çok olumlu değerlendiriyor, ancak şirketin biraz olgunlaşmamış olduğunu düşündüğünü söylüyor.
  • API sunucusunun Fly üzerinde 48 saat boyunca erişilemez olduğu bir deneyimden ve db ürününde tutarsız bağlantı kopmaları yaşandığından bahsediyor.
  • Fly'ın API erişiminin sık sık kesildiğini ve bunun yeni hizmet güncellemelerini dağıtmayı zorlaştırdığını belirtiyor.
  • Dağıtım deneyimini özlediğini ama GCP'nin Cloud Run hizmetini kullanmaktan daha memnun olduğunu ifade ediyor.

• “flyctl'i her çalıştırdığınızda, sevimli ve devasa CLI'miz havadan bir TCP/IP stack oluşturuyor ve kendine özgü bir IPv6 adresiyle doğrudan Fly Machines ile iletişim kuruyor.”

  • flyctl çalıştırıldığında anlık olarak bir TCP/IP stack oluşturulup benzersiz bir IPv6 adresi üzerinden Fly Machines ile doğrudan iletişim kurulması açıklaması merak uyandırıyor.

• İlk handshake paketinin ağ stack'ine yeniden iletilmesini engelleyen şey nedir? Böyle olursa paket kaybı olmaz gibi görünüyor. Ayrıca eBPF filtresinde udp[8] = 1 kontrolünün amacı nedir?

  • İlk handshake paketinin ağ stack'ine yeniden iletilmesini engelleyen mekanizmanın ne olduğu ve eBPF filtresinde belirli bir UDP paket değerinin neden kontrol edildiği soruluyor.

• Rastgele dockerize edilmiş bir uygulamayı Fly.io'ya nasıl deploy ederim? Paramı alın

  • Dockerize edilmiş bir uygulamayı Fly.io'ya deploy etme yöntemine yönelik ilgi ve istek dile getiriliyor.

• Herkes için, Netmaker'ın reklamını utanmadan yapacağım.

  • Netmaker ile memnuniyet verici bir deneyim yaşadığını paylaşıyor, AWS VPC'ye kişisel erişim ihtiyacından söz ediyor ve Netmaker'ın daha geniş çapta benimsenmesini umduğunu belirtiyor.