Architecture-center: Memperjelas penggunaan 'Izinkan lalu lintas yang diteruskan'

Dibuat pada 11 Des 2018  ·  6Komentar  ·  Sumber: MicrosoftDocs/architecture-center

Di bagian Peering VNet, dokumen menyatakan:

Anda juga dapat mengonfigurasi jari-jari untuk menggunakan gateway hub VNet untuk berkomunikasi dengan jaringan jarak jauh. Untuk mengizinkan lalu lintas gateway mengalir dari spoke ke hub, dan menyambung ke jaringan jarak jauh, Anda harus:

  • Konfigurasikan koneksi peering VNet di hub untuk mengizinkan transit gateway.
  • Konfigurasikan koneksi peering VNet di setiap jari-jari untuk menggunakan gateway jarak jauh.
  • Konfigurasikan semua koneksi peering VNet untuk mengizinkan lalu lintas yang diteruskan.

Peluru ketiga salah. 'Izinkan lalu lintas yang diteruskan' tidak diperlukan untuk mengalihkan lalu lintas melalui gateway VPN (saya baru saja mencobanya).

Saya percaya 'Izinkan lalu lintas yang diteruskan' hanya diperlukan dalam skenario yang dijelaskan dalam paragraf sebelumnya, di mana lalu lintas dirutekan melalui NVA dalam arsitektur hub-spoke.

Dokumen harus diklarifikasi untuk menjelaskan penggunaan 'izinkan lalu lintas yang diteruskan' dengan benar di setiap skenario.


Detail Dokumen

Jangan edit bagian ini.

Pri1 assigned-to-author doc-enhancement guidancsvc triaged

Komentar yang paling membantu

terima kasih telah berbagi umpan balik ini @jtuliani dan @evandropomatti , kami sangat menghargai ini

Saya pikir ini mengacu pada bagian Peering Jaringan Virtual di bawah Rekomendasi di mana berdasarkan pemahaman saya, dua skenario berbeda sedang dibahas.

Skenario A

Jika Anda memerlukan jari-jari untuk terhubung satu sama lain tanpa mengintipnya.

Untuk skenario kasus ini, izinkan kami membagikan dari Buat dokumen

_"Jika kotak centang ini tidak dicentang untuk peering antara setiap jaringan virtual jari-jari dan jaringan virtual hub, lalu lintas tidak mengalir di antara jaringan virtual jari-jari karena hub tidak meneruskan lalu lintas antara jaringan virtual."_

Selain itu,

_"Anda tidak perlu memeriksa pengaturan ini jika lalu lintas diteruskan antara jaringan virtual melalui Gateway VPN Azure."_

Skenario B

Konfigurasikan jari-jari untuk menggunakan gateway hub untuk berkomunikasi dengan jaringan jarak jauh. Untuk konfigurasi yang sangat khusus ini, Izinkan lalu lintas yang diteruskan tidak diperlukan.

Karena itu, izinkan kami membuka kembali masalah ini karena saya setuju saat membaca dokumen bahwa ini adalah ide yang baik untuk membuat perbedaan di sini.

Sebagai bagian dari revisi ini, mohon pertimbangkan juga untuk menunjukkan peering mana yang benar-benar diperlukan (yaitu Skenario B, [x] Use remote gateways diperlukan dari peering spoke-hub, sedangkan [x] Allow gateway transit diperlukan dari hub -spoke peering, dan [] Allow forwarded traffic dapat tetap tidak dicentang untuk keduanya) asalkan itu adalah preferensi penulis. Pandangan berdampingan ini mungkin ideal.

Sebagai kesimpulan dan dalam semua keadilan, konfigurasi saat ini akan bekerja dengan baik untuk kedua skenario A + B, sehingga mereka tidak saling bertentangan. Mengingat itu, demi kesederhanaan, kami mungkin ingin mempertahankan ARM apa adanya untuk saat ini.

Semua 6 komentar

Hai @jtuliani Terima kasih telah melaporkan masalah ini! Kami akan meninjau dan membuat perubahan yang diperlukan.

+1, saya juga akan menambahkan bahwa kita harus mencatat bahwa ketika mengaktifkan lalu lintas yang diteruskan di VNet, pengguna perlu mempertimbangkan bahwa NIC Azure juga harus mengaktifkan penerusan (kita cukup menautkan ke sini ).

