VM GCP dengan beberapa NIC: mengapa balasan keluar dari antarmuka yang salah
Rute cloud dan rute tamu adalah dua keputusan. Telusuri satu permintaan cabang dan satu permintaan internet melalui kedua NIC sebelum menambahkan aturan kebijakan.
Melampirkan antarmuka kedua ke VM Compute Engine memberinya lampiran jaringan lain, bukan jalur balik simetris. Tamu tetap memilih antarmuka dan alamat sumber dari rute dan aturannya sendiri. Google Cloud kemudian menerapkan perutean VPC dan kebijakan firewall di sekitar antarmuka tempat paket keluar. Ketika kedua keputusan itu tidak sepakat, permintaan tiba di satu NIC dan balasan keluar melalui NIC lain, dan cabang melihat percakapan setengah terbuka.
Telusuri jalurnya dalam lima langkah dan ketidaksesuaian akan muncul sebelum Anda menulis aturan kebijakan.
Langkah 1: petakan NIC cloud ke perangkat tamu
Cloud menamai antarmuka nic0, nic1 dan seterusnya, sedangkan tamu melihat nama perangkat yang tidak harus sama. Selesaikan pemetaan dari metadata instans atau dari alamat antarmuka itu sendiri sebelum hal lain. Rute default biasa yang disediakan DHCP dikaitkan dengan nic0, itulah sebabnya jalur menghadap internet begitu sering menang secara tidak sengaja. Menulis kebijakan berdasarkan nama perangkat yang ditebak adalah cara aturan yang benar mendarat di antarmuka yang salah.
Catat alamat, nama perangkat, dan VPC tempat masing-masing berada. Peta tiga kolom itu adalah masukan untuk setiap langkah berikutnya.
Langkah 2: namai dua keputusan perutean
Keputusan pertama milik tamu: antarmuka mana dan alamat sumber mana untuk paket ini. Keputusan kedua milik cloud: apa yang diizinkan rute VPC dan kebijakan firewall di sekitar antarmuka itu.
Rute yang terlihat di VPC yang menghadap VPN tidak menjadi rute tamu yang memilih NIC itu. Rute cloud menjelaskan apa yang dapat dikirim jaringan, sedangkan rute tamu menentukan apa yang dilakukan paket.
Langkah 3: pilih kebijakan jalur balik
Untuk kumpulan prefiks cabang yang kecil dan stabil, rute tujuan eksplisit di tamu adalah ekspresi paling sederhana: balasan ke prefiks itu keluar melalui antarmuka yang menghadap VPN. Ketika beberapa layanan sengaja memakai alamat sumber lokal yang berbeda, aturan berbasis sumber yang memilih tabel per antarmuka menjaga setiap balasan dalam konteks yang tepat. Dokumentasi beberapa antarmuka menjelaskan penamaan NIC dan perilaku rute default yang menjadi andalan rancangan ini.
Setiap tabel memerlukan rute terhubung dan hop berikutnya yang valid, ditambah tujuan yang akan ditanyakan kepadanya. Aturan yang menunjuk ke tabel yang tidak lengkap bukanlah rancangan jalur balik. Gunakan gateway yang didokumentasikan untuk NIC itu alih-alih mengarang gateway Ethernet dari tampilan subnet.
Langkah 4: periksa filter tamu sendiri
Periksa tempat server mendengarkan dan sumber lokal mana yang dibawa balasan. Pendengar pada semua alamat tidak mengesampingkan kebijakan perutean, jadi mengikat ke semua alamat tidak mengubah apa pun tentang antarmuka tempat jawaban keluar.
Di Linux, tinjau validasi jalur balik terhadap rancangan yang dimaksud. Menonaktifkannya secara global sebagai langkah pertama menukar bug perutean dengan paparan spoofing, dan menyembunyikan asimetri yang Anda coba temukan.
Langkah 5: uji satu aliran per jalur
Verifikasi permintaan cabang yang diizinkan dan permintaan internet yang tidak terkait secara terpisah, masing-masing dengan sumber dan tujuan sebenarnya. Tangkap pada kedua antarmuka bila bisa, karena bukti yang berguna adalah antarmuka mana yang membawa balasan. Lalu pastikan kebijakan di sisi cloud menghormati jalur yang Anda rancang. Satu permintaan yang berhasil membuktikan satu aliran, bukan rancangan simetris.
Pisahkan kedua pengujian dalam catatan Anda, karena keduanya menggunakan rute dan aturan firewall yang berbeda.
Apa yang tidak diberikan NIC kedua
Antarmuka kedua menambahkan lampiran jaringan dan alamat lain. Itu tidak menambahkan perutean simetris otomatis dan tidak melewati kebijakan firewall. Memperlakukannya sebagai perbaikan perutean adalah alasan rancangan multi-NIC menumpuk aturan yang tidak dapat dijelaskan siapa pun nanti.
Jika VM harus meneruskan lalu lintas mesin lain, rencanakan peran router itu secara eksplisit, termasuk pengaturan cloud yang mengizinkan penerusan dan filter tamu yang menyertainya.