VPN S2S në Azure i lidhur por pa trafik: lexoni regjistrin IKE

Portali thotë Connected, tuneli ka një numërues të kohës së funksionimit, dhe një trace nga makina juaj virtuale vdes në hopin e dytë. Gjendja e lidhjes përshkruan negociatën IKE dhe IPsec, jo nëse një paketë e vetme i mbijeton shtresës së politikave në cilëndo anë. Dy defekte shpjegojnë shumicën e këtyre tiketave dhe asnjëri prej tyre nuk rregullohet duke ndryshuar një rrugë në Azure. Të dyja janë shkruar tashmë në regjistrin që prodhoi porta, prandaj filloj atje dhe jo në tabelën e rrugëve.

Çfarë vërteton vërtet Connected

Një lidhje site-to-site e lidhur do të thotë që faza 1 dhe faza 2 kanë përfunduar dhe shoqatat e sigurisë janë aktive. Është një pohim për negociatën: të dyja palët u dakordësuan për një propozim, shkëmbyen çelësat dhe instaluan çiftin e SA-ve. Nuk thotë asgjë nëse përzgjedhësit e trafikut përputhen me nënrrjetet që ju mendoni se janë të mbrojtura, dhe as nëse pala e largët do ta drejtojë paketën diku pasi ta deshifrojë. Një tunel mund të qëndrojë aktiv për javë të tëra duke hedhur poshtë çdo fluks interesant, dhe pikërisht ky model i bën njerëzit të rindërtojnë një portë të shëndoshë.

Dy defektet që vlen të kontrollohen së pari janë një peer që propozon AH në vend të ESP, dhe një rrjet virtual i numëruar në një hapësirë që porta nuk do ta trajtojë si të brendshme.

Hapni regjistrin e eksportuar përpara se të prekni rrugët

Në portal, hapni portën e rrjetit virtual dhe ekzekutoni operacionin VPN troubleshoot mbi lidhjen, pastaj shkarkoni paketën që prodhon dhe shpaketojeni. Brenda ka një regjistër IKE me shkëmbimet e fazës 1 dhe fazës 2, me vulë kohore dhe i lexueshëm si tekst i thjeshtë. Kërkoni në të rreshtin transform në vend që ta lexoni nga lart poshtë, sepse zëri interesant është zakonisht disa qindra rreshta më poshtë. Nëse nuk keni akses në portal, të njëjtat diagnoza shfaqen në destinacionin e regjistrit të portës kur cilësimet e diagnostikimit janë aktivizuar.

Dy zëra mbajnë pjesën më të madhe të vlerës. I pari lexohet afërsisht expected ESP with combined authentication and cipher, received AH. I dyti është një gabim payload i pavlefshëm gjatë shkëmbimit IKE, që zakonisht do të thotë një fushë propozimi e formuar gabimisht ose e pambështetur.

Të dy përshkruajnë atë që ofroi pajisja lokale, pra të dy janë cilësime në anën e peer-it. Rikrijimi i anës Azure të lidhjes nuk e ndryshon propozimin që dërgon firewalls juaj, dhe ta bësh gjithsesi është ora më e humbur në këtë proces. Në peer, vendosni fazën 2 në ESP me vërtetim dhe shifrim të kombinuar dhe lëreni të negociojë algoritmin, pastaj kontrolloni nëse një kuti kontrolli e furnitorit me emër si combined mode po zgjedh në heshtje një propozim AH poshtë saj.

Konfirmoni hapësirën e adresave të rrjetit virtual

Porta pret që rrjeti virtual të jetë në intervale private. Një rrjet i numëruar në një bllok publik, për shembull një që fillon me 111.x, mund ta ngrejë tunelin ndërsa Azure refuzon ta trajtojë atë hapësirë si të brendshme, kështu që lidhja duket e shëndoshë dhe asnjë fluks nuk pranohet. Konfirmoni hapësirën e adresave përpara se të harxhoni një pasdite me përzgjedhësit. Nëse numërimi është një kërkesë e rreptë nga një alokim i vjetër, zgjidhja është një ndryshim i planit të adresave dhe jo një portë tjetër.

Shënoni mbivendosjen me intervalet lokale ndërsa jeni në panelin e hapësirës së adresave, sepse prefikset që mbivendosen prodhojnë një dështim tjetër që nga klienti duket i ngjashëm.

Verifikoni prefikset në të dyja drejtimet

Burimi i portës së rrjetit lokal mban prefikset lokale, dhe ato duhet të përputhen me nënrrjetet që pajisja e largët mbron vërtet. Një përmbledhje që përfshin adresa që pajisja i hedh poshtë do të lërë të kalojnë disa flukse dhe do të dështojë në të tjera, gjë që lexohet si një defekt i herëpashershëm i rrugëtimit dhe jo si një mospërputhje konfigurimi. Kontrolloni edhe anën e largët: një skaj liston një /16 ndërsa tjetri liston tre /24 brenda tij — ky është dështimi klasik i pjesshëm. Asnjë listë nuk është autoritative më vete, prandaj krahasoni të dyja krah për krah në vend që t'i besoni asaj që shihni.

Një ndryshim prefiksi nuk kapet gjithmonë vetë, prandaj planifikoni ta ruani ose ta rikrijoni objektin e lidhjes dhe pastaj konfirmoni që prefikset e reja shfaqen në të dyja anët.

Provoni një rrugë, jo një ping

Trace-i që ndan një tunel që punon nga një rrugë që punon duket kështu: hopi i parë është porta lokale, pastaj disa hop pa përgjigje, pastaj përgjigjet hosti i largët. Nëse trace-i nuk arrin kurrë te hosti, provoni portën TCP që aplikacioni përdor vërtet, sepse ICMP filtrohet mjaft shpesh saqë një ping i dështuar provon shumë pak. Ekzekutoni të njëjtin trace nga një host i largët drejt një makine virtuale në Azure. Asimetria midis dy rezultateve është mënyra më e shpejtë për të gjetur një rrugë kthimi që mungon ose një rregull që lejon vetëm një drejtim.

Shkruani propozimin e peer-it, të dy hapësirat e adresave dhe kohën e krijimit të lidhjes në tiketë, që inxhinieri i ardhshëm të dijë cilat vlera u rindërtuan dhe cilat nuk u prekën kurrë.

Nëse regjistri kthehet bosh, porta mund të mos e përfundojë fare lidhjen tuaj. Konfirmoni që adresa e peer-it në portën e rrjetit lokal përputhet me pajisjen nga e cila lexoni regjistrin, sepse dy porta në një abonim ngatërrohen lehtësisht gjatë një rindërtimi. Ai gabim kushton një ditë dhe nuk lë gjurmë në asnjë regjistër.