NGINX урсгалын релеэр SSH-г эвдэхгүй дамжуулах

PROXY толгой нь үүнийг хүлээж буй хүлээн авагчид зориулсан мессеж, прокси хийсэн DNS бичлэг нь TCP реле биш. Ирмэг болон дээд урсгалыг тус тусад нь засаарай.

Релеэр дамжих нийтийн SSH хоёр хамааралгүй хил дээр бүтэлгүйтдэг бөгөөд нэгийг засах нь ихэвчлэн нөгөөг илчилдэг. Нэг бол ирмэг урсгалыг зөөхийн оронд HTTP хариу буцаадаг, эсвэл реле бэкенд уншиж зөвшөөрөөгүй толгойг урд нь нэмдэг. Аль нь харж байгааг гурван нөхцөл тодорхойлно: нийтийн бичлэг үнэндээ юу руу зааж байна, урсгалын блок дээшээ юу илгээдэг, SSH клиент аль нэрийг шалгадаг. Тэдгээрийг энэ дарааллаар шийдээрэй.

Хоёр хил, хоёр шинж

Ирмэгийн алдаа нь SSH баннер байх ёстой газар HTTP төлөвийн хуудас ирж байгаа мэт харагдана. Холболт TCP түвшинд дуусаж, эхний байтууд нь вэб серверт хамаарах текст байна. Энэ нь протоколын зөрүү, алдагдсан пакет биш. Мөн ирмэг тэр нэрэнд зориуд өөр зүйл үйлчилж байгааг хэлж өгнө.

Дээд урсгалын алдаа өөрөөр харагдана. Холболт sshd-д хүрч, sshd хүлээж буй таних солилцоо биш байтуудыг уншиж, сесс хэзээ ч түлхүүр санал болголгүй үхэх эсвэл гацах болно.

Энэ хоёрыг төөрөгдүүлэхэд хялбар, учир нь хоёулаа холбогдоод дараа нь бүтэлгүйтдэг клиент үүсгэдэг. Хүлээн авсан эхний протоколын хариу л тэдгээрийг ялгадаг тул тэр нь тасалбарт байх ёстой.

PROXY толгой бол мессеж, унтраалга биш

Урсгалын модульд proxy_protocol on нь NGINX-д ачааллын өмнө дээд урсгал руу PROXY протоколын толгой бичихийг тушаадаг. Энэ нь TCP проксиг идэвхжүүлэхгүй бөгөөд SSH шифрлэлттэй ямар ч холбоогүй. Энэ нь хүлээн авагчид хаягласан тэмдэглэл юм. Хүлээн авагч үүнийг уншиж чадахгүй бол урсгалын эхэнд хог болно.

Хүлээн авагч үйлчилгээ тэр толгойг зориуд хэрэглэх ёстой. Энгийн sshd холболтын эхний байтууд болгон SSH таних солилцоог хүлээдэг тул гэнэтийн оршил гар барилтыг эвдэрсэн сервер мэт харагдах байдлаар эвддэг.

stream {
    server {
        listen 2222;
        proxy_pass 10.77.0.20:22;
    }
}

Тэр хэсэг нь VPN-ээр хүрэх боломжтой бэкендэд зориулсан бүрэн ажилладаг реле юм. Ямар ч PROXY заавар харагдахгүй, учир нь хүлээн авагч тэр протоколыг мэдэхгүй, энэ дутагдал нь орхигдуулалт биш шийдвэр юм.

Хоёр чиглэлийг ч тусгаарлаарай. listen мөрөнд proxy_protocol тохируулах нь NGINX өөрийн клиент эхлээд толгойг илгээнэ гэж хүлээж байгааг илэрхийлнэ; үүнийг энгийн SSH клиентэд идэвхжүүлэх нь хүмүүсийн ихэвчлэн шийдэх гэж оролддог асуудлын яг эсрэгээр үүсгэдэг.

Нийтийн хост нэр үнэндээ хаа хүрдэг

