Azure S2S VPN yhdistetty mutta liikennettä ei kulje: lue IKE-loki

Portaali sanoo Connected, tunnelilla on käyttöaikalaskuri ja virtuaalikoneestasi otettu trace kuolee toisella hopilla. Yhteyden tila kuvaa IKE- ja IPsec-neuvottelua, ei sitä, selviääkö yksikään paketti käytäntökerroksen läpi kummallakaan puolella. Kaksi vikaa selittää useimmat näistä tiketeistä, eikä kumpaakaan korjata Azure-reittiä muuttamalla. Molemmat on jo kirjoitettu lokiin, jonka yhdyskäytävä tuotti, siksi aloitan sieltä enkä reititystaulusta.

Mitä Connected todella todistaa

Yhdistetty site-to-site-yhteys tarkoittaa, että vaihe 1 ja vaihe 2 on saatu valmiiksi ja tietoturvayhteydet ovat pystyssä. Se on väite neuvottelusta: molemmat osapuolet sopivat ehdotuksesta, vaihtoivat avaimet ja asensivat SA-parin. Se ei kerro mitään siitä, vastaavatko liikenteen valitsimet aliverkkoja, joiden uskot olevan suojattuja, eikä siitä, reitittääkö vastapuoli paketin jonnekin salauksen purkamisen jälkeen. Tunneli voi pysyä pystyssä viikkoja pudottaen samalla jokaisen kiinnostavan virtauksen, ja juuri tämä kuvio saa ihmiset rakentamaan terveen yhdyskäytävän uudelleen.

Kaksi ensimmäisenä tarkistettavaa vikaa ovat peer, joka ehdottaa ESP:n sijaan AH:ta, ja virtuaaliverkko, joka on numeroitu avaruuteen, jota yhdyskäytävä ei kohtele sisäisenä.

Avaa viety loki ennen kuin kosket reitteihin

Avaa portaalissa virtuaaliverkon yhdyskäytävä ja suorita VPN troubleshoot -toiminto yhteydelle, lataa sitten sen tuottama paketti ja pura se. Sisällä on IKE-loki vaiheiden 1 ja 2 vaihdoista, aikaleimoilla ja luettavana pelkkänä tekstinä. Etsi siitä transform-rivi sen sijaan että lukisit ylhäältä alas, sillä kiinnostava merkintä on yleensä joitakin satoja rivejä alempana. Jos sinulla ei ole portaaliin pääsyä, samat diagnostiikkatiedot ilmestyvät yhdyskäytävän lokikohteeseen, kun diagnostiikka-asetukset on otettu käyttöön.

Kaksi merkintää kantaa suurimman osan arvosta. Ensimmäinen kuuluu suunnilleen expected ESP with combined authentication and cipher, received AH. Toinen on virheellisen payloadin virhe IKE-vaihdon aikana, mikä tarkoittaa yleensä väärin muotoiltua tai tukematonta ehdotuskenttää.

Molemmat kuvaavat, mitä paikallinen laite tarjosi, joten molemmat ovat peer-puolen asetuksia. Yhteyden Azure-puolen uudelleenluonti ei muuta sitä ehdotusta, jonka palomuurisi lähettää, ja sen tekeminen silti on tämän työnkulun yleisin hukattu tunti. Aseta peerillä vaihe 2 ESP:hen yhdistetyllä todennuksella ja salauksella ja anna sen neuvotella algoritmi, tarkista sitten valitseeko combined mode -niminen toimittajan valintaruutu hiljaa alleen AH-ehdotuksen.

Vahvista virtuaaliverkon osoiteavaruus

Yhdyskäytävä odottaa virtuaaliverkon olevan yksityisissä alueissa. Julkiseen lohkoon numeroitu verkko, esimerkiksi 111.x:llä alkava, voi nostaa tunnelin pystyyn, kun taas Azure kieltäytyy kohtelemasta sitä avaruutta sisäisenä, joten yhteys näyttää terveeltä eikä yhtään virtausta hyväksytä. Vahvista osoiteavaruus ennen kuin vietät iltapäivän valitsimien parissa. Jos numerointi on vanhasta jaosta peräisin oleva kova vaatimus, korjaus on osoitesuunnitelman muutos eikä toinen yhdyskäytävä.

Kirjaa päällekkäisyys paikallisten alueiden kanssa, kun olet osoiteavaruuden lehdellä, sillä päällekkäiset etuliitteet tuottavat erilaisen vian, joka näyttää asiakkaan puolelta samankaltaiselta.

Tarkista etuliitteet molempiin suuntiin

Paikallisen verkon yhdyskäytäväresurssi pitää sisällään paikalliset etuliitteet, ja niiden on vastattava aliverkkoja, joita etälaite todella suojaa. Yhteenveto, joka sisältää osoitteita, jotka laite pudottaa, päästää läpi jotkin virtaukset ja epäonnistuu toisissa, mikä luetaan ajoittaisena reititysvikana eikä kokoonpanon ristiriitana. Tarkista myös vastapuoli: toinen pää listaa /16, kun toinen listaa kolme /24 sen sisällä — se on klassinen osittainen epäonnistuminen. Kumpikaan lista ei ole yksinään ratkaiseva, joten vertaa niitä rinnakkain sen sijaan että luottaisit siihen, jonka näet.

Etuliitteen muutos ei aina tartu itsestään, joten varaudu tallentamaan tai luomaan yhteysolio uudelleen ja vahvista sitten, että uudet etuliitteet näkyvät molemmilla puolilla.

Testaa polkua, älä pingiä

Trace, joka erottaa toimivan tunnelin toimivasta reitistä, näyttää tältä: ensimmäinen hop on paikallinen yhdyskäytävä, sitten muutama vastaamaton hop, sitten etäisäntä vastaa. Jos trace ei koskaan saavuta isäntää, testaa TCP-portti, jota sovellus todella käyttää, sillä ICMP:tä suodatetaan tarpeeksi usein, että epäonnistunut ping todistaa hyvin vähän. Aja sama trace etäisännästä Azure-virtuaalikoneeseen. Kahden tuloksen epäsymmetria on nopein tapa löytää puuttuva paluureitti tai sääntö, joka sallii vain yhden suunnan.

Kirjoita peerin ehdotus, molemmat osoiteavaruudet ja yhteyden luontiaika tikettiin, jotta seuraava insinööri tietää, mitkä arvot rakennettiin uudelleen ja mihin ei koskaan koskettu.

Jos loki palaa tyhjänä, yhdyskäytävä ei ehkä lopeta yhteyttäsi lainkaan. Vahvista, että paikallisen verkon yhdyskäytävän peer-osoite vastaa laitetta, josta luet lokia, sillä kaksi yhdyskäytävää yhdessä tilauksessa sekoittuvat helposti uudelleenrakennuksen aikana. Se virhe maksaa päivän eikä jätä jälkeä mihinkään lokiin.