Docker a publicat portul. Ascultă proxy-ul acolo?
Verificați ascultătorul din containerul proxy și maparea portului gazdă din Docker când conexiunile sunt refuzate sau resetate.
Un port Docker publicat oferă o cale către un punct final din container. Nu pornește proxy-ul și nu schimbă adresa pe care ascultă acel proces.
Pentru o mapare tipică în rețea bridge, comparați aceste trei valori:
| Partea căii | Valoarea de inspectat |
|---|---|
| Intrarea clientului | Adresa gazdă și portul publicat pe care le contactează clientul |
| Ținta redirecționării | Adresa containerului și portul alese de mapare |
| Serviciul | Adresa și portul pe care proxy-ul le leagă efectiv în container |
Un proxy legat în container doar la 127.0.0.1 poate să nu primească traficul redirecționat către adresa sa de rețea. Aceasta diferă de publicarea unui port gazdă doar pe loopback-ul gazdei: aceasta restricționează cine poate ajunge la mapare, în timp ce loopback-ul containerului poate împiedica maparea să ajungă la serviciu.
Alegeți ascultătorul intern pentru implementarea dorită, păstrând publicarea restricționată a gazdei și accesul la proxy. Declarația de port expus dintr-un Dockerfile nu pornește un serviciu, iar o pornire reușită a containerului nu dovedește că procesul ascultă la ținta redirecționării.
Urmăriți cât de departe ajunge o conexiune eșuată. Refuzurile și resetările variază în funcție de platformă și de implementarea redirecționării, așa că niciuna nu identifică singură o setare. Odată ce ajunge la serviciu, căutați un salut de proxy valid și aplicați versiunea SOCKS, autentificarea și politica de destinație necesare. Doar un port gazdă accesibil nu poate stabili aceste capacități.