VPN S2S în Azure conectat dar fără trafic: citiți jurnalul IKE

Portalul spune Connected, tunelul are un contor de timp de funcționare, iar un trace de pe mașina dvs. virtuală moare la al doilea hop. Starea conexiunii descrie negocierea IKE și IPsec, nu dacă un singur pachet supraviețuiește stratului de politici de oricare parte. Două defecte explică majoritatea acestor tichete și niciunul nu se repară prin schimbarea unei rute în Azure. Ambele sunt deja scrise în jurnalul pe care l-a produs gateway-ul, de aceea încep de acolo și nu din tabelul de rute.

Ce certifică de fapt Connected

O conexiune site-to-site conectată înseamnă că faza 1 și faza 2 sunt finalizate și că asocierile de securitate sunt active. Este o afirmație despre negociere: ambele părți au convenit asupra unei propuneri, au schimbat chei și au instalat perechea de SA. Nu spune nimic despre dacă selectorii de trafic corespund subrețelelor pe care le considerați protejate și nici despre dacă partea îndepărtată va ruta pachetul undeva după ce îl decriptează. Un tunel poate sta activ săptămâni întregi aruncând fiecare flux interesant, iar acesta este exact modelul care îi face pe oameni să reconstruiască un gateway sănătos.

Cele două defecte care merită verificate mai întâi sunt un peer care propune AH în loc de ESP și o rețea virtuală numerotată într-un spațiu pe care gateway-ul nu îl va trata ca intern.

Deschideți jurnalul exportat înainte de a atinge rutele

În portal, deschideți gateway-ul de rețea virtuală și rulați operația VPN troubleshoot pe conexiune, apoi descărcați pachetul pe care îl produce și dezarhivați-l. Înăuntru este un jurnal IKE cu schimburile din faza 1 și faza 2, cu marcaje de timp și lizibil ca text simplu. Căutați în el linia transform în loc să citiți de sus în jos, pentru că intrarea interesantă se află de obicei câteva sute de linii mai jos. Dacă nu aveți acces la portal, aceleași diagnostice apar în destinația de jurnale a gateway-ului când setările de diagnostic sunt activate.

Două intrări poartă cea mai mare parte a valorii. Prima sună cam așa: expected ESP with combined authentication and cipher, received AH. A doua este o eroare de payload invalid în timpul schimbului IKE, ceea ce înseamnă de obicei un câmp de propunere format greșit sau neacceptat.

Ambele descriu ce a oferit dispozitivul local, deci ambele sunt setări din partea peer-ului. Regenerarea părții Azure a conexiunii nu schimbă propunerea pe care o trimite firewall-ul dvs., iar să faceți asta totuși este cea mai des irosită oră din acest flux de lucru. Pe peer, setați faza 2 pe ESP cu autentificare și cifrare combinate și lăsați-l să negocieze algoritmul, apoi verificați dacă o bifă a furnizorului cu un nume ca combined mode selectează în tăcere o propunere AH dedesubt.

Confirmați spațiul de adrese al rețelei virtuale

Gateway-ul așteaptă ca rețeaua virtuală să fie în intervale private. O rețea numerotată într-un bloc public, de exemplu una care începe cu 111.x, poate ridica tunelul în timp ce Azure refuză să trateze acel spațiu ca intern, așa că conexiunea pare sănătoasă și niciun flux nu este acceptat. Confirmați spațiul de adrese înainte de a petrece o după-amiază pe selectori. Dacă numerotarea este o cerință strictă dintr-o alocare mai veche, remedierea este o schimbare a planului de adrese și nu un alt gateway.

Notați suprapunerea cu intervalele locale cât timp sunteți în panoul spațiului de adrese, pentru că prefixele care se suprapun produc o defecțiune diferită care arată similar din partea clientului.

Verificați prefixele în ambele direcții

Resursa gateway-ului de rețea locală conține prefixele locale și acestea trebuie să corespundă subrețelelor pe care dispozitivul îndepărtat le protejează cu adevărat. Un rezumat care include adrese pe care dispozitivul le aruncă va lăsa să treacă unele fluxuri și va eșua pe altele, ceea ce se citește ca o defecțiune intermitentă de rutare și nu ca o nepotrivire de configurare. Verificați și partea îndepărtată: un capăt listează un /16 în timp ce celălalt listează trei /24 în interiorul lui — aceasta este defecțiunea parțială clasică. Niciuna dintre liste nu este autoritară singură, așa că comparați-le una lângă alta în loc să vă încredeți în cea pe care o vedeți.

O schimbare de prefix nu este întotdeauna preluată de la sine, așa că planificați să salvați din nou sau să recreați obiectul conexiunii și apoi confirmați că noile prefixe apar pe ambele părți.

Testați o cale, nu un ping

Trace-ul care separă un tunel funcțional de o rută funcțională arată astfel: primul hop este gateway-ul local, apoi câteva hopuri care nu răspund, apoi răspunde gazda îndepărtată. Dacă trace-ul nu ajunge niciodată la gazdă, testați portul TCP pe care aplicația îl folosește cu adevărat, pentru că ICMP este filtrat destul de des încât un ping eșuat să demonstreze foarte puțin. Rulați același trace de pe o gazdă îndepărtată spre o mașină virtuală din Azure. Asimetria dintre cele două rezultate este cea mai rapidă cale de a găsi o rută de retur lipsă sau o regulă care permite doar o singură direcție.

Scrieți propunerea peer-ului, ambele spații de adrese și ora creării conexiunii în tichet, ca următorul inginer să știe ce valori au fost reconstruite și care nu au fost atinse niciodată.

Dacă jurnalul revine gol, este posibil ca gateway-ul să nu vă termine deloc conexiunea. Confirmați că adresa peer-ului din gateway-ul de rețea locală corespunde dispozitivului de pe care citiți jurnalul, pentru că două gateway-uri într-un singur abonament se confundă ușor în timpul unei reconstrucții. Acea greșeală costă o zi și nu lasă nicio urmă în niciun jurnal.