’n Proksitoets moet direkte terugval laat misluk

’n Plaaslike proksi wat langs ’n toepassing luister, herskep nie ’n netwerk wat proksitoegang vereis nie. Die toepassing kan die gekonfigureerde proksi ignoreer, direk verbind en steeds sukses rapporteer.

Skei die toepassing se netwerk van die proksi se uitwaartse pad. Een houergebonde reëling plaas die toepassing slegs op ’n interne netwerk en gee die proksi ’n tweede uitgangsnetwerk. In ’n bestaande Compose-definisie kan die netwerkkoppelinge so lyk:

services:
  app:
    networks: [clients]
  proxy:
    networks: [clients, egress]
networks:
  clients:
    internal: true
  egress: {}

Dit is ’n netwerkfragment vir dienste wat reeds gedefinieer is. Konfigureer die goedgekeurde vorentoe-proksi en die toepassing se werklike kliënt afsonderlik. Docker dokumenteer interne netwerke as ekstern geïsoleer; slegs die proksi in hierdie reëling het die bykomende uitwaartse netwerk.

Sluit ’n negatiewe geval in waarin proksigebruik verwyder is: die toepassing se eksterne versoek moet misluk. Vir ’n geauthentiseerde HTTP-proksi behoort ’n verwerpte rekening sy verifikasiefout te lewer, terwyl die aanvaarde rekening die teiken met ’n ooreenstemmende proksi-waarneming moet bereik.

Toets die proksi se toegestane en geweierde gevalle afsonderlik. Hou die toepassing weg van ander eksterne netwerke en vermy ’n omseilende gasheernetwerkmodus. ’n Suksesvolle versoek is eers nuttige bewys nadat die beoogde roete die een is wat die toets beskikbaar maak.