SSH дамжуулалт яг ямар аппын урсгалыг зөөдөг вэ?

Бүрхүүл, локал дамжуулалт, SOCKS болон туннелийн төхөөрөмжийн горим нь өөр өөр интерфейс санал болгодог. Апп тань ашиглаж болох интерфейсийг маршрутлагдсан VPN-тэй харьцуулахын өмнө нэрлээрэй.

Терминал холбогдож, prompt гарч ирэхэд бүгд SSH хандалт ажиллаж байгааг хүлээн зөвшөөрнө. Дараа нь зөөврийн компьютер дээрх өгөгдлийн сангийн клиент хувийн хостод хүрч чадахгүй хэвээр, сессийг буруутгадаг. Бүтээсэн зүйл нь бүрхүүл байсан бөгөөд энэ нь SSH санал болгож болох дөрвөн огт өөр интерфейсийн нэг юм. Эхлээд интерфейсийг нэрлэ, дараа нь апп үнэхээр ашиглаж байгаа эсэхийг шалга. Дараалал чухал, учир нь интерфейс бүр өөрийн аргаар бүтэлгүйтдэг.

Ямар нэг зүйлийг харьцуулахын өмнө интерфейсийг нэрлэ

OpenSSH клиентийн гарын авлага андуурахад хялбар дөрвөн механизмыг ялгадаг. Бүрхүүл эсвэл алсын команд нь SSH хост дээр ажилладаг. Локал дамжуулалт клиент дээр сонсдог socket нээж, дараагийн холболтыг алсын талаас хийдэг. Алсын дамжуулалт эсрэгээр ажиллаж, серверийн талд сонсдог. Динамик дамжуулалт үүнийг хэрхэн ашиглахаа мэддэг програмуудад SOCKS төгсгөлийн цэг санал болгодог.

  • Бүрхүүл: програм алсын машин дээр ажилладаг, локалд юу ч сонсдоггүй.
  • Локал дамжуулалт: зөөврийн компьютерт порт байна, алсын хост гадагшлах холболтыг хийдэг.
  • Алсын дамжуулалт: алсын талд порт байна, урсгал таны зүг буцаж ирдэг.
  • Динамик: клиент дээрх SOCKS прокси, зөвхөн проксиг ойлгодог аппууд ашигладаг.

Эдгээрийн аль нь ч маршрут суулгадаггүй. Прокси тохиргоог үл тоомсорлодог, эсвэл UDP-ээр ярьдаг, эсвэл нэрсийг өөрөө шийддэг програм, идэвхтэй SSH сессээр нөлөөлөгдөхгүй. Энэ нь SSH-ийн алдаа биш; энэ нь таны сонгосон интерфейсийн хүрээ юм.

Локал, алсын болон динамик дамжуулалт нь хэн сонсдогоороо ялгаатай

Ихэнх тохиолдлыг шийддэг ялгаа нь сонсдог socket хэнд хамаарах явдал юм. Локал дамжуулалтад клиент сонсож, алсын үзүүр очих газрыг залгадаг, тиймээс очих газрын хаяг серверийн өнцгөөс шийдэгддэг. Алсын дамжуулалтад сервер сонсож, холболт таны тал руу буцаж зөөгддөг, ингэснээр локал үйлчилгээг шууд нийтлэхгүйгээр ил гаргадаг.

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

Эхний команд зөөврийн компьютерт 5432 портыг холбож, бастионоос харагдах байдлаар өгөгдлийн сан руу дамжуулдаг. Хоёр дахь нь 1080 порт дээр SOCKS прокси үүсгэдэг. Гурав дахь команд аль процессууд үнэхээр сонсож байгааг баталгаажуулдаг бөгөөд портын зөрчилдөөнөөс болж чимээгүй бүтэлгүйтсэн биш, дамжуулалт байгаа гэдгийн цорын ганц нотолгоо юм.

