Docker publikigis la pordon. Ĉu la prokurilo aŭskultas tie?
Kontrolu la aŭskultanton ene de prokurila ujo kaj la gastigan pordomapadon de Docker kiam konektoj estas rifuzataj aŭ restarigitaj.
Publikigita Docker-pordo donas vojon al finpunkto en ujo. Ĝi nek lanĉas la prokurilon nek ŝanĝas la adreson sur kiu tiu procezo aŭskultas.
Por tipa ponta-reta mapado, komparu ĉi tiujn tri valorojn:
| Parto de la vojo | Valoro por inspekti |
|---|---|
| Klienta eniro | La gastiga adreso kaj la publikigita pordo kiujn la kliento kontaktas |
| Plusendada celo | La uja adreso kaj pordo elektitaj de la mapado |
| Servo | La adreso kaj pordo kiujn la prokurilo efektive ligas ene de la ujo |
Prokurilo ligita nur al 127.0.0.1 ene de la ujo eble ne ricevos trafikon plusenditan al sia reta adreso. Tio diferencas de publikigi gastigan pordon nur sur la gastiga loopback: tio limigas kiun povas atingi la mapadon, dum uja loopback povas malhelpi la mapadon atingi la servon.
Elektu la internan aŭskultanton por la celata deplojo konservante limigitan gastigan publikigon kaj prokurilan aliron. La deklaro pri elmetita pordo en Dockerfile ne lanĉas servon, kaj sukcesa uja lanĉo ne pruvas ke la procezo aŭskultas ĉe la plusendada celo.
Observu kiom malproksimen atingas malsukcesa konekto. Rifuzoj kaj restarigoj varias laŭ la platformo kaj la plusendada efektivigo, do nek unu nek la alia unike identigas agordon. Kiam ĝi atingas la servon, serĉu validan prokurilan saluton kaj apliku la postulatan SOCKS-version, aŭtentikigon kaj celpolitikon. Nur atingebla gastiga pordo ne povas pruvi tiujn kapablojn.