Сокетын хос эсвэл дамжуулсан толгой: аль хаягт итгэх вэ?

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

Ямар нэг зүйлийг харьцуулахын өмнө замыг тайлбарлана уу:

Client -> approved reverse proxy -> application origin

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

Хаягийн хоёр төрлийн нотолгоо

Сокетын хос нь нэг TCP холболтын тухай баримт юм: ямар нэг зүйл тэр хаягаас гар барилтыг дуусгасан. Энэ нь танд чухал хүн, төхөөрөмж эсвэл бүртгэл байх албагүй, учир нь VPN эсвэл Tor гарц нь үйлчилгээний ажиглаж буй эх сурвалж байх нь хууль ёсны юм. Гэсэн хэдий ч энэ нь хост өөрөө баталгаажуулсан цорын ганц хаяг хэвээр байгаа бөгөөд түүний бүх үнэ цэнэ нь энэ юм.

Дамжуулалтын талбар нь гинжин хэлхээний тухай мета өгөгдөл юм. X-Forwarded-For, X-Real-IP болон стандартчилагдсан талбар Forwarded тэдгээрийг эргүүлэн илгээдэг төгсгөлийн цэгт хүрсэн аливаа клиент бичиж болох тул тэдгээрийн найдвартай байдал нь тэдгээрийг тогтоох эрхийг хэнд олгосон хамаарна.

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

Толгой холболтыг хэзээ ч дахин чиглүүлдэггүй

Дамжуулалтын талбарт хаяг бичих нь серверт ирж буй TCP холболтын эх сурвалжийг өөрчлөхгүй бөгөөд замын аль ч хэсэгт чиглүүлэлтийг өөрчлөхгүй. Энгийн VPN чиглүүлэлт эсвэл эх NAT нь ямар ч HTTP толгойгүйгээр урсгалыг хүргэдэг. Үүнтэй адил транзит гарц нь TLS төгсгөлийн цэгийн зохион байгуулалтыг өөрчлөхгүйгээр зөв хамгаалагдсан HTTPS солилцоог дахин бичихгүй.

Эсрэг алдаа мөн адил түгээмэл: HTTPS нь клиентийн өгсөн дамжуулалтын толгойг үнэн болгодоггүй. Энэ нь худал мэдэгдлийн тээврийг үнэнийхтэй адил сайн хамгаалдаг.

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

Мэдэгдэх эрхтэй проксиг нэрлэнэ үү

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

NGINX-ийн бодит IP модуль хуваагдлыг тодорхой харуулдаг. set_real_ip_from мэдэгдэл нь тооцогдох илгээгчдийг нэрлэдэг бөгөөд real_ip_header аль талбар үүнийг зөөж байгааг хэлдэг; эхнийх нь итгэлцлийг гүйцэтгэдэг, хоёр дахь нь зөвхөн хаана харахыг хэлдэг.

set_real_ip_from 10.20.0.0/24;
real_ip_header X-Forwarded-For;
# real_ip_recursive off - take the rightmost value in the field
# real_ip_recursive on  - walk the list back past every trusted address

Зөвхөн толгой сонгох заавар нь утгыг хэн илгээсэн тухай өөрөө юу ч тогтоодоггүй.

Тээврийн аюулгүй байдал нь таны итгэдэг бүрэлдэхүүн хэсгүүдийн хооронд бүх замыг туулах ёстой. Зөв хэвийн болгодог ирмэг нь доорх хамгаалалтгүй үсрэлт хэн нэгэнд мэдэгдлийг замд нь засах боломж олгосон мөчид тэр үнэ цэнийг алддаг.

Олон үсрэлттэй гинжийг санаатайгаар зохицуулаарай

Хэд хэдэн прокси тодорхой гинжин загвар шаарддаг. Ямар нэг блог нийтлэл тэгж хийсэн гэж таслалаар тусгаарлагдсан хамгийн зүүн эсвэл баруун утгыг бүү ав; таны проксиудын аль нь нэмж, аль нь орлуулж, аль нь ирж буй талбарыг хадгалдагийг олж мэдээрэй. Жишээлбэл, NGINX жагсаалтыг өөрийн итгэмжит олонлог руу буцаж явж, өөрт хамаарахгүй эхний хаяг дээр зогсож чаддаг бөгөөд энэ нь тэр бүтээгдэхүүний дүрэм, фрэймворк бүр дагадаг хууль биш юм. Өөрийн проксийн баримт бичгийг мөн адил хоёр асуулттай уншаарай: аль утгыг сонгодог, аль илгээгчдэд итгэдэг вэ?

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

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

Хоёр ажиглалтыг бүртгэлд хадгалаарай

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

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