Docker ha pubblicato la porta. Il proxy è in ascolto lì?
Controllate il listener dentro un container proxy e la mappatura della porta host di Docker quando le connessioni vengono rifiutate o reimpostate.
Una porta Docker pubblicata fornisce un percorso verso un endpoint nel container. Non avvia il proxy e non cambia l'indirizzo su cui quel processo è in ascolto.
Per una tipica mappatura in rete bridge, confrontate questi tre valori:
| Parte del percorso | Valore da ispezionare |
|---|---|
| Ingresso del client | L'indirizzo dell'host e la porta pubblicata che il client contatta |
| Destinazione dell'inoltro | L'indirizzo del container e la porta scelti dalla mappatura |
| Servizio | L'indirizzo e la porta che il proxy associa realmente dentro il container |
Un proxy associato solo a 127.0.0.1 dentro il container può non ricevere il traffico inoltrato al suo indirizzo di rete. Questo differisce dal pubblicare una porta host solo sul loopback dell'host: ciò limita chi può raggiungere la mappatura, mentre il loopback del container può impedire alla mappatura di raggiungere il servizio.
Scegliete il listener interno per la distribuzione prevista preservando la pubblicazione host limitata e l'accesso al proxy. La dichiarazione di porta esposta di un Dockerfile non avvia un servizio, e un avvio riuscito del container non dimostra che il processo sia in ascolto sulla destinazione dell'inoltro.
Seguite fin dove arriva una connessione fallita. I rifiuti e le reimpostazioni variano in base alla piattaforma e all'implementazione dell'inoltro, quindi nessuno dei due identifica da solo un'impostazione. Quando raggiunge il servizio, cercate un saluto proxy valido e applicate la versione SOCKS, l'autenticazione e la politica di destinazione richieste. Una porta host raggiungibile da sola non può stabilire queste capacità.