1 poin oleh GN⁺ 2024-03-14 | 1 komentar | Bagikan ke WhatsApp

Peningkatan WireGuard di Fly.io

  • Fly.io mengubah kontainer menjadi VM lalu menjalankannya di hardware di seluruh dunia dengan memanfaatkan kekuatan Firecracker.
  • Mereka banyak menggunakan WireGuard, dan kini ini menjadi bagian dari API pelanggan.
  • Setiap kali menjalankan CLI flyctl, sistem membuat stack TCP/IP dan berkomunikasi langsung dengan Fly Machines menggunakan alamat IPv6 yang unik.
  • Pendekatan ini memiliki kelebihan dan kekurangan, dan ada beberapa peningkatan yang telah dilakukan.

Kondisi sebelumnya

  • Server "gateway" yang tersebar di seluruh dunia menerima koneksi WireGuard dan bertugas menghubungkannya ke jaringan privat yang sesuai.
  • Setiap kali flyctl dijalankan, sistem membuat atau menyambungkan proses agen di background.
  • Agen membuat konfigurasi peer WireGuard baru melalui GraphQL API.
  • API mengirim konfigurasi peer ke gateway yang sesuai melalui sistem messaging NATS.
  • Di gateway, layanan wggwd menerima konfigurasi tersebut, menyimpannya ke database SQLite, lalu menambahkannya ke kernel.
  • API merespons permintaan GraphQL dengan mengirimkan konfigurasi, lalu flyctl terhubung ke peer WireGuard.
  • NATS memang cepat, tetapi tidak menjamin pengiriman dan tidak membersihkan peer lama yang tertinggal di gateway.

Cara yang lebih baik

  • Penyimpanan peer WireGuard tidak memerlukan database yang rumit.
  • Sistem diubah agar gateway mengambil konfigurasi dari API saat dibutuhkan.
  • Peer hanya ditambahkan ke kernel saat klien ingin terhubung, dan bisa dihapus saat tidak lagi diperlukan.

Memungkinkan peer WireGuard JIT

  • Antarmuka konfigurasi WireGuard di kernel Linux menggunakan Netlink.
  • Paket permintaan koneksi WireGuard dapat diidentifikasi dan dicegat dengan filter BPF dan packet socket.
  • WireGuard tidak memiliki konsep "klien" dan "server"; ini adalah protokol point-to-point.
  • Saat flyctl mengirim paket UDP ke gateway, itu adalah handshake initiation.
  • Koneksi masuk dapat ditangkap dengan menggunakan filter BPF.
  • Karena berbasis kerangka protokol Noise, permintaan harus didekripsi untuk diidentifikasi.
  • Dengan membuat event feed, sistem bisa mendapatkan kunci publik dari semua pengguna yang mencoba terhubung ke gateway.
  • Setiap kali terlihat peer baru, informasi peer tersebut diambil dan dipasang melalui permintaan ke HTTP API internal.

Meluncurkan app dalam hitungan menit

  • Di Fly.io, app dapat dideploy dengan cepat dan langsung mendapatkan peer WireGuard JIT sendiri.

Melihat grafik

  • Setelah sistem ini dijalankan selama beberapa minggu, jumlah peer WireGuard lama yang tertinggal di gateway berkurang drastis.
  • Gateway mempertahankan state yang lebih sedikit dan konfigurasi peer menjadi lebih cepat.
  • Mereka membagikan hasil yang berhasil pada hari perpindahan melalui chart Grafana.

Opini GN⁺

  • Peningkatan WireGuard di Fly.io adalah contoh bagus bagaimana performa dan stabilitas jaringan bisa ditingkatkan secara signifikan.
  • Pendekatan ini dapat membantu memperkuat pengelolaan trafik jaringan dan keamanan, terutama pada layanan berbasis cloud.
  • Proyek lain dengan fungsi serupa antara lain Tailscale dan ZeroTier, yang juga menawarkan alternatif VPN bagi pengguna pribadi maupun perusahaan.
  • Saat mengadopsi WireGuard, perlu mempertimbangkan konfigurasi jaringan, kebijakan keamanan, kompatibilitas, dan hal-hal serupa.
  • Keuntungan dari pilihan teknologi ini adalah performa yang cepat dan konfigurasi yang sederhana, tetapi integrasi dengan infrastruktur yang sudah ada atau aspek pengelolaannya bisa menjadi tantangan.

