Перанакіраванне Squid праз TCP-балансіроўшчык DigitalOcean

Выкарыстоўвайце аднолькавыя пратаколы ўваходу і мэты TCP для існуючага рэсурсу DigitalOcean, калі шлях павінен захоўваць прамы HTTP і CONNECT.

Для існуючага рэсурсу балансіроўшчыка нагрузкі DigitalOcean захоўвайце байтавы паток проксі кліента з аднолькавымі пратаколамі TCP:

forwarding_rule {
  entry_port      = 3128
  entry_protocol  = "tcp"
  target_port     = 3128
  target_protocol = "tcp"
}

Трымайце фактычную мэту, сеткавыя абмежаванні і праверкі стану вакол гэтага фрагмента. Кліент выкарыстоўвае адрас балансіроўшчыка, а Squid прымае паток на сваім слухачы.

Прамы проксі прымае HTTP-мэты ў абсалютнай форме і CONNECT для HTTPS. Звычайны рэжым балансіроўкі HTTP павінен яўна падтрымліваць такія размовы; называць слухач HTTP не даказвае сумяшчальнасці.

Правярайце не толькі порт: праверка стану TCP даказвае прыём, а аўтэнтыфікаваны CONNECT да дазволенай мэты правярае кантракт проксі.

Праверце адрас крыніцы, які бачыць Squid, перш чым спадзявацца на аўтарызацыю па IP. Метаданыя пратаколу PROXY, калі выкарыстоўваюцца, патрабуюць падтрымкі з абодвух бакоў і дадаюць байты перад запытам проксі. Планамерна злівайце жывыя тунелі падчас абслугоўвання мэты; раптоўнае выдаленне іх працэсу перарывае іх.

Падобныя артыкулы