Дајте на далечински 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 ја држи сесијата подалеку од заеднички контролен мастер, ExitOnForwardFailure брзо се провалува наместо да ве остави со полуотворена сесија, а PermitRemoteOpen ограничува до каде може да стигне далечинскиот слушач. Користете овластена Pi сметка и проверете го клучот на домаќинот пред сѐ да додадете нешто од ова.

Што навистина изложува далечинскиот слушач

Проверете ја политиката за проследување на серверот пред да се потпрете на слушачот. Со GatewayPorts no далечинското проследување останува врзано за loopback, и тоа е изложеноста што ја сакате. Сервер конфигуриран да наметне џокер-проследување го објавува истиот порт на секој интерфејс, што го претвора личното прокси во нешто достапно за локалната мрежа.

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 по уред или ресурс; користено внатре во нив, тоа е едноставно една овластена апликациска патека со јасни граници.

Поврзани статии