SSH локално прослеђивање ка постојећем HTTP проксију: две loopback адресе

Ваш одобрени прокси ради на скок-хосту где слуша само на loopback-у, па му ништа изван тог рачунара не може приступити. Није вам потребан VPN ни нови прокси; потребан вам је један порт тог рачунара пренесен на један ваш порт. Локално прослеђивање чини управо то и тражи једну наредбу плус једно подешавање апликације. Забуна обично настаје мешањем тога која loopback адреса припада ком рачунару.

Утврдите да ли фиксни прокси већ постоји

Ова техника прослеђује услугу која већ ради. Ако удаљени хост има само SSH демон и нема прокси, никакво прослеђивање га не ствара, а веза ће бити одбијена са удаљене стране. Потврдите да је прокси везан, који му је порт и да ли слуша на 127.0.0.1 или на одређеној адреси интерфејса, јер та адреса мора бити циљ прослеђивања.

Ако то потврдите прво, поштедећете себе отклањања грешака на тунелу који никада није био повезан ни са чим.

Изградите прослеђивање и прочитајте наредбу

Облик који желите везује loopback порт на вашем преносном рачунару и повезује га, са стране сервера, са адресом проксија онако како је сервер види.

ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:13128:127.0.0.1:3128 [email protected]

-N потискује удаљену наредбу, а -T потискује доделу termios-а, јер желите тунел, а не љуску. Прва loopback адреса је место где преносни рачунар слуша; другу разрешава SSH сервер, па 127.0.0.1 тамо значи прокси на том рачунару. ExitOnForwardFailure чини да наредба гласно не успе ако је локални порт већ заузет, уместо да покрене сесију која ништа не прослеђује. Запишите циљну адресу онако како је сервер разрешава, јер име које само ваш преносни рачунар може да разреши неће успети на другој страни.

Сопствена политика сервера важи пре него што било шта од овога проради. AllowTcpForwarding мора то да дозволи, а PermitOpen може да ограничи на која одредишта и портове сесија сме да дође, па прослеђивање које клијент прихвати сервер ипак може да одбије. Одбијање се појављује као грешка прослеђивања или канала на клијенту, а читање те поруке је брже од уређивања наредбе.

Усмерите једну апликацију на прослеђивање

Подесите апликацију да користи HTTP прокси на http://127.0.0.1:13128, са акредитивима ако их удаљени прокси захтева. Задржите сопствену проверу сертификата апликације за HTTPS одредишта, јер је тунел проксија не замењује. Ово је фиксно прослеђивање једне услуге, па апликацији треба рећи за прокси уместо да је оставите да га сама открије.

Брза провера пре било каквог трајног подешавања: curl -x http://127.0.0.1:13128 -I https://example.com, што испробава HTTP CONNECT методу коју прокси мора да подржава.

Задржите овлашћења тамо где су била

Удаљени прокси и даље одлучује која одредишта и методе допушта, а SSH пријава не би смела тихо да да сваком налогу општи веб релеј. Везивање на 127.0.0.1 на преносном рачунару избегава објављивање порта на вашу локалну мрежу, али порт не чини приватним од других процеса на истом рачунару. Замена тог везивања wildcard адресом ради дељења проксија начин је на који настаје неуправљани отворени релеј.

SSH пренос штити скок до сервера. После те тачке прокси отвара сопствену везу, па обичан HTTP захтев ка одредишту остаје обичан и после сервера, иако је први сегмент био шифрован.

Проверите оба краја, затим почистите

Постављање локалног тунела и успех удаљене услуге различити су резултати, а излазни статус наредбе говори само о првоме. Проверите да ли слушалац постоји помоћу ss -ltn, затим упутите дозвољен захтев апликације и захтев који прокси треба да одбије. Ако се оба понашају како се очекује, пут је стваран; ако је тунел активан и сваки захтев не успе, прокси одбија или не може да дође до одредишта.

Када завршите, зауставите SSH процес који га држи, уклоните подешавање проксија из апликације и потврдите да је локални порт нестао уместо да оставите слушаоца који ће надживети задатак.