Satu akun VPN di dua server: tiga buku besar status

Satu akun yang dapat masuk ke salah satu dari dua node VPN memunculkan pertanyaan desain jauh sebelum pertanyaan perangkat lunak. Tampilan akun, jaringan yang dimiliki setiap node, dan sesi yang dipegang klien yang terhubung adalah tiga jenis status yang berbeda, dan ketiganya gagal dengan cara berbeda saat Anda menyalinnya ke sana kemari. Menyalin ketiganya ke dalam satu sistem adalah cara umum kehilangan salah satunya.

Telusuri tiga buku besar di bawah ini secara berurutan. Masing-masing menanyakan apa yang otoritatif, apa yang lokal, dan apa yang terjadi ketika node lain tidak ada, dan jawabannya tidak saling mengikuti.

Siapa yang boleh terhubung: satu otoritas, banyak node

Mulailah dari buku besar penerimaan: sumber identitas mana yang otoritatif, penerbit sertifikat mana yang dipercaya, akun mana yang memenuhi syarat, faktor kedua apa yang berlaku, dan apa yang dapat dijangkau setiap akun. Lalu catat bagaimana setiap node mengetahui perubahan, dan seberapa cepat.

Basis data bersama adalah salah satu komponen yang mungkin dari jawaban itu. Itu bukan bukti bahwa setiap kebijakan yang relevan tinggal di sana, atau bahwa setiap node menerapkan perubahan pada saat yang sama. Akun yang dinonaktifkan di node A tetapi masih diterima di node B berarti proses offboarding belum selesai.

Putuskan apa yang dilakukan node ketika otoritas tidak dapat dijangkau. Menerima kredensial tersimpan selama gangguan adalah pilihan kebijakan dengan biaya keamanan, dan menolaknya adalah pilihan kebijakan dengan biaya ketersediaan. Keduanya dapat dipertahankan; membiarkannya tanpa dokumentasi tidak.

Pisahkan otoritas penerbit dari data akun. Beberapa gateway dapat memercayai CA yang sama tanpa memegang kunci penandatangannya, dan setiap node tetap membutuhkan sertifikat servernya sendiri dan hubungan kepercayaan sisi kliennya sendiri.

Apa yang dimiliki sebuah node: alamat dan rute

Buku besar kedua bersifat lokal untuk setiap node: alamat pendengar, identitas server, kumpulan alamat, rute ke sumber daya privat, kebijakan penyelesai, dan bagaimana lalu lintas keluar menuju internet. Akun yang sama dapat dilayani oleh salah satu node sementara objek-objek ini tetap berbeda.

Jalur kembali adalah bagian yang terlupakan. Jika kedua node membagikan alamat dari kumpulan yang sama, jaringan privat tidak dapat mengetahui node mana yang memiliki klien tertentu, dan balasannya dapat dikirim ke tempat yang salah. Kumpulan berbeda juga memerlukan rute dan izin, jadi rentang nomor yang berbeda bukanlah desain yang lengkap.

Arahkan klien ke satu node secara sengaja. Pemilihan DNS, daftar titik akhir klien, dan layanan front-end adalah mekanisme berbeda dengan perilaku kesehatan dan failover yang berbeda. Memilih salah satunya tidak masalah; memperlakukan “penyeimbangan beban” sebagai desain membuat jalur kembali dan perilaku kegagalan tidak terdefinisi.

Contoh produk yang terdokumentasi membantu di sini. Dokumentasi replikasi Pritunl memperlakukan jaringan VPN sebagai objek per replika, dan klien pada replika berbeda memerlukan rute dan konektivitas tambahan untuk saling menjangkau. Itu pengaturan khusus produk, bukan resep untuk Community OpenVPN, tetapi menunjukkan mengapa menambahkan replika mengubah jaringan dan bukan hanya penyimpanan akun.

Apa itu sesi: status hidup, bukan baris

Buku besar ketiga adalah sesi hidup. Klien yang terhubung memiliki status protokol dan penetapan jaringan pada node yang menerimanya. Akun yang diketahui di node lain tidak memberi node itu sesi, kunci, atau kemampuan melanjutkan paket.

Bersikap tegas tentang apa yang terjadi ketika node gagal. Hasil yang didukung mungkin berupa penyambungan ulang ke node lain dengan autentikasi baru dan alamat baru, setelah itu aplikasi pulih dengan caranya sendiri. Jika penyerahan tanpa gangguan diperlukan, persyaratan itu membutuhkan dukungan implementasi yang eksplisit, bukan kesimpulan dari replikasi basis data. Tuliskan jawabannya di tempat insinyur jaga dapat menemukannya.

Aturan kapasitas membutuhkan perlakuan yang sama. Batas dua sesi bersamaan per akun hanya dapat ditegakkan antar node jika suatu otoritas memiliki pandangan terkoordinasi tentang slot yang terpakai. Daftar lokal node dan catatan akun historis tidak menjumlah menjadi pandangan itu.

Menguji ketiga buku besar

Latih masing-masing secara terpisah. Masuk melalui node A, lalu melalui node B, dan pastikan keduanya berhasil dengan rentang alamat yang diharapkan. Tarik sebuah identitas dan periksa kedua node, bukan hanya yang kebetulan Anda uji. Lalu hentikan satu node dan amati apa yang sebenarnya dilakukan klien dan aplikasi privat itu.

Sertakan jalur kembali dalam uji penerimaan. Klien yang terhubung ke B tetapi tidak dapat menerima balasan dari sumber daya di belakang A telah lulus pemeriksaan penerimaan dan gagal pada yang jaringan, dan perbedaan itu harus muncul dalam laporan.

Desain akun multi-node baru lengkap ketika ketiga buku besar memiliki pemilik eksplisit, jalur perubahan, dan perilaku kegagalan. Menyalin berkas konfigurasi antar node tidak menjawab satu pun pertanyaan itu.