Тэст проксі павінен правальваць прамое злучэнне

Лакальны проксі, які слухае побач з праграмай, не ўзнаўляе сетку, якая патрабуе доступу праз проксі. Праграма можа праігнараваць наладжаны проксі, злучыцца напрамую і ўсё роўна паведаміць пра поспех.

Аддзяліце сетку праграмы ад знешняга шляху проксі. Адзін варыянт на аснове кантэйнераў змяшчае праграму толькі ва ўнутранай сетцы, а проксі атрымлівае другую выхадную сетку. У існуючым вызначэнні Compose падлучэнні да сетак могуць выглядаць так:

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

Гэта фрагмент сеткі для ўжо вызначаных сэрвісаў. Наладзьце адабраны прамы проксі і фактычнага кліента праграмы асобна. Docker апісвае ўнутраныя сеткі як ізаляваныя звонку; у гэтай схеме дадатковую знешнюю сетку мае толькі проксі.

Дадайце адмоўны выпадак без выкарыстання проксі: знешні запыт праграмы павінен пацярпець няўдачу. Для HTTP-проксі з аўтэнтыфікацыяй адхілены ўліковы запіс павінен даваць памылку аўтэнтыфікацыі, а прыняты — дасягаць мэты з адпаведным назіраннем з боку проксі.

Праверце дазволеныя і забароненыя выпадкі проксі асобна. Трымайце праграму па-за іншымі знешнімі сеткамі і не дадавайце рэжым сеткі хаста, які абыходзіць проксі. Паспяховы запыт — карысны доказ толькі тады, калі тэст дае менавіта той маршрут, які планаваўся.