Accesarea unei aplicații private Container Apps prin VPN de la punct la site
Un mediu intern Container Apps are nevoie de o intrare privată, un nume de gazdă potrivit și un resolver pe care VPN-ul îl poate atinge. Rulați fiecare pas, apoi verificați refuzul.
Acest ghid acoperă un mediu Container Apps cu profile de încărcare a muncii și o intrare internă în rețeaua virtuală, accesată de pe un laptop printr-un VPN de la punct la site aprobat, folosind FQDN-ul direct al aplicației și fără rute HTTP la nivel de mediu. intrarea mediului este accesibilă din client, domeniul de intrare al aplicației admite apelantul, iar numele de gazdă este rezolvat la intrarea privată. Fiecare pas de mai jos lasă un rezultat verificabil și o revenire care nu atinge nimic ce nu ați modificat. Parcurgeți-le în ordinea dată, deoarece niciun pas ulterior nu poate compensa o decizie de domeniu luată greșit la pasul 1.
Înainte de a atinge DNS, clarificați cuvântul intern. Este folosit pentru două domenii diferite în acest produs, iar interschimbarea lor este cel mai frecvent motiv pentru care un nume funcțional tot nu returnează nimic util.
Pasul 1: stabiliți domeniul mediului și al aplicației
Citiți configurația de intrare a aplicației înainte de a modifica orice înregistrare:
| Setting | Boundary |
|---|---|
| Internal environment | The environment entry is reached through its private network arrangement |
| App with internal ingress | Callers from the environment VNet only; a VPN laptop qualifies once it has a route into that VNet and the domain resolves privately |
| App with external ingress in an internal environment | The app accepts outside traffic through the environment's private entry |
Traficul de intrare intern este expus pe echilibratorul de încărcare intern al mediului în interiorul VNet-ului mediului, deci întrebarea nu este dacă laptopul este o altă aplicație de containere, ci dacă poate ajunge la acel VNet. Un client VPN cu o rută în VNet și domeniul implicit al mediului rezolvat prin zona privată este un apelant eligibil, și exact asta construiesc pașii rămași. Un mediu intern fără intrare publică este un fapt diferit de o aplicație cu trafic de intrare intern, iar traficul de intrare extern la nivel de aplicație nu oferă mediului o ușă publică. Scrieți domeniul în tichet și în portal, deoarece următorul inginer citește mai întâi tichetul.
Confirmați acel domeniu cu proprietarul configurației înainte de a continua și țineți poarta îngustă: dacă nu există nicio rută în VNet-ul mediului, sau domeniul implicit al mediului nu este rezolvat prin zona privată, opriți-vă și reparați mai întâi acea cale. Niciun pas ulterior nu poate înlocui un apelant care nu poate ajunge la VNet sau nu poate rezolva numele.
Pasul 2: colectați numele de gazdă real și adresa de intrare
Notați domeniul implicit al mediului, adresa sa privată statică de intrare și FQDN-ul configurat al aplicației, luate din resursă și nu dintr-o captură de ecran veche sau o pagină wiki:
az containerapp env show -n ENV -g RG \
--query "{domain:properties.defaultDomain, ip:properties.staticIp}"
az containerapp show -n APP -g RG \
--query "properties.configuration.ingress.fqdn"Ghidul pentru intrarea privată a Container Apps descrie potrivirea domeniului mediului cu adresa sa internă, păstrând intacte numele de gazdă ale aplicației. Exact această formă o construiți aici manual, așa că aliniați conținutul zonei la ea în loc să inventați o nouă schemă de denumire.
Dacă domeniul citit nu corespunde FQDN-ului raportat de aplicație, opriți-vă și reconciliați-le acum. Construirea unei zone pe sufixul greșit produce un nume de gazdă care se rezolvă perfect și totuși ajunge pe gazda virtuală greșită.
Pasul 3: puneți zona privată pe calea resolverului VPN-ului
Creați sau reutilizați zona DNS privată acceptată pentru domeniul implicit real al mediului, cu înregistrările wildcard și de adresă documentate care indică intrarea statică. Legați acea zonă la rețeaua virtuală potrivită și faceți autoritatea privată accesibilă prin calea de resolver aprobată a VPN-ului, în loc să presupuneți că legătura este suficientă.
Un client de la punct la site are de obicei nevoie de un punct final de intrare al unui resolver privat sau de un forwarder DNS acceptat pentru a ajunge la acea zonă. Legarea unei zone schimbă ce rezolvă Azure pentru rețelele legate; nu redirecționează resolverul public al fiecărui laptop extern. Nu o înlocuiți cu o zonă DNS de punct final privat împrumutată din alt model de rețea Container Apps, deoarece numele înregistrărilor și sufixul zonei nu se vor potrivi.
Revenirea pentru acest pas este eliminarea legăturii zonei sau a înregistrării adăugate. Notați care dintre cele două a fost, deoarece ștergerea unei zone partajate pentru a anula o singură legătură este o modalitate bine cunoscută de a strica un al doilea mediu.
Pasul 4: testați numele, apoi publicul refuzat
Testați numele de gazdă și identitatea TLS împreună, nu doar adresa. Pentru un diagnostic controlat de mapare a numelor puteți fixa adresa păstrând numele de gazdă:
curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
https://app.ENVIRONMENT_DOMAIN/Înlocuiți numele de gazdă cu FQDN-ul real al aplicației și adresa cu intrarea internă reală. Acest lucru afectează doar acea singură cerere și nu este provizionare DNS. Nu adăugați -k pentru a transforma o eroare de identitate într-o trecere aparentă, deoarece o nepotrivire de certificat este semnalul că loviți ascultătorul greșit.
Cererea directă a adresei numerice poate selecta gazda virtuală greșită sau poate eșua validarea chiar în timp ce TCP 443 răspunde, așa că tratați un test IP reușit ca dovadă despre rețea și nimic mai mult. De pe laptopul dorit, calea normală a resolverului este forwarderul DNS al clientului sau punctul final de intrare al resolverului privat care găzduiește zona, iar un eșec acolo este o problemă de accesibilitate a resolverului, nu o înregistrare lipsă. Confirmați că aceeași cerere reușește pe acea cale, apoi confirmați că publicul refuzat este încă refuzat.
Ce să înregistrați și ce să reveniți
Portul țintă al containerului și portul HTTPS al clientului sunt setări separate. Nu publicați portul țintă al containerului prin VPN pentru că containerul ascultă acolo, și nu lărgiți o regulă de rețea pentru a trece un test de port. Ambele modificări supraviețuiesc incidentului și sunt greu de atribuit ulterior.
Încheiați cu o operație nouă a aplicației de pe laptopul dorit, cu identitatea sa autorizată și DNS-ul său normal, apoi verificați că un apelant neautorizat încă eșuează. În timp ce sunteți în configurația aplicației, confirmați și dacă o rută HTTP la nivel de mediu expune această aplicație ca țintă, deoarece acea rută este o a doua ușă pe care domeniul de intrare nu o descrie.
Înregistrați cinci valori împreună: domeniul mediului, domeniul de intrare al aplicației, FQDN-ul, adresa privată de intrare și proprietarul resolverului. Acele cinci descriu întregul contract de acces, iar următoarea persoană care îl va depana va cere exact acelea.