1 komentar

 
GN⁺ 2024-03-14
Komentar Hacker News
  • WireGuard di kernel Linux dikatakan menimbulkan masalah dalam membangun desain karena tidak memiliki fitur untuk memasang peer saat ada permintaan.

    • WireGuard di kernel Linux mengalami kesulitan desain karena tidak adanya fitur untuk memasang peer berdasarkan permintaan.
    • Peer dapat ditambahkan saat runtime, tetapi tampaknya tujuannya adalah mengautentikasi peer sebelum menambahkannya ke interface agar mencegah entri yang tidak perlu.
    • Menggunakan filter eBPF untuk langsung mengelola koneksi berbasis routing kunci kriptografi dengan pihak yang telah diautentikasi, lalu setelah verifikasi selesai peer ditambahkan ke interface dan dihapus setelah timeout.
  • Saya setuju bahwa permintaan HTTP lebih andal daripada routing melalui message queue, tetapi saya terkejut bahwa pesan yang hilang karena NATS berdampak besar pada layanan.

    • Setuju dengan pendapat bahwa permintaan HTTP langsung lebih andal daripada message queue, tetapi merasa heran bahwa kehilangan pesan di NATS berdampak cukup besar pada layanan.
    • Mengungkapkan rasa ingin tahu mengapa masalah keandalan yang mencolok bisa terjadi, karena saat pesan hilang NATS diperkirakan akan mencoba mengirim ulang.
  • Saya ingin mempromosikan proyek eksperimental terbaru. Jika Anda tertarik membangun aplikasi Go yang berfungsi sebagai peer WireGuard di ruang pengguna, silakan lihat.

    • Memperkenalkan proyeknya sendiri untuk orang-orang yang tertarik membangun aplikasi Go yang berfungsi sebagai peer WireGuard di ruang pengguna.
    • Dibangun di atas kerja luar biasa dari wireguard-go, tetapi ingin disederhanakan agar lebih cocok digunakan sebagai library.
    • Tertarik membangun service mesh, dan meskipun dukungan berbagai bahasa mungkin sulit, merasa API socket bisa diimplementasikan.
    • Menyebutkan bahwa akselerasi hardware untuk kriptografi WireGuard belum terlihat, sehingga mungkin sulit bersaing dengan mTLS.
    • Bekerja sebagai freelancer di bidang jaringan cepat/aman, dan mempersilakan yang berminat untuk menghubungi (email ada di profil).
  • Menarik bahwa tunneling WireGuard di atas WebSockets adalah konfigurasi default. Ini tidak bagus untuk performa, tetapi sepertinya cocok untuk pekerjaan DevOps yang menggunakan flyctl.

    • Menyoroti fakta bahwa tunneling WireGuard melalui WebSockets adalah konfigurasi default.
    • Meskipun tidak optimal untuk performa, diperkirakan tidak akan menjadi masalah untuk pekerjaan DevOps yang menggunakan flyctl.
    • Bertanya-tanya tentang masa depan QUIC/HTTP3, dan mempertanyakan apakah operator jaringan akan benar-benar menangani UDP di port 443 alih-alih memblokirnya.
  • Kami dapat memasang peer sebagai pengirim, dan flyctl adalah pihak yang merespons. Kernel Linux memulai koneksi WireGuard ke flyctl. Cara ini berhasil, dan protokolnya tidak terlalu peduli siapa server dan siapa klien. Koneksi baru dipasang secepat mungkin.

    • Menjelaskan cara memasang peer sebagai pengirim sementara flyctl menjadi pihak yang merespons, lalu kernel Linux memulai koneksi WireGuard.
    • Menyebutkan bahwa protokol tidak terlalu terikat pada peran server dan klien, dan koneksi baru bisa dibuat dengan sangat cepat.
  • Startup saya menggunakan Fly selama hampir satu tahun. Fitur inti untuk mengubah kode menjadi kode yang ter-deploy dalam waktu kurang dari satu menit itu indah. Anda bisa spin up/down node baru dalam hitungan detik.

    • Membagikan pengalaman startup yang telah menggunakan Fly selama hampir satu tahun.
    • Menilai positif fitur yang memungkinkan deployment kode dengan cepat, tetapi merasa perusahaan ini masih agak belum matang.
    • Menyebut pengalaman server API Fly tidak bisa diakses selama 48 jam, serta masalah putus koneksi yang tidak konsisten pada produk "db".
    • Menunjukkan bahwa akses API Fly sering down sehingga menimbulkan masalah saat menerapkan perubahan layanan baru.
    • Mengatakan pengalaman deployment-nya dirindukan, tetapi merasa lebih puas menggunakan Cloud Run dari GCP.
  • “Setiap kali menjalankan flyctl, CLI kami yang besar dan menggemaskan membuat stack TCP/IP di udara, memiliki alamat IPv6 unik, dan berkomunikasi langsung dengan Fly Machines.”

    • Mengungkapkan rasa penasaran terhadap penjelasan bahwa saat flyctl dijalankan, sebuah stack TCP/IP dibuat seketika dan berkomunikasi langsung dengan Fly Machines melalui alamat IPv6 unik.
  • Apa yang mencegah paket handshake awal dikirim ulang ke stack jaringan? Kalau begitu sepertinya tidak akan ada packet loss. Juga, apa tujuan memeriksa "udp[8] = 1" di filter eBPF?

    • Mengajukan pertanyaan tentang mekanisme yang mencegah paket handshake awal dikirim ulang ke stack jaringan dan alasan memeriksa nilai paket UDP tertentu di filter eBPF.
  • Bagaimana cara men-deploy aplikasi Docker apa pun ke Fly.io? Ambil saja uang saya

    • Menunjukkan minat dan antusiasme untuk mengetahui cara men-deploy aplikasi Docker ke Fly.io.
  • Untuk semua orang lain, saya akan tanpa malu-malu mempromosikan Netmaker.

    • Membagikan pengalaman memuaskan menggunakan Netmaker, menyebut kebutuhan pribadi untuk akses ke AWS VPC, dan berharap Netmaker diadopsi lebih luas.