Дайте на отдалечен Pi SOCKS прокси през вашия SSH клиент

Отдалеченото динамично пренасочване поставя SOCKS слушателя на Pi и осъществява следващата връзка от одобрения VPN път на вашия лаптоп. Без втори SSH сървър.

Приемате, че SOCKS прокси трябва да работи там, където достъпът до мрежата вече съществува. OpenSSH може да постави слушателя съвсем другаде. Отдалеченото динамично пренасочване отваря SOCKS порта на отдалечен хост и започва всяка връзка от вашия локален SSH клиент, който носи одобрения VPN път на лаптопа. Pi получава ограничено прокси; то не наследява тунела или правата ви.

Слушателят и страната, от която тръгва връзката, могат да са различни

Обикновената ssh -D 1080 пуска слушателя на вашата машина и изпраща връзките оттам. Отдалеченото динамично пренасочване обръща това: слушателят се появява на отдалечения хост и всяка връзка, която приеме, се отваря от локалната страна. Ръководството на OpenSSH клиента документира -R без фиксирана дестинация точно като тази схема SOCKS4/5.

Поддържана команда от лаптопа изглежда така, като акаунтът, хостовете и портът са запълващи стойности:

ssh -NT -S none -o ExitOnForwardFailure=yes \
  -o PermitRemoteOpen=app.corp.example:443 \
  -R 1080 [email protected]

Три подробности вършат полезна работа там. -S none държи сесията далеч от споделен контролен master, ExitOnForwardFailure се проваля бързо, вместо да ви остави с полуотворена сесия, а PermitRemoteOpen ограничава какво може да достигне отдалеченият слушател. Използвайте оторизиран акаунт в Pi и проверете ключа на хоста, преди да добавите нещо от това.

Какво всъщност излага отдалеченият слушател

Проверете политиката за пренасочване на сървъра, преди да разчитате на слушателя. С GatewayPorts no отдалеченото пренасочване остава вързано към loopback и това е излагането, което искате. Сървър, настроен да налага wildcard пренасочване, публикува същия порт на всеки интерфейс, което превръща лично прокси в нещо, достъпно за локалната мрежа.

Loopback също не е граница между потребителите. Друг процес на Pi може да се свърже с 127.0.0.1:1080, ако знае порта, така че локалните акаунти на Pi и всичко, което работи на него, са част от вашия дизайн за достъп. Това е причина да държите списъка с дестинации тесен, а не причина да пропуснете проверката на политиката.

Дръжте разрешената дестинация конкретна за приложението, което се опитвате да достигнете. Замяната ѝ с неограничено пренасочване, за да работи несвързана програма, разширява пътя далеч отвъд проблема, с който сте започнали. Списъкът с дестинации също записва за какво е била сесията и това помага на всеки, който я одитира по-късно. Запишете го до акаунта, който сте използвали.

Прекарайте едно приложение през проксито

Клиент на Pi, който разбира прокси, може след това да направи заявката. Префиксът socks5h предава името на дестинацията на проксито, така че търсенето и връзката се случват от страната на лаптопа и съвпада с именуваната дестинация в PermitRemoteOpen:

curl --proxy socks5h://127.0.0.1:1080 \
  --noproxy '' https://app.corp.example/

Запазете нормалната проверка на сертификата и собствената автентикация на приложението. Проксито променя къде се установява TCP връзката; то не прави неавтентикирана услуга безопасна и не превръща самоподписан край в доверен.

Лаптопът все още се нуждае от свой маршрут и достъп до резолвера както до SSH сървъра, така и до приложението. Трафикът на неговия SSH клиент трябва да бъде избран от одобрената VPN политика, а изключване при split-tunnel може да изпрати този трафик по различен път от тествания.

Докажете пътя и го затворете

Потвърдете, че слушателят съществува там, където го очаквате, и че отговаря само предвидената дестинация:

$ ss -ltnp | grep 1080
LISTEN 0 128 127.0.0.1:1080 0.0.0.0:*
$ curl -sS -o /dev/null -w '%{http_code}\n' \
    --proxy socks5h://127.0.0.1:1080 https://app.corp.example/

ExitOnForwardFailure може да докаже, че пренасочването е установено, и пак не може да удостовери, че входът в приложението успява надолу по веригата. Тествайте приложението, не само порта. Слушател, който приема и после проваля всяка заявка, обикновено означава, че името на дестинацията или маршрутът на лаптопа са грешни, а не че тунелът се е провалил.

Тази схема носи само TCP. UDP, ICMP и програми, които игнорират настройките за прокси, остават извън нея, а пренасочването приключва в момента, в който приключи SSH сесията. Спрете тази сесия, когато приключите, и премахнете настройката за прокси, която добавихте към приложението.

За постоянен достъп използвайте вместо това поддържаната регистрация на собственика на мрежата или управляван шлюз. Обратното прокси е грешен инструмент за заобикаляне на ограниченията на VPN за устройства или ресурси; използвано в тях, то е просто един разрешен път за приложение с изрични граници.

Подобни статии