Динамик дамжуулалт өөрийн анхааруулга хүртэх ёстой: энэ нь SOCKS-ийг хүндэтгэдэг аппуудыг л хамардаг. Хөтөчийг түүн рүү чиглүүлж болно, командын мөрийн хэрэгсэлд ашиглахыг хэлж болно, гэхдээ өөрийн холболтын стектэй өгөгдлийн сангийн драйвер ихэвчлэн чадахгүй. Машин дээрх бүх програм одоо туннелийг ашигладаг гэж үзэх нь энэ салбарын хамгийн түгээмэл алдаа юм.

Туннелийн төхөөрөмжийн горим бол цорын ганц жинхэнэ сүлжээний үл хамаарах зүйл

OpenSSH мөн -w туннелийн төхөөрөмжийн дамжуулалтыг дэмждэг бөгөөд энэ нь TCP сонсогчийн оронд цэгээс цэг рүү интерфейс дамжуулдаг. Энэ бол жинхэнэ сүлжээний туннель бөгөөд санаатайгаар тохируулагддаг, бүрхүүл нээхийн хажуугийн нөлөө биш.

sudo ssh -w 0:0 [email protected]
ip addr show tun0

Түүнд хоёр төгсгөлд боломжтой харгалзах интерфейсийн дугаарууд, сервер дээрх зөв тохиргоо, төхөөрөмжийг үүсгэхэд клиент дээр хангалттай эрх хэрэгтэй. Мөн ямар очих газрууд үүнийг ашиглах ёстой гэсэн бодлогыг нүцгэн интерфейс агуулдаггүй тул хаяг болон маршрутын төлөвлөгөө хэрэгтэй.

Тийм байсан ч туннель алсын хост дээр дуусдаг. SSH тээвэр ямар хамгаалалт өгсөн ч тэр нь тэнд дуусч, дараагийн холболт нь тусдаа үсрэлт юм. VPN гарц мөн ижил хэлбэрийн хилтэй тул харьцуулалт нь аль хэрэгсэл илүү хүчтэй вэ гэхээс илүү хүрээ, төгсгөлийн тухай байх ёстой. Тэр хилийг чанга дуугаар нэрлэх нь туннель «бүгдийг шифрлэдэг» эсэх тухай маргааныг ч шийднэ, учир нь энэ нь тодорхой шифрлэдэггүй.

Апп тань таны бүтээсэн интерфейсийг ашиглаж байгаа эсэхийг шалга

Шалгалт нь сесс бүрээр биш, апп бүрээр хийгддэг. Ажиллаж буй дамжуулалт порт холбогдсон, алсын тал залгаж чадна гэдгийг нотолдог; гэхдээ танд чухал програмын түүгээр холбогдсон гэдгийг нотолдоггүй.

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

Эхний команд хотын нэрийг алсаас шийдэж, SOCKS төгсгөлийн цэгээр хүсэлт илгээдэг бол хоёр дахь нь TLS одоо ч шаардлагатай байхад дамжуулсан өгөгдлийн сангийн портыг туршдаг. Дамжуулалтыг зогсоосон байдалд мөн адил шалгалтуудыг ажиллуулж бүтэлгүйтэх эсэхийг баталгаажуулаарай, учир нь хоёр замаар ч давдаг шалгалт туннелийг хэзээ ч ашиглаж байгаагүй.

Дараа нь маршрутлагдсан VPN-тэй зөвхөн чухал хэмжээсээр харьцуул: ямар очих газрууд хамрагдсан, ямар протоколууд ажилладаг, хамгаалалт хаана дуусдаг, хэн хандалтыг баталгаажуулах ёстой. Нэг үйлчилгээний дамжуулалт илүү нарийн, илүү сайн хариулт байж болох бол олон апп ижил сүлжээний зам шаарддаг үед VPN нь зөв хэлбэр юм. Аль нь ч өөрийн алсын төгсгөлийн цэгээс хүрч болох бүгдийг өгдөггүй.

Холбоотой нийтлэлүүд