Saya menghabiskan banyak waktu untuk mencari tahu mengapa VM Linux saya tidak dapat menjangkau satu sama lain di VNet yang di-peering mengikuti panduan ini sampai saya menyadari ada pengaturan tambahan pada NIC untuk diaktifkan juga.

Terima kasih banyak - item ini telah dipindahkan ke backlog internal kami untuk penyempurnaan dokumentasi.

@doodlemania2 dokumentasi masih menyatakan bahwa "izinkan lalu lintas yang diteruskan" diperlukan. Dilihat oleh pengujian @jtuliani seharusnya tidak, dan dokumentasinya harus diubah.

Di sini Anda menjawab bahwa itu diperlukan:
https://github.com/MicrosoftDocs/architecture-center/issues/1544#issuecomment -506504344

Ini adalah pertanyaan yang bagus! Kami melakukan itu agar rekan-rekan dapat berbicara satu sama lain dengan cara perutean melalui hub. Tanpa itu, paket-paket akan jatuh saat mereka mencoba untuk keluar dari spoke yang ditujukan untuk hub dan sebaliknya. Beri tahu kami jika itu masih tidak menjelaskannya dengan baik dan kami dapat melihat ulang kata-katanya!

Apakah itu benar-benar diperlukan dan tesnya agak salah? Atau dokumentasi perlu diperbarui?

Anda juga dapat mengonfigurasi jari-jari untuk menggunakan gateway hub untuk berkomunikasi dengan jaringan jarak jauh. Untuk mengizinkan lalu lintas gateway mengalir dari spoke ke hub, dan menyambung ke jaringan jarak jauh, Anda harus:

  • Konfigurasikan koneksi peering di hub untuk mengizinkan transit gateway .
  • Konfigurasikan koneksi peering di setiap jari-jari untuk menggunakan gateway jarak jauh .
  • Konfigurasikan semua koneksi peering untuk mengizinkan lalu lintas yang diteruskan .

Saya juga menyarankan agar kami tidak menutup masalah di sini sampai selesai. Proses internal tidak masalah bagi masyarakat, jika tidak kita hanya mengalami situasi seperti ini.

terima kasih telah berbagi umpan balik ini @jtuliani dan @evandropomatti , kami sangat menghargai ini

Saya pikir ini mengacu pada bagian Peering Jaringan Virtual di bawah Rekomendasi di mana berdasarkan pemahaman saya, dua skenario berbeda sedang dibahas.

Skenario A

Jika Anda memerlukan jari-jari untuk terhubung satu sama lain tanpa mengintipnya.

Untuk skenario kasus ini, izinkan kami membagikan dari Buat dokumen

_"Jika kotak centang ini tidak dicentang untuk peering antara setiap jaringan virtual jari-jari dan jaringan virtual hub, lalu lintas tidak mengalir di antara jaringan virtual jari-jari karena hub tidak meneruskan lalu lintas antara jaringan virtual."_

Selain itu,

_"Anda tidak perlu memeriksa pengaturan ini jika lalu lintas diteruskan antara jaringan virtual melalui Gateway VPN Azure."_

Skenario B

Konfigurasikan jari-jari untuk menggunakan gateway hub untuk berkomunikasi dengan jaringan jarak jauh. Untuk konfigurasi yang sangat khusus ini, Izinkan lalu lintas yang diteruskan tidak diperlukan.

Karena itu, izinkan kami membuka kembali masalah ini karena saya setuju saat membaca dokumen bahwa ini adalah ide yang baik untuk membuat perbedaan di sini.

Sebagai bagian dari revisi ini, mohon pertimbangkan juga untuk menunjukkan peering mana yang benar-benar diperlukan (yaitu Skenario B, [x] Use remote gateways diperlukan dari peering spoke-hub, sedangkan [x] Allow gateway transit diperlukan dari hub -spoke peering, dan [] Allow forwarded traffic dapat tetap tidak dicentang untuk keduanya) asalkan itu adalah preferensi penulis. Pandangan berdampingan ini mungkin ideal.

Sebagai kesimpulan dan dalam semua keadilan, konfigurasi saat ini akan bekerja dengan baik untuk kedua skenario A + B, sehingga mereka tidak saling bertentangan. Mengingat itu, demi kesederhanaan, kami mungkin ingin mempertahankan ARM apa adanya untuk saat ini.

@ferantivero Saya pikir Anda berhasil dan kami dapat menyelesaikan masalah ini sekarang.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat