VPN S2S Azure bersambung tetapi tiada trafik: baca log IKE

Portal menulis Connected, terowong mempunyai pembilang masa beroperasi, dan trace dari mesin maya anda mati pada hop kedua. Keadaan sambungan menerangkan rundingan IKE dan IPsec, bukan sama ada satu paket pun melepasi lapisan dasar di mana-mana pihak. Dua kesalahan menjelaskan kebanyakan tiket ini, dan kedua-duanya tidak diperbaiki dengan menukar laluan Azure. Kedua-duanya sudah tertulis dalam log yang dihasilkan oleh gerbang, sebab itu saya bermula di sana dan bukan dalam jadual laluan.

Apa yang sebenarnya diperakui oleh Connected

Sambungan site-to-site yang bersambung bermaksud fasa 1 dan fasa 2 telah selesai dan persatuan keselamatan aktif. Itu adalah pernyataan tentang rundingan: kedua-dua rakan sebaya bersetuju dengan cadangan, bertukar kunci dan memasang pasangan SA. Ia tidak menyatakan apa-apa tentang sama ada pemilih trafik sepadan dengan subrangkaian yang anda anggap terlindung, dan tidak juga sama ada pihak jauh akan menghalakan paket ke mana-mana selepas menyahsulitnya. Terowong boleh kekal beroperasi selama berminggu-minggu sambil membuang setiap aliran yang menarik, dan itulah corak yang membuat orang membina semula gerbang yang sihat.

Dua kesalahan yang wajar diperiksa dahulu ialah rakan sebaya yang mencadangkan AH dan bukannya ESP, dan rangkaian maya yang dinomborkan dalam ruang yang tidak akan dianggap dalaman oleh gerbang.

Buka log yang dieksport sebelum menyentuh laluan

Dalam portal, buka gerbang rangkaian maya dan jalankan operasi VPN troubleshoot pada sambungan, kemudian muat turun berkas yang dihasilkannya dan nyahmampatkannya. Di dalamnya ada log IKE dengan pertukaran fasa 1 dan fasa 2, bertanda masa dan boleh dibaca sebagai teks biasa. Cari baris transform di dalamnya dan bukan membaca dari atas ke bawah, kerana entri yang menarik biasanya beberapa ratus baris ke dalam. Jika anda tiada akses portal, diagnostik yang sama muncul di destinasi log gerbang apabila tetapan diagnostik didayakan.

Dua entri membawa sebahagian besar nilainya. Yang pertama berbunyi lebih kurang expected ESP with combined authentication and cipher, received AH. Yang kedua ialah ralat payload tidak sah semasa pertukaran IKE, yang biasanya bermaksud medan cadangan yang salah bentuk atau tidak disokong.

Kedua-duanya menerangkan apa yang ditawarkan oleh peranti di premis, jadi kedua-duanya tetapan di pihak rakan sebaya. Menjana semula pihak Azure sambungan tidak mengubah cadangan yang dihantar oleh firewall anda, dan melakukannya juga merupakan jam yang paling kerap terbuang dalam aliran kerja ini. Pada rakan sebaya, tetapkan fasa 2 kepada ESP dengan pengesahan dan sifer gabungan dan biarkan ia merundingkan algoritma, kemudian periksa sama ada kotak semak vendor dengan nama seperti combined mode secara senyap memilih cadangan AH di bawahnya.

Sahkan ruang alamat rangkaian maya

Gerbang menjangka rangkaian maya berada dalam julat persendirian. Rangkaian yang dinomborkan dalam blok awam, contohnya yang bermula dengan 111.x, boleh menaikkan terowong sementara Azure enggan menganggap ruang itu sebagai dalaman, jadi sambungan kelihatan sihat dan tiada aliran diterima. Sahkan ruang alamat sebelum anda menghabiskan sebelah petang dengan pemilih. Jika penomboran itu keperluan keras daripada peruntukan lama, pembaikannya ialah perubahan pelan alamat dan bukan gerbang lain.

Catat pertindihan dengan julat di premis semasa anda berada dalam bilah ruang alamat, kerana awalan yang bertindih menghasilkan kegagalan berbeza yang kelihatan serupa dari pihak klien.

Sahkan awalan dalam kedua-dua arah

Sumber gerbang rangkaian setempat menyimpan awalan di premis, dan ia mesti sepadan dengan subrangkaian yang benar-benar dilindungi oleh peranti jauh. Ringkasan yang merangkumi alamat yang dibuang oleh peranti akan meloloskan sesetengah aliran dan gagal pada yang lain, yang terbaca sebagai kegagalan penghalaan berselang-seli dan bukan sebagai ketakpadanan konfigurasi. Periksa juga pihak jauh: satu hujung menyenaraikan /16 manakala yang lain menyenaraikan tiga /24 di dalamnya — itulah kegagalan separa klasik. Tiada senarai yang berwibawa dengan sendirinya, jadi bandingkan kedua-duanya bersebelahan dan bukannya mempercayai yang anda boleh lihat.

Perubahan awalan tidak selalu diambil dengan sendirinya, jadi rancang untuk menyimpan semula atau mencipta semula objek sambungan dan kemudian sahkan awalan baharu muncul pada kedua-dua pihak.

Uji laluan, bukan ping

Trace yang memisahkan terowong yang berfungsi daripada laluan yang berfungsi kelihatan seperti ini: hop pertama ialah gerbang di premis, kemudian beberapa hop yang tidak menjawab, kemudian hos jauh menjawab. Jika trace tidak pernah sampai ke hos, uji port TCP yang benar-benar digunakan oleh aplikasi, kerana ICMP ditapis cukup kerap sehingga ping yang gagal membuktikan sangat sedikit. Jalankan trace yang sama dari hos jauh menuju mesin maya di Azure. Asimetri antara kedua-dua keputusan ialah cara terpantas untuk mencari laluan balik yang hilang atau peraturan yang hanya membenarkan satu arah.

Tulis cadangan rakan sebaya, kedua-dua ruang alamat dan masa penciptaan sambungan ke dalam tiket, supaya jurutera seterusnya tahu nilai mana yang dibina semula dan mana yang tidak pernah disentuh.

Jika log kembali kosong, gerbang mungkin tidak menamatkan sambungan anda langsung. Sahkan bahawa alamat rakan sebaya pada gerbang rangkaian setempat sepadan dengan peranti yang anda gunakan untuk membaca log, kerana dua gerbang dalam satu langganan mudah dikelirukan semasa pembinaan semula. Kesilapan itu mengambil masa sehari dan tidak meninggalkan kesan dalam mana-mana log.