SSH сесс дэх HTTP 400 хуудас нь ирмэгийн талаарх нотолгоо. Замд ямар нэг зүйл HTTP ярьж байна, бэкенд дэх түлхүүр эсвэл бүртгэлийн ажил үүнийг өөрчлөхгүй. Ирмэг шийдэгдэх хүртэл бэкендийг өөрчлөхөө болиорой.

Cloudflare-ийн энгийн прокси хийсэн бичлэг дэмжигдсэн HTTP болон HTTPS хөдөлгөөнийг тодорхой портуудад зөөдөг. Хост нэрэнд прокси асаах нь ерөнхий TCP реле үүсгэхгүй, SSH-г 443 порт руу зөөх нь үүнийг HTTPS болгохгүй.

Хоёр хэрэгжих боломжтой чиглэл байна. Зөвхөн DNS бичлэг нь таны өөрийн TCP реле руу зааж болох бөгөөд энэ нь илрэлийн шийдвэрийг таны гарт үлдээнэ. Эсвэл SSH тээвэрлэлтийг тодорхой баримтжуулсан бүтээгдэхүүн ашиглах бөгөөд өөрийн гарал үүсэл, клиент, нэвтрэх тохиргоотойгоор.

Юу ч сонгосон, релед бэкенд рүү VPN зам, зөвшөөрөгдсөн холболт, буцах зам хэрэгтэй хэвээр. Нийтийн тал ажиллаж байгаа учраас зам нь заавал байх ёстой.

SSH таних тэмдгийг хочийн нэрээр тогтвортой бариарай

Хэрэглэгчид ихэвчлэн одоо байгаа хост нэрээ үргэлжлүүлэн бичихийг хүсдэг. SSH тохиргооны хочийн нэр нь релед юу ч өөрчлөхгүйгээр үүнийг хийж чадах бөгөөд өөрчлөлтийг клиентийн талд, өөрийн байх ёстой газарт үлдээнэ.

Host git.example.com
    HostName ssh-entry.example.net
    Port 2222
    User git
    HostKeyAlias git.example.com

Хэрэв HostKeyAlias тохируулаагүй бол OpenSSH хост түлхүүрийг холбогдож буй нэрийнх нь дор хайдаг тул бичлэг шилжиж, хэрэглэгч бүр анх ашиглахдаа түлхүүр өөрчлөгдсөн тухай анхааруулга харна. Хочийн нэрийг тохируулах нь known-hosts бичлэгүүдийг тогтвортой байлгаж, холболт реле рүү үргэлжлэн явна.

Энэ хочийн нэр зөвхөн SSH-д суурилсан алсын репозиторуудад хамаарна. HTTPS Git URL үүнийг авч үзэхгүй, ердийн алсын URL нь таны бодитоор бэлтгэсэн тээвэрлэлттэй тохирох ёстой.

Хийх ёсгүй зүйл бол анхааруулгыг арилгахын тулд хост түлхүүрийн шалгалтыг унтраах юм. Энэ нь дамжуулалтын засвар хэзээ ч хүрэхийг хүсээгүй хамгаалалтыг арилгаж, гадаад төрхийн тав тухгүй байдлыг бодит илрэл болгоно.

Үсрэлт бүрийг тусад нь шалгаарай

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

Үр дүн бүртэй хамт очих хаяг, порт, эхний протоколын байтуудыг хадгаарай. Тэр гурвал ирмэгийн алдааг VPN чиглүүлэлтийн асуудал болон SSH нэвтрүүлэлтийн алдаанаас ялгадаг бөгөөд энэ нь засвар ба таамаглалын ялгаа юм.

Эцэст нь, төлөвлөсөн илрэлийг баримтжуулаарай. SSH-г хувийн бэкенд рүү зөөдөг TCP реле нь нийтийн периметрт зориуд нээсэн цоорхой бөгөөд бусад аливаа нэвтрэх үйлчилгээний адил хяналтад хамрагдах ёстой.

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