Локално пренасочване по 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 процес, премахнете настройката за прокси от приложението и потвърдете, че локалният порт е изчезнал, вместо да оставите слушател, който надживява задачата.