Azure punct-la-site se conectează, dar niciun resurs privat nu răspunde
Conectat înseamnă doar că tunelul a urcat. Verificați ce poate transporta gateway-ul, comparați spațiile de adrese, apoi rezolvați un nume și testați serviciul în sine.
Conectat este o stare a tunelului, nu o afirmație despre accesibilitate. Un client punct-la-site poate termina IKE, poate primi o adresă și tot nu ajunge nicăieri, pentru că gateway-ul transmite trafic doar pentru rețelele pe care VNet le știe deja. Parcurgeți aceste cinci verificări în ordine și opriți-vă la prima defecțiune. Săritul înainte este modul în care o problemă DNS este tratată ca problemă de firewall timp de o oră.
Ordinea contează mai mult decât lista.
Verificarea 1: decideți ce trebuie să transporte tunelul
Azure VPN Gateway termină tunelul și transmite traficul care aparține VNet; nu esteo ieșire generală spre internet. Dacă utilizatorii se așteaptă ca navigarea lor să iasă prin Azure, proiectarea este greșită înainte de a intra în joc vreo setare a clientului. Activați split tunneling ca internetul local să rămână pe calea locală, și folosiți o instanță NAT sau un tunel site-la-site când este cu adevărat necesară o adresă de ieșire fixă.
Notați unde trebuie să ajungă clientul înainte de a testa ceva. Fără acea listă, fiecare rezultat parțial pare un progres.
Verificarea 2: comparați spațiile de adrese înainte de certificate
Suprapunerea este judecată pe intervalele mai largi, așa că două rețele care par diferite la nivel de subrețea se ciocnesc totuși dacă blocurile lor părinte se suprapun. Subrețeaua gateway-ului trebuie să fie dedicată și suficient de mare pentru SKU, iar pool-ul de adrese al clientului nu trebuie să se ciocnească cu VNet sau cu orice este accesibil printr-un peering. Schimbați planul și implementați din nou, pentru că adăugarea de rute ca compensare produce un tunel care funcționează pentru unele destinații și inexplicabil nu pentru altele. Provisionarea eșuează zgomotos aici, ceea ce este cazul bun.
Autentificarea este următoarea poartă. Profilurile de certificat, RADIUS și Entra ID nu sunt interschimbabile, iar pachetul de client diferă pentru fiecare.
Verificarea 3: rezolvați un nume privat din interior
Clientul își păstrează propriul resolver dacă profilul descărcat nu conține serverele DNS ale VNet, iar acea listă este încorporată la momentul descărcării. Adăugați un forwarder în interiorul VNet, setați-l ca server DNS al VNet, apoi descărcați și importați din nou pachetul de client. Reutilizarea pachetului vechi testează doar lista veche de resolveri.
Testați mai întâi o adresă, pentru că aceasta separă rutarea de denumire într-un singur pas: Test-NetConnection 10.20.1.4 -Port 3389.
Dacă adresa răspunde și numele nu, întrebați resolverul direct cu Resolve-DnsName files.corp.example -Server 10.20.0.4. Dacă ambele eșuează, defecțiunea nu este DNS și ar trebui să opriți editarea setărilor DNS. DNS-ul platformei Azure la 168.63.129.16 răspunde doar din interiorul VNet, așa că un client din afara ei nu poate folosi acea adresă ca resolver.
Verificarea 4: testați serviciul din spatele tunelului
Un tunel sănătos și un port închis arată identic din perspectiva clientului. Verificați firewall-ul invitatului, apoi grupul de securitate de rețea de pe subrețea sau NIC, apoi dacă serviciul ascultă pe adresa privată și nu doar pe loopback. Permiteți pool-ul de clienți ca sursă în loc să deschideți o regulă spre internet, și rețineți că SMB către Azure Files are nevoie de calea punctului final privat rutată prin tunel. Când un resurs răspunde pe IP, dar nu pe nume, întoarceți-vă la verificarea 3 în loc să atingeți gateway-ul.
Un tabel ține straturile separate în timp ce lucrați:
| Symptom | Layer to check |
|---|---|
| Name fails, private IP works | Resolver setting or forwarder |
| Private IP also fails | Address plan, NSG, guest firewall |
| Private works, internet fails | Expected; the gateway is not an egress |
| Connects, then drops | Tunnel type or certificate mismatch |
Verificarea 5: înregistrați profilul înainte de escaladare
Puneți în tichet tipul de gateway, tipul de tunel, metoda de autentificare și sistemul de operare al clientului. Un profil IKEv2 cu certificat și un profil RADIUS eșuează din motive diferite, iar un client construit pentru alt tip de tunel se conectează doar când gateway-ul oferă un protocol compatibil.
Pentru o echipă mică, proiectarea durabilă este un VNet, un forwarder DNS și un client split-tunnel documentat. Dacă cerința este o ieșire publică fixă, terminați un tunel site-la-site pe un firewall pe care îl controlați și rutați traficul de internet acolo, în loc să cereți gateway-ului punct-la-site ceva pentru care nu a fost niciodată construit.