Docker het die poort gepubliseer. Luister die proxy daar?
Kontroleer die luisteraar binne 'n proxy-houer sowel as Docker se gasheerpoorttoewysing wanneer verbindings geweier of gereset word.
'n Gepubliseerde Docker-poort bied 'n pad na 'n houer-eindpunt. Dit begin nie die proxy nie en verander nie die adres waarop daardie proses luister nie.
Vir 'n tipiese brugnetwerk-toewysing, vergelyk hierdie drie waardes:
| Deel van die pad | Waarde om te ondersoek |
|---|---|
| Kliënt-ingang | Die gasheeradres en gepubliseerde poort wat die kliënt kontak |
| Deurstuurtarget | Die houeradres en poort wat deur die toewysing gekies word |
| Diens | Die adres en poort wat die proxy werklik binne die houer bind |
'n Proxy wat slegs aan 127.0.0.1 binne die houer gebind is, ontvang dalk nie verkeer wat na sy netwerkadres deurgestuur word nie. Dit verskil van die publikasie van 'n gasheerpoort slegs op gasheer-loopback: dit beperk wie die toewysing kan bereik, terwyl houer-loopback kan verhoed dat die toewysing die diens bereik.
Kies die interne luisteraar vir die beoogde ontplooiing terwyl beperkte gasheerpublikasie en proxy-toegang behou word. 'n Dockerfile se blootgestelde-poort-verklaring begin nie 'n diens nie, en 'n suksesvolle houerlanseering bewys nie dat die proses by die deurstuurtarget luister nie.
Volg hoe ver 'n mislukte verbinding kom. Weierings en resets verskil per platform en deurstuurtimplementering, so nie een identifiseer uniek 'n instelling nie. Sodra dit die diens bereik, soek 'n geldige proxy-groet en pas die vereiste SOCKS-weergawe, verifikasie en bestemmingsbeleid toe. 'n Bereikbare gasheerpoort alleen kan nie daardie vermoëns bewys nie.