Saran bahwa lab rumahan membutuhkan tunnel penuh biasanya datang dari tutorial yang memilikinya, bukan dari kebutuhan. Tunnel terbelah bukan versi kompromi dari VPN yang benar; itu versi yang tabel rutenya bisa Anda jelaskan. Lab dengan lima layanan dan satu antarmuka pengelolaan tidak perlu setiap paket yang keluar rumah melewati tunnel. Yang dibutuhkannya adalah inventaris dan rute untuk setiap butir dalam inventaris itu.

Mitos: tunnel terbelah adalah kompromi

Mitos itu bertahan karena tunnel penuh lebih mudah dikonfigurasi sekali dan lebih sulit di-debug nanti. Tukar itu wajar untuk laptop di Wi-Fi publik dan salah untuk rak di ruang bawah tanah.

Itu juga menyembunyikan asumsi kedua, yaitu pengalamatan lab tidak punya kesamaan dengan jaringan tempat Anda terhubung.

Inventarisasi sumber daya sebelum rute

Tuliskan setiap subnet lab, layanan yang hidup di sana, nama yang Anda gunakan untuk menyelesaikannya, dan siapa yang diizinkan menjangkaunya; catatan penerusan untuk gateway Anda menjelaskan jalur balik yang menjadi dasar perencanaan Anda. Tambahkan rentang kontainer dan rentang LAN yang mungkin sudah dipakai klien jarak jauh, karena tumpang tindih adalah kegagalan yang dicegah inventaris ini. Rute yang mencakup setiap alamat privat akan berbenturan dengan jaringan rumah cepat atau lambat. Inventaris juga merupakan rencana uji, karena itu layak dilakukan sebelum konfigurasi, bukan sesudahnya.

Tetapkan setiap sumber daya ke sebuah jalur: lewat tunnel, langsung, atau ditolak. Sumber daya tanpa jalur adalah yang nanti memunculkan pertanyaan dukungan yang membingungkan.

Lima baris dan satu kolom keputusan mengalahkan tabel rute yang tidak bisa dibaca siapa pun.

Gateway membutuhkan jalur balik

Penerusan di gateway hanya separuh. Lab membutuhkan rute kembali ke kumpulan klien, atau pengaturan penerjemahan yang didukung agar pengembalian mungkin. Jika balasan tidak menemukan klien, tunnel terlihat tersambung dan setiap permintaan habis waktu; itu gejala perutean, bukan kegagalan VPN. Periksa jalur balik sebagai bagian dari desain, bukan sebagai langkah pemecahan masalah.

Kumpulan klien yang tumpang tindih dengan pengalamatan lab sendiri adalah separuh lain masalah ini, dan gagal dengan cara yang persis sama.

Perbaiki rencananya, bukan gejalanya, saat kedua rentang berbenturan.

Peran pengelolaan dan internet terpisah

Putuskan apakah hanya lalu lintas lab yang memakai tunnel atau tunnel itu juga menjadi jalan keluar internet. Jangan menambahkan rute default hanya karena sebuah tutorial memakainya, karena keputusan itu mengubah ke mana setiap kueri DNS dan setiap pemeriksaan pembaruan pergi. Pertahankan jalur luar ke titik akhir VPN itu sendiri, atau tunnel akan mencoba membawa koneksi luarnya sendiri. Jaga akses pengelolaan tetap sempit dan terjangkau melalui metode pemulihan yang disetujui.

DNS privat dapat dipilih untuk nama lab tanpa mengasumsikan setiap kueri publik membutuhkan resolver yang sama. Itu keputusan resolver, bukan keputusan rute.

Memisahkannya adalah yang membuat mode kegagalan dapat dibedakan nanti.

Uji dari luar, bukan dari LAN

Gunakan koneksi eksternal yang sah alih-alih uji dari LAN yang sama, karena uji dari LAN yang sama dapat menyembunyikan rute balik yang hilang sepenuhnya. Verifikasi alamat lab, nama host privatnya, tujuan langsung yang dimaksudkan, dan perilaku kegagalan yang diperlukan. Kasus kegagalan sama pentingnya dengan kasus keberhasilan: sumber daya yang seharusnya tidak tercapai harus benar-benar tidak tercapai. Catat keempat hasilnya sebelum menyatakan desain selesai.

Lalu simpan konfigurasi rute dan DNS di samping inventaris, dengan pemilik yang disebutkan namanya. Saat lab mendapat subnet lain, perbarui keduanya dan uji lagi.

Rute tak dijelaskan yang tumpang tindih dengan jaringan rumah yang ada adalah hasil bawaan dari melewati langkah itu.

Desain yang selesai itu kecil, terdokumentasi, dan membosankan, yang justru diinginkan lab dari jaringannya. Versi yang menarik adalah yang rusak saat Anda jauh dari rumah.

Artikel terkait