Azure S2S VPN savienots, bet nav trafika: lasiet IKE žurnālu

Portāls saka Connected, tunelim ir darbības laika skaitītājs, un trace no jūsu virtuālās mašīnas mirst otrajā hopā. Savienojuma stāvoklis apraksta IKE un IPsec sarunas, nevis to, vai viens pakets izdzīvo politikas slāni jebkurā pusē. Divas kļūdas izskaidro lielāko daļu šo biļešu, un nevienu no tām neizlabo Azure maršruta maiņa. Abas jau ir ierakstītas žurnālā, ko izveidoja vārteja, tāpēc es sāku tur, nevis maršrutu tabulā.

Ko Connected patiešām apliecina

Savienots site-to-site savienojums nozīmē, ka 1. un 2. fāze ir pabeigtas un drošības asociācijas darbojas. Tas ir apgalvojums par sarunām: abas puses vienojās par priekšlikumu, apmainījās ar atslēgām un instalēja SA pāri. Tas neko nepasaka par to, vai trafika selektori atbilst apakštīkliem, kurus uzskatāt par aizsargātiem, un neko par to, vai tālā puse pēc atšifrēšanas paketu kaut kur maršrutēs. Tunelis var stāvēt nedēļām, izmetot katru interesanto plūsmu, un tieši šis modelis liek cilvēkiem pārbūvēt veselīgu vārteju.

Divas kļūdas, ko vērts pārbaudīt vispirms, ir peer, kas piedāvā AH ESP vietā, un virtuālais tīkls, kas numurēts telpā, kuru vārteja neuzskatīs par iekšēju.

Atveriet eksportēto žurnālu pirms maršrutu aizskaršanas

Portālā atveriet virtuālā tīkla vārteju un palaidiet VPN troubleshoot darbību savienojumam, pēc tam lejupielādējiet izveidoto pakotni un izpakojiet to. Iekšā ir IKE žurnāls ar 1. un 2. fāzes apmaiņām, ar laika zīmogiem un lasāms kā vienkāršs teksts. Meklējiet tajā transform rindu, nevis lasiet no augšas uz leju, jo interesantais ieraksts parasti atrodas dažus simtus rindu tālāk. Ja jums nav piekļuves portālam, tā pati diagnostika parādās vārtejas žurnāla galamērķī, kad diagnostikas iestatījumi ir iespējoti.

Divi ieraksti nes lielāko daļu vērtības. Pirmais skan aptuveni expected ESP with combined authentication and cipher, received AH. Otrais ir nederīga payload kļūda IKE apmaiņas laikā, kas parasti nozīmē nepareizi veidotu vai neatbalstītu priekšlikuma lauku.

Abi apraksta, ko piedāvāja vietējā ierīce, tāpēc abi ir peer puses iestatījumi. Azure puses atjaunošana nemaina priekšlikumu, ko sūta jūsu ugunsmūris, un to darīt tomēr ir visbiežāk izšķērdētā stunda šajā darbā. Uz peer iestatiet 2. fāzi uz ESP ar apvienotu autentifikāciju un šifru un ļaujiet tam vienoties par algoritmu, pēc tam pārbaudiet, vai combined mode nosaukuma piegādātāja izvēles rūtiņa klusi neizvēlas AH priekšlikumu zem tā.

Apstipriniet virtuālā tīkla adrešu telpu

Vārteja sagaida, ka virtuālais tīkls atradīsies privātos diapazonos. Tīkls, kas numurēts publiskā blokā, piemēram, sākas ar 111.x, var pacelt tuneli, kamēr Azure atsakās uzskatīt šo telpu par iekšēju, tāpēc savienojums izskatās veselīgs un neviena plūsma netiek pieņemta. Apstipriniet adrešu telpu, pirms veltāt pēcpusdienu selektoriem. Ja numerācija ir stingra prasība no vecāka sadalījuma, risinājums ir adrešu plāna maiņa, nevis cita vārteja.

Pierakstiet pārklāšanos ar vietējiem diapazoniem, kamēr esat adrešu telpas panelī, jo pārklājošies prefiksi rada cita veida kļūmi, kas no klienta puses izskatās līdzīgi.

Pārbaudiet prefiksus abos virzienos

Vietējā tīkla vārtejas resursā ir vietējie prefiksi, un tiem jāatbilst apakštīkliem, ko attālā ierīce patiešām aizsargā. Kopsavilkums, kas ietver adreses, kuras ierīce izmet, laidīs cauri dažas plūsmas un citās neizdosies, un tas lasās kā periodiska maršrutēšanas kļūme, nevis kā konfigurācijas neatbilstība. Pārbaudiet arī tālo pusi: viens gals uzskaita /16, bet otrs uzskaita trīs /24 tajā — tā ir klasiskā daļējā neveiksme. Neviens saraksts nav pats par sevi autoritatīvs, tāpēc salīdziniet tos blakus, nevis uzticieties tam, ko redzat.

Prefiksa izmaiņas ne vienmēr tiek uztvertas pašas no sevis, tāpēc plānojiet savienojuma objektu saglabāt vai izveidot no jauna un pēc tam apstipriniet, ka jaunie prefiksi parādās abās pusēs.

Pārbaudiet ceļu, nevis ping

Trace, kas atdala strādājošu tuneli no strādājoša maršruta, izskatās šādi: pirmais hop ir vietējā vārteja, tad daži hop, kas neatbild, tad atbild tālais host. Ja trace nekad nesasniedz host, pārbaudiet TCP portu, ko lietojumprogramma patiešām izmanto, jo ICMP tiek filtrēts pietiekami bieži, lai neizdevies ping pierādītu ļoti maz. Palaidiet to pašu trace no tālā hosta uz virtuālo mašīnu Azure. Asimetrija starp diviem rezultātiem ir ātrākais veids, kā atrast trūkstošu atgriešanās maršrutu vai noteikumu, kas atļauj tikai vienu virzienu.

Ierakstiet peer priekšlikumu, abas adrešu telpas un savienojuma izveides laiku biļetē, lai nākamais inženieris zinātu, kuras vērtības tika pārbūvētas un kuras nekad netika aizskartas.

Ja žurnāls atgriežas tukšs, iespējams, vārteja vispār nepabeidz jūsu savienojumu. Apstipriniet, ka vietējā tīkla vārtejas peer adrese atbilst ierīcei, no kuras lasāt žurnālu, jo divas vārtejas vienā abonementā pārbūves laikā ir viegli sajaukt. Šī kļūda maksā dienu un neatstāj pēdas nevienā žurnālā.