It portaal seit Connected, de tunnel hat in uptime-teller, en in trace fan jo firtuele masine stjert op 'e twadde hop. De ferbiningsstatus beskriuwt de IKE- en IPsec-ûnderhanneling, net oft ien pakket de beliedslaach oan beide kanten oerlibbet. Twa flaters ferklearje de measte fan dizze tickets, en gjinien fan beide wurdt reparearre troch in Azure-route te feroarjen. Beide steane al skreaun yn it log dat de gateway produsearre hat, dêrom begjin ik dêr en net yn 'e routetabel.

Wat Connected eins befêstiget

In ferbûne site-to-site-ferbining betsjut dat faze 1 en faze 2 foltôge binne en dat de befeiligingsassosjaasjes oan binne. Dat is in útspraak oer de ûnderhanneling: beide pearen waarden it iens oer in foarstel, wikselen kaaien út en ynstallearren it pear SA's. It seit neat oer oft de ferkearsselektearders oerienkomme mei de subnetten dy't jo befeilige achtsje, en neat oer oft de fiere kant it pakket nei it ûntsiferjen earne hinne routearret. In tunnel kin wiken oan bliuwe wylst er elke nijsgjirrige stream falle lit, en dat is krekt it patroan dat minsken in sûne gateway wer opbouwe lit.

De twa flaters dy't it earst neisjoen wurde moatte, binne in peer dy't AH ynstee fan ESP foarstelt, en in firtueel netwurk dat nûmere is yn in romte dy't de gateway net as yntern behannelje sil.

Iepenje it eksportearre log foardat jo routes oanreitsje

Iepenje yn it portaal de gateway fan it firtuele netwurk en fier de VPN troubleshoot-bewurking út op 'e ferbining, download dan it bondel dat it produsearret en pak it út. Binnenyn is in IKE-log mei de faze 1- en faze 2-útwikselings, mei tiidstimpels en lêsber as gewoane tekst. Sykje deryn nei de transform-rigel ynstee fan fan boppen nei ûnderen te lêzen, want de nijsgjirrige ynskriuwing stiet meastentiids in pear hûndert rigels fierder. As jo gjin portaaltafoldwaan hawwe, ferskine deselde diagnostyk yn 'e logbestimming fan 'e gateway as de diagnostikyndellingen oan steane.

Twa ynskriuwings drage it measte fan 'e wearde. De earste lêst sa'n bytsje expected ESP with combined authentication and cipher, received AH. De twadde is in ûnjildige-payload-flater tidens de IKE-útwikseling, wat meastentiids in ferkeard foarme of net stipe foarstelfjild betsjut.

Beide beskriuwe wat it lokale apparaat oanbean hat, dus beide binne ynstellingen oan 'e peer-kant. It Azure-kant fan 'e ferbining opnij generearje feroaret it foarstel net dat jo firewall stjoert, en it dochs dwaan is it meast ferspile oere yn dizze wurkstream. Set op 'e peer faze 2 op ESP mei kombinearre autentikaasje en sjifre en lit it it algoritme ûnderhannelje, kontrolearje dan oft in leveransierskontrôlefak mei in namme lykas combined mode stil in AH-foarstel dêrûnder selektearret.

Befêstigje de adresromte fan it firtuele netwurk

De gateway ferwachtet dat it firtuele netwurk yn privee berikken sit. In netwurk dat yn in iepenbiere blok nûmere is, bygelyks ien dy't mei 111.x begjint, kin de tunnel omheech bringe wylst Azure wegeret dy romte as yntern te behanneljen, sadat de ferbining sûn liket en gjin stream akseptearre wurdt. Befêstigje de adresromte foardat jo in middei oan selektearders besteegje. As de nûmering in hurde eask út in âldere tawizing is, is de oplossing in feroaring fan it adresplan en net in oare gateway.

Skriuw de oerlaap mei de lokale berikken op wylst jo yn 'e adresromteblêd binne, want oerlaapjende foarheaksels produsearje in oare flater dy't fan 'e klant ôf itselde liket.

Kontrolearje de foarheaksels yn beide rjochtingen

De boarne fan 'e lokale netwurkgateway hâldt de lokale foarheaksels, en se moatte oerienkomme mei de subnetten dy't it fiere apparaat echt befeiliget. In gearfetting dy't adressen befettet dy't it apparaat falle lit, sil guon streamen trochlitte en op oaren misse, wat lêst as in tuskenskoftige routflater ynstee fan in konfiguraasje-ôfwiking. Kontrolearje ek de fiere kant: ien ein dy't in /16 listet wylst de oare trije /24 deryn listet, is de klassike foar in part mislearring. Gjin fan beide listen is op himsels gesachhawwend, dus fergelykje se njonkeninoar ynstee fan te fertrouwen op dy't jo sjen kinne.

In foarheakselferoaring wurdt net altyd fansels oppakt, dus plan om it ferbiningsobjket opnij te bewarjen of te meitsjen en befêstigje dan dat de nije foarheaksels oan beide kanten ferskine.

Test in paad, gjin ping

De trace dy't in wurkjende tunnel fan in wurkjende route skiedt, sjocht der sa út: de earste hop is de lokale gateway, dan in pear hopen sûnder antwurd, dan antwurdet de fiere host. As de trace de host nea berikt, test dan de TCP-poarte dy't de applikaasje echt brûkt, want ICMP wurdt faak genôch filtere dat in mislearre ping heul lyts bewiist. Rin itselde trace fan in fiere host nei in firtuele masine yn Azure. Asymmetry tusken de twa resultaten is de fluchste manier om in ûntbrekkende weromroute of in regel te finen dy't mar ien rjochting tastiet.

Skriuw it foarstel fan 'e peer, beide adresromten en de oanmaaktiid fan 'e ferbining yn 'e ticket, sadat de folgjende yngenieur wit hokker wearden opnij boud binne en hokker nea oanreitsje binne.

As it log leech weromkomt, is it mooglik dat de gateway jo ferbining hielendal net beëiniget. Befêstigje dat it peeradres op 'e lokale netwurkgateway oerienkomt mei it apparaat dêr't jo it log fan lêze, want twa gateways yn ien abonnemint wurde by in weropbou maklik betize. Dy flater kostet in dei en lit gjin spoar yn hokker log dan ek efter.

Relatearre artikelen