Яагаад Port-Share бүх вэбсайтын зочдыг localhost мэт харуулдаг вэ

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

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

Логын мөрийг биш, хоёр холболтыг дагаарай

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

ss -ltnp 'sport = :443'
ss -tnp 'dport = :8080'

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

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

Дамжуулалтын давхаргын дамжуулалт нь толгой шургуулах биш

Дамжуулагч байтуудыг зөөдөг. Энэ нь HTTP-г задлан шинжилдэггүй тул хэзээ ч хүсэлт гэж уншдаггүй хүсэлтэд толгой оруулж чадахгүй, мөн хөндөхгүйгээр дамжуулж буй TLS урсгалд юу ч нэмж чадахгүй. Прокси толгой хүлээж буй модуль аль ч бүрэлдэхүүн үйлдвэрлэдэггүй нэгнийг үргэлжлүүлэн хүлээх болно.

Анхны хаягийг хоёр механизм зөөж болох бөгөөд хоёулаа хоёр төгсгөлд зөвшилцөл шаарддаг. PROXY протокол холболтын эхэнд жижиг толгой нэмдэг бөгөөд арын хэсэг үүнийг хүлээхээр тохируулагдсан байх ёстой; хүлээхгүй арын хэсэг тэдгээр байтыг хүсэлтийн эхлэл гэж үзэж, будлиантайгаар бүтэлгүйтнэ. X-Forwarded-For мэтийн итгэмжлэгдсэн прокси толгойнууд нь HTTP-г ойлгодог прокси тэдгээрийг тогтоож, аль хосууд тэдгээрийг баталж болохыг арын хэсэгт хэлсэн үед ажилладаг.

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

curl -sS -H 'X-Forwarded-For: 127.0.0.1' https://site.example.com/health
grep -F '127.0.0.1' /var/log/nginx/access.log | tail -n 3

Сонголтоор ашиглах эх сурвалжийн буулгалтын хавтас

Порт хуваалцах нь тухайн боломж хэрэгжсэн платформ дээр анхны эх сурвалжийн хаяг ба дамжуулах холболтын хоорондын буулгалтыг бүртгэдэг сонголтоор ашиглах хавтасны аргументтай. Вэб тал тэр буулгалтыг ашиглана гэж хүлээгддэг; энэ нь толгой биш бөгөөд хүсэлтэд шургуулагдахгүй.

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

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

Хаягийг аль бүрэлдэхүүн баталгаажуулахыг шийдээрэй

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

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

Ажиллахгүй зүйл бол дамжуулсан loopback хаягийг хүсэлт энэ машинд үүссэн гэдгийн нотолгоо гэж үзэх явдал юм. Тэр дүгнэлт нь яг эсрэгээрээ: хаяг байгаа шалтгаан нь локал бүрэлдэхүүн холболт үүсгэсэн явдал юм. Ингэж бичсэн дүрэм сонсогчд хүрч чадах хэнийг ч хүлээн авдаг.

Хуудсыг биш, дүрмийг туршаарай

Ачаалагдах хуудас нь дамжуулалтын зам ажиллаж байгааг нотолж, хамааруулалтын талаар юу ч хэлдэггүй. Хаягийн хэрэглэгчийг туршаарай: хандалтын дүрэм, хурдны хязгаар, аудитын бүртгэл, газарзүйн хайлт.

curl -sS -o /dev/null -w '%{http_code}\n' https://site.example.com/
tail -n 5 /var/log/nginx/access.log
grep -c '' /var/log/nginx/access.log

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

Байршуулалтын тэмдэглэлд хамааруулалтын гинжийг бичжээ дуусгаарай: аль сонсогч, аль дамжуулагч, аль толгой эсвэл буулгалт, аль арын хэсэг түүнд итгэхээр тохируулагдсан. Логын мөрийг унших дараагийн хүнд дөрөв нь бүгд хэрэгтэй бөгөөд тэр тэмдэглэл байхгүй байгаа нь ижил тасалбарыг нэг жилийн дараа дахин нээх шалтгаан юм. Үүнийг чатын урсгалд биш, тохиргооны хажууд хадгалаарай.