Azure S2S VPN konektita sed sen trafiko: legu la IKE-protokolon

La portalo diras Connected, la tunelo havas tempomezuradon, kaj trace de via virtuala maŝino mortas ĉe la dua hop. La konekta stato priskribas la interkonsenton IKE kaj IPsec, ne ĉu unu pako postvivas la politikan tavolon ĉe ajna flanko. Du fuŝoj klarigas plej multajn el tiuj ĉi biletoj, kaj neniu el ili ripariĝas per ŝanĝo de Azure-itinero. Ambaŭ jam estas skribitaj en la protokolo, kiun la pordego produktis, kaj tial mi komencas tie anstataŭ en la itinera tabelo.

Kion Connected efektive atestas

Konektita site-to-site konekto signifas, ke fazo 1 kaj fazo 2 finiĝis kaj la sekurecaj asocioj estas aktivaj. Tio estas aserto pri la interkonsento: ambaŭ partneroj konsentis pri propono, interŝanĝis ŝlosilojn kaj instalis la paron da SA. Ĝi diras nenion pri tio, ĉu la trafikaj selektiloj kongruas kun la subretoj, kiujn vi kredas protektitaj, nek pri tio, ĉu la malproksima flanko ien ajn enkursigos la pakon post malĉifrado. Tunelo povas resti aktiva dum semajnoj dum ĝi forĵetas ĉiun interesan fluon, kaj tio estas ĝuste la ŝablono, kiu igas homojn rekonstrui sanan pordegon.

La du fuŝoj, kiujn indas kontroli unue, estas partnero proponanta AH anstataŭ ESP, kaj virtuala reto numerita en spaco, kiun la pordego ne traktos kiel internan.

Malfermu la eksportitan protokolon antaŭ ol tuŝi itinerojn

En la portalo malfermu la pordegon de la virtuala reto kaj rulu la operacion VPN troubleshoot kontraŭ la konekto, poste elŝutu la pakaĵon, kiun ĝi produktas, kaj malpaku ĝin. Ene estas IKE-protokolo kun la interŝanĝoj de fazo 1 kaj fazo 2, kun tempaj markoj kaj legebla kiel simpla teksto. Serĉu en ĝi la linion transform anstataŭ legi de supre malsupren, ĉar la interesa ero kutime estas kelkcent liniojn pli profunde. Se vi ne havas aliron al la portalo, la samaj diagnozaĵoj aperas en la protokola celo de la pordego, kiam la diagnozaj agordoj estas ŝaltitaj.

Du eroj portas la plej grandan parton de la valoro. La unua tekstas proksimume expected ESP with combined authentication and cipher, received AH. La dua estas eraro pri nevalida payload dum la IKE-interŝanĝo, kio kutime signifas mise strukturitan aŭ ne subtenatan proponan kampon.

Ambaŭ priskribas, kion proponis la loka aparato, do ambaŭ estas agordoj ĉe la partnera flanko. Regeneri la Azure-flankon de la konekto ne ŝanĝas la proponon, kiun via fajroŝirmilo sendas, kaj fari tion malgraŭe estas la plej ofte malŝparita horo en tiu ĉi laborfluo. Ĉe la partnero agordu fazon 2 al ESP kun kombinita aŭtentigo kaj ĉifro kaj lasu ĝin interkonsenti la algoritmon, poste kontrolu, ĉu markobutono de vendisto nomita io kiel combined mode silente elektas AH-proponon sube.

Konfirmu la adresspacon de la virtuala reto

La pordego atendas, ke la virtuala reto troviĝu en privataj gamoj. Reto numerita en publika bloko, ekzemple tiu komenciĝanta per 111.x, povas levigi la tunelon dum Azure rifuzas trakti tiun spacon kiel internan, do la konekto aspektas sana kaj neniu fluo estas akceptata. Konfirmu la adresspacon antaŭ ol pasigi posttagmezon pri selektiloj. Se la numerado estas malmola postulo el pli malnova atribuo, la ripeto estas ŝanĝo de la adresa plano, ne alia pordego.

Notu la koincidon kun la lokaj gamoj dum vi estas en la adresspaca panelo, ĉar koincidantaj prefiksoj produktas alian fiaskon, kiu el la klienta flanko aspektas simila.

Kontrolu la prefiksojn en ambaŭ direktoj

La risurco de la loka retpordego tenas la lokajn prefiksojn, kaj ili devas kongrui kun la subretoj, kiujn la malproksima aparato efektive protektas. Resumo, kiu inkluzivas adresojn, kiujn la aparato forĵetas, pasigos kelkajn fluojn kaj malsukcesos ĉe aliaj, kio legeblas kiel intermita itinera fuŝo anstataŭ kiel malkongruo de agordo. Kontrolu ankaŭ la malproksiman flankon: unu finaĵo listiganta /16 dum la alia listigas tri /24 ene de ĝi estas la klasika parta fiasko. Neniu listo estas aŭtoritata sola, do komparu ilin flanko ĉe flanko anstataŭ fidi tiun, kiun vi vidas.

Ŝanĝo de prefikso ne ĉiam estas kaptata memstare, do planu resavi aŭ rekrei la konektan objekton kaj poste konfirmu, ke la novaj prefiksoj aperas ĉe ambaŭ flankoj.

Testu vojon, ne ping

La trace, kiu apartigas funkciantan tunelon de funkcianta itinero, aspektas tiel: la unua hop estas la loka pordego, poste kelkaj nerespondaj hop, poste la malproksima gastiganto respondas. Se la trace neniam atingas la gastiganton, testu la TCP-pordon, kiun la aplikaĵo efektive uzas, ĉar ICMP estas filtrita sufiĉe ofte por ke malsukcesa ping pruvu tre malmulte. Rulu la saman trace de malproksima gastiganto al virtuala maŝino en Azure. Malsimetrio inter la du rezultoj estas la plej rapida vojo por trovi mankan revenan itineron aŭ regulon, kiu permesas nur unu direkton.

Skribu la proponon de la partnero, ambaŭ adresspacojn kaj la kreadtempon de la konekto en la bileton, por ke la sekva inĝeniero sciu, kiuj valoroj estis rekonstruitaj kaj kiuj neniam tuŝitaj.

Se la protokolo revenas malplena, eble la pordego tute ne finas vian konekton. Konfirmu, ke la partnera adreso en la loka retpordego kongruas kun la aparato, de kiu vi legas la protokolon, ĉar du pordegoj en unu abono facile konfuziĝas dum rekonstruo. Tiu eraro kostas tagon kaj lasas neniun spuron en ajna protokolo.