VPN tamu ESXi: routing atau bridging, putuskan sebelum port group
TUN yang dirutekan butuh rute balik; TAP yang dijembatani butuh jangkauan lapisan 2 dan kebijakan port group yang lebih luas. Tetapkan peran sebelum memperluas mode promiscuous.
Rutekan paket atau perluas domain Ethernet: perubahan port group menyusul pilihan itu. Dari aplikasi yang memegang alamat privat hasilnya bisa tampak identik, sedangkan persyaratan hypervisor sama sekali berbeda. Itulah sebabnya port group diperluas lebih dulu dan pertanyaan desain dijawab kemudian, biasanya setelah badai broadcast. Jalankan pemeriksaan ini berurutan dan berhenti selama persyaratannya masih kabur, karena tidak ada pengaturan port group yang memperbaiki desain yang tidak pernah dipilih.
Keputusan milik pemilik layanan; konfigurasi hypervisor harus menjalankannya, bukan menentukannya secara tidak sengaja.
Periksa apa yang sebenarnya dibutuhkan ujung jauh
Daftar layanan yang harus dijangkau klien jarak jauh dan protokol yang mereka pakai. Jika daftarnya beberapa layanan TCP pada prefiks yang dikenal, routing cukup. Jika ada yang benar-benar butuh ketetanggaan lapisan 2 — penemuan yang bergantung pada broadcast, protokol non-IP, perangkat yang tidak menerima gateway — routing tidak bisa menirunya dan itu harus dikatakan lebih awal. Jujurlah soal entri non-IP dalam daftar itu, karena di situlah desain yang dirutekan gagal diam-diam seminggu kemudian.
Lalu periksa kumpulan klien. Desain yang dirutekan butuh rentang alamat dan rute balik eksplisit di sisi jauh; desain yang dijembatani butuh domain Ethernet yang diperluas memiliki alokasi alamat dan isolasi. Apa pun yang Anda pilih, seseorang di luar VM ini harus menyetujuinya.
Apa yang dituntut tiap desain dari jaringan virtual
Kedua desain berbeda dalam apa yang harus ditanggung jaringan virtual, dan tabel adalah cara terpendek untuk melihatnya:
| Desain | Peran di sisi tamu | Apa yang harus ditampung jaringan virtual | Mode kegagalan jika salah memilih |
|---|---|---|---|
| TUN dirutekan | Router antar prefiks terpisah | Kumpulan klien yang dirutekan plus jalur balik di sisi jauh | Klien mencapai gateway dan tidak pernah mencapai layanan di belakangnya |
| TAP dijembatani | Jembatan lapisan 2 bagi klien yang bergabung | Identitas Ethernet tambahan, lalu lintas broadcast, dan aturan VLAN | vSwitch menjatuhkan frame, atau desain butuh mode promiscuous yang tidak disetujui siapa pun |
Routing membiarkan domain broadcast di tempatnya dan memberi tempat alami untuk membatasi layanan mana yang melintasi gateway. Jembatan memindahkan batas: klien menjadi peserta domain Ethernet yang diperluas, dan alokasi alamat, isolasi, serta kebijakan lapisan 2 kini berlaku bagi mereka. Tulis baris yang dipilih ke catatan perubahan. Kalimat seperti “TUN dirutekan, kumpulan klien 10.90.0.0/24, rute balik di inti” mencegah insinyur berikutnya memperdebatkan ulang desain dari pengaturan port group.
Siapa yang boleh melihat frame siapa
Tanyakan satu hal kepada pemilik platform sebelum menyentuh port group: apakah desain menuntut VM ini menerima frame yang dialamatkan ke peserta lain? Jika jawabannya tidak, tidak ada yang berlaku di bagian ini, karena TUN yang dirutekan tidak pernah butuh visibilitas itu. Jika jawabannya ya, panduan Broadcom tentang mode promiscuous adalah bacaan yang penting: panduan itu menjelaskan seberapa banyak vSwitch yang bisa dilihat VM dan menyarankan membatasi kebijakan itu ke satu port group.
Perlakukan itu sebagai pemeriksaan persyaratan, bukan surat izin. Nyalakan pengaturan untuk satu sambungan khusus saat kebutuhan jembatan tertulis, dan biarkan mati di tempat lain. Trunk VLAN lebar yang disalin dari contoh jembatan lain adalah bagian yang tidak diingat siapa pun untuk dihapus, dan desain satu VLAN harus tetap satu VLAN.
Catat port group mana yang berubah dan mengapa, di tempat yang sama dengan baris desain. Pasangan itulah yang membuat audit berikutnya mungkin.
Jaga objek tamu tetap eksplisit
Di dalam Linux, keanggotaan jembatan dan kepemilikan alamat adalah objek terpisah, dan mencampurnya menyebabkan keadaan setengah berfungsi yang membingungkan. Berikan alamat ke antarmuka jembatan atau ke tunnel yang dirutekan, bukan ke kedua sisi jalur yang sama, dan jaga port anggota bebas dari konfigurasi IP.
Hindari menaruh satu subnet secara independen pada TUN yang dirutekan dan pada antarmuka Ethernet yang tidak terkait. Konfigurasi itu menghasilkan dua jalur ke prefiks yang sama, balasan asimetris, dan utas dukungan soal flapping yang tidak menyebut salah satu jalur. Jika tamu juga menghosting kontainer atau hypervisor lokal, periksa bahwa keduanya belum menjembatani ke uplink yang sama. Dua jembatan pada satu NIC adalah desain, bukan kecelakaan yang ingin Anda temukan saat jendela perubahan.
Konfirmasi dengan jalur paket, bukan ping
Verifikasi jalur sebenarnya, bukan hanya keterjangkauan. Dari klien, konfirmasi alamat sumber mana yang tiba di layanan jauh, lalu bahwa balasannya kembali lewat jalur yang sama. Di tamu, periksa penghitung penerusan untuk aliran tertentu, dan di port group konfirmasi tidak ada visibilitas tambahan yang diaktifkan melebihi kebutuhan desain yang dipilih.
Terakhir, uji arah kegagalan. Hentikan tunnel atau lepaskan klien dan periksa bahwa lalu lintas tidak diam-diam jatuh ke jalur yang dirutekan yang Anda kira tidak terpakai, karena jatuhnya itulah cara desain yang dijembatani diam-diam menjadi router yang tidak diinginkan.