Docker paskelbė prievadą. Ar tarpinis serveris ten klausosi?
Patikrinkite klausytoją tarpinio serverio konteineryje ir Docker host prievado susiejimą, kai ryšiai atmetami arba atstatomi.
Paskelbtas Docker prievadas suteikia kelią į konteinerio galinį tašką. Jis nepaleidžia tarpinio serverio ir nekeičia adreso, kuriuo tas procesas klausosi.
Įprastam tiltinio tinklo susiejimui palyginkite šias tris reikšmes:
| Kelio dalis | Tikrinama reikšmė |
|---|---|
| Kliento įėjimas | Host adresas ir paskelbtas prievadas, su kuriais jungiasi klientas |
| Persiuntimo tikslas | Konteinerio adresas ir prievadas, kuriuos pasirenka susiejimas |
| Paslauga | Adresas ir prievadas, kuriuos tarpinis serveris iš tikrųjų susieja konteinerio viduje |
Konteinerio viduje tik prie 127.0.0.1 susietas tarpinis serveris gali negauti srauto, persiunčiamo į jo tinklo adresą. Tai skiriasi nuo host prievado paskelbimo tik host loopback sąsajoje: tai apriboja, kas gali pasiekti susiejimą, o konteinerio loopback gali neleisti susiejimui pasiekti paslaugos.
Pasirinkite vidinį klausytoją numatytam diegimui, išlaikydami apribotą host paskelbimą ir prieigą prie tarpinio serverio. Dockerfile deklaruotas atviras prievadas nepaleidžia paslaugos, o sėkmingas konteinerio paleidimas neįrodo, kad procesas klausosi persiuntimo tiksle.
Stebėkite, kiek toli pasiekia nepavykęs ryšys. Atmetimai ir atstatymai skiriasi priklausomai nuo platformos ir persiuntimo įgyvendinimo, todėl nė vienas jų vienareikšmiškai nenustato nustatymo. Kai jis pasiekia paslaugą, ieškokite galiojančio tarpinio serverio pasveikinimo ir pritaikykite reikiamą SOCKS versiją, autentifikavimą ir paskirties politiką. Vien tik pasiekiamas host prievadas negali įrodyti šių galimybių.