S2S VPN sa Azure konektado ngunit walang trapiko: basahin ang IKE log

Sinasabi ng portal na Connected, may counter ng uptime ang tunnel, at namamatay ang trace mula sa iyong virtual machine sa ikalawang hop. Inilalarawan ng estado ng koneksyon ang negosasyon ng IKE at IPsec, hindi kung may isang packet na nakakalampas sa patong ng patakaran sa alinmang panig. Dalawang sira ang nagpapaliwanag sa karamihan ng mga ticket na ito, at wala sa dalawa ang naaayos sa pagpalit ng ruta sa Azure. Nakasulat na ang dalawa sa log na ginawa ng gateway, kaya doon ako nagsisimula at hindi sa talahanayan ng ruta.

Ano ang talagang pinatutunayan ng Connected

Ang konektadong site-to-site na koneksyon ay nangangahulugang natapos ang yugto 1 at yugto 2 at aktibo ang mga asosasyon ng seguridad. Isa itong pahayag tungkol sa negosasyon: nagkasundo ang dalawang peer sa isang panukala, nagpalitan ng mga susi at nag-install ng pares ng SA. Wala itong sinasabi kung tugma ang mga tagapili ng trapiko sa mga subnet na inaakala mong protektado, at wala rin kung iruruta ng kabilang panig ang packet kahit saan pagkatapos nitong i-decrypt. Maaaring manatiling aktibo ang tunnel nang ilang linggo habang itinatapon ang bawat kawili-wiling daloy, at iyon mismo ang pattern na nag-uudyok sa mga tao na muling itayo ang isang malusog na gateway.

Ang dalawang sirang dapat unang tiyakin ay peer na nagmumungkahi ng AH sa halip na ESP, at virtual network na binilangan sa espasyong hindi ituturing ng gateway na panloob.

Buksan ang na-export na log bago hawakan ang mga ruta

Sa portal, buksan ang gateway ng virtual network at patakbuhin ang operasyong VPN troubleshoot sa koneksyon, pagkatapos i-download ang bundle na ginagawa nito at i-extract. Sa loob ay may IKE log na may mga palitan ng yugto 1 at yugto 2, may mga timestamp at nababasang parang plain text. Hanapin dito ang linyang transform sa halip na basahin mula itaas pababa, dahil ang kawili-wiling entry ay karaniwang ilang daang linya ang lalim. Kung wala kang access sa portal, lumalabas ang parehong diagnostics sa destinasyon ng log ng gateway kapag naka-enable ang mga diagnostic setting.

Dalawang entry ang nagdadala ng malaking bahagi ng halaga. Ang una ay mababasang tulad ng expected ESP with combined authentication and cipher, received AH. Ang pangalawa ay error sa invalid payload habang nagpapalitan ng IKE, na karaniwang nangangahulugang mali ang pagkakabuo o hindi suportadong field ng panukala.

Parehong inilalarawan nila ang inialok ng on-premises na aparato, kaya pareho silang setting sa panig ng peer. Ang muling pagbuo ng panig Azure ng koneksyon ay hindi nagbabago sa panukalang ipinapadala ng iyong firewall, at ang gawin pa rin iyon ang pinakasayang oras sa gawaing ito. Sa peer, itakda ang yugto 2 sa ESP na may pinagsamang authentication at cipher at hayaang makipagnegosasyon ito sa algorithm, pagkatapos tingnan kung may checkbox ng vendor na may pangalang parang combined mode na tahimik na pumipili ng panukalang AH sa ilalim.

Tiyakin ang espasyo ng address ng virtual network

Inaasahan ng gateway na nasa pribadong saklaw ang virtual network. Ang network na binilangan sa pampublikong bloke, halimbawa ang nagsisimula sa 111.x, ay maaaring magpaangat ng tunnel habang tumatanggi ang Azure na ituring ang espasyong iyon na panloob, kaya mukhang malusog ang koneksyon at walang daloy na tinatanggap. Tiyakin ang espasyo ng address bago magpalipas ng hapon sa mga tagapili. Kung ang pagbilang ay matigas na pangangailangan mula sa lumang alokasyon, ang pagwawasto ay pagbabago ng plano ng address at hindi ibang gateway.

Itala ang pagpapatong sa mga saklaw ng on-premises habang nasa blade ng espasyo ng address, dahil ang mga nagpapatong na prefix ay gumagawa ng ibang pagkasira na mukhang pareho mula sa client.

Tiyakin ang mga prefix sa dalawang direksyon

Ang resource ng gateway ng lokal na network ay may mga prefix ng on-premises, at kailangan nilang tumugma sa mga subnet na aktwal na pinoprotektahan ng remote na aparato. Ang buod na may kasamang mga address na itinatapon ng aparato ay magpapalusot sa ilang daloy at mabibigo sa iba, na nababasang parang paminsan-minsang sira sa routing at hindi parang hindi tugmang configuration. Tingnan din ang kabilang panig: isang dulo na naglilista ng /16 habang ang isa ay naglilista ng tatlong /24 sa loob nito — iyon ang klasikong bahagyang pagkasira. Walang listahan ang awtoritatibo nang mag-isa, kaya ihambing ang dalawa nang magkatabi sa halip na magtiwala sa nakikita mo.

Ang pagbabago ng prefix ay hindi laging kusang nakukuha, kaya planuhin ang muling pag-save o muling paggawa ng object ng koneksyon at pagkatapos tiyakin na lumalabas ang mga bagong prefix sa dalawang panig.

Subukan ang isang landas, hindi ping

Ang trace na naghihiwalay sa gumaganang tunnel mula sa gumaganang ruta ay ganito: ang unang hop ay ang on-premises na gateway, pagkatapos ay ilang hop na hindi tumutugon, pagkatapos ay sumasagot ang remote na host. Kung hindi umaabot ang trace sa host, subukan ang TCP port na aktwal na ginagamit ng aplikasyon, dahil ang ICMP ay sinala nang sapat na madalas para ang bigong ping ay kakaunti ang mapatunayan. Patakbuhin ang parehong trace mula sa remote na host patungo sa virtual machine sa Azure. Ang asimetriya sa dalawang resulta ang pinakamabilis na paraan upang mahanap ang nawawalang ruta ng pagbabalik o ang patakarang nagpapahintulot lamang ng isang direksyon.

Isulat ang panukala ng peer, ang dalawang espasyo ng address at ang oras ng paggawa ng koneksyon sa ticket, upang malaman ng susunod na inhinyero kung aling mga halaga ang itinayong muli at alin ang hindi kailanman hinawakan.

Kung babalik na walang laman ang log, maaaring hindi talaga tinatapos ng gateway ang iyong koneksyon. Tiyakin na tugma ang peer address sa gateway ng lokal na network sa aparatong pinagbabasahan mo ng log, dahil ang dalawang gateway sa isang subscription ay madaling mapagkamalan sa panahon ng muling pagbuo. Ang pagkakamaling iyon ay tumatagal ng isang araw at walang bakas na iniiwan sa anumang log.