Динамичко SSH прослеђивање као SOCKS прокси преко вашег VPN-а
Апликација која говори само SOCKS нема прокси завршну тачку на обичном VPN-у. Два скока, један loopback слушалац и једно тражење имена које мора сам да обави SSH сервер.
Апликација која говори само SOCKS нема са чим да разговара на обичном VPN-у, јер тунел преноси пакете, а апликација жели прокси завршну тачку. OpenSSH може да обезбеди ту тачку када власник приступа то дозволи, јер динамичко прослеђивање претвара једну SSH сесију у локални прокси. Затим постоје два скока која треба држати одвојено: тунел који стиже до SSH хоста и веза коју тај хост даље отвара. Њихово раздвајање објашњава и зашто овај распоред ради и шта он никада неће урадити.
Шта SSH слушалац постаје, а шта не
Динамичко прослеђивање приморава SSH клијента да слуша локално и говори SOCKS4 или SOCKS5 са свим што се повеже. Сваки захтев именује одредиште и SSH сервер отвара следећу везу, због чега тражење одредишта може да се догоди на даљој страни. То је TCP прослеђивање на нивоу апликације, а не VPN за цео уређај. Не преноси UDP придруживање, ни ICMP, ни било шта за апликације које потпуно игноришу подешавања проксија. Ни скок од SSH сервера до апликације није унутар вашег тунела, што је важно када одредиште прихвата саобраћај само из познатих мрежа.
Предуслови су стварни: рута до SSH хоста, овлашћен налог, проверени кључ хоста сервера и дозвола за прослеђивање. Ниједан од њих не ствара прокси, а последњи обично први недостаје. Потврдите сва четири пре него што будете поправљали било шта друго, јер са клијента грешка изгледа исто, који год да недостаје.
Покрените га на loopback-у са јасним портом
Изаберите неискоришћен локални порт и јасно га повежите са loopback-ом уместо да адресу оставите празну. Три опције испод постоје свака из једног разлога.
ssh -D 127.0.0.1:1080 -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
[email protected]-N прескаче далеку команду, а -T прескаче псеудотерминал, тако да сесија постоји само за прослеђивање. ExitOnForwardFailure тера клијента да изађе када слушалац не може да се створи, уместо да ради без затраженог прослеђивања. ControlPath=none држи сесију изван постојеће мултиплексиране везе која би могла да дода своја прослеђивања. Loopback држи слушаоца изван LAN-а, али на дељеном рачунару то није граница овлашћења, јер и други локални процеси могу да му приступе. Референца OpenSSH клијента документује све ове опције, а упозорење о loopback-у произлази из тога шта је сокет који слуша.
Шаљите имена кроз прокси, а не око њега
SOCKS5 клијент може сам да реши одредиште или да замоли прокси да то уради, и тај избор одређује који ће резолвер да одговори. Са socks5h curl шаље име хоста кроз прокси, тако да се тражење обавља на SSH серверу. Са обичним socks5 преносни рачунар први решава и путује само веза, што тихо поништава сврху када је име интерно. Захтев испод такође празни листу без проксија, тако да наследна вредност NO_PROXY не може да га одведе око проксија.
curl -sS --noproxy '' --proxy socks5h://127.0.0.1:1080 https://app.corp.example/healthПровера сертификата и сопствена пријава апликације и даље важе, јер прокси не замењује ни једно од тога. Остају два тражења: преносни рачунар мора да стигне до SSH хоста дозвољеним путем VPN-а и DNS-а, а SSH сервер мора сам да реши име апликације. Друго се може тестирати одвојено пре него што било који саобраћај прође кроз прокси.
ssh [email protected] getent hosts app.corp.exampleДокажите једно дозвољено одредиште, па затворите сесију
Тестирајте одредиште које политика дозвољава и оно које би требало да одбије, јер прослеђивање које ради доказује само да слушалац ради и ништа више. Апликација види изворну адресу коју бира SSH сервер, а то није адреса тунела вашег преносног рачунара. Тамо где даља страна бележи везе по извору, та разлика је прво што треба проверити када захтев буде одбијен.
Зауставите сесију кроз процес који је поседује, уместо да убијете неповезану љуску. Затим потврдите да је слушалац нестао, јер порт који још одговара је сесија коју заправо нисте затворили. Уклоните само подешавање проксија које је увела ова вежба, а остатак конфигурације апликације оставите на миру. Ненадгледани терминал са правилом прослеђивања није услуга, и сталном проксију је потребан одобрен животни циклус, а не заборављен прозор.
ss -ltn | grep 1080Откази које овај распоред не може да исправи
Неки симптоми указују директно на горње границе, а њихово рано препознавање штеди једно поподне отклањања грешака проксија. Табела повезује оно што видите са оним што то обично значи. Све у последњој колони је питање дизајна, а не грешка у конфигурацији.
| What you see | What it usually means | Where to look |
|---|---|---|
| The app connects and nothing follows | It ignores proxy settings entirely | Its own network settings, not the SSH session |
| A name resolution error for the destination | The SSH server cannot resolve it | Server resolver and search domains |
| A UDP-only application fails | Dynamic forwarding carries TCP only | This arrangement cannot serve it |
| curl works, the browser does not | The browser is not using the socks5h endpoint | Browser proxy configuration |
| The listener answers after the session ended | Another process owns port 1080 | The ss output, then the owning process |
Прва три реда су она која људи погрешно дијагностикују, јер сваки даје покушај везе уместо грешке о самом проксију. Име које се реши на преносном рачунару не говори ништа о резолверу сервера, а отказ се уместо тога чита као проблем са сертификатом или временским ограничењем. Апликације само са UDP стоје изван дизајна, а не покварене унутар њега, и никаква додатна ssh опција то не мења. Ред о прегледачу је уобичајени подсетник да подешавања проксија важе за сваку апликацију посебно. Последњи ред је разлог зашто провера при затварању постоји: порт који још слуша значи да га сада поседује нешто друго.