Хамтарсан дэд домэйн, хоёр орох хаалга: хэн ямар бүртгэлийг хардаг вэ?

A эмнэлэг болон B эмнэлэг нэг кодын сан, хоёр дэд домэйн, оффис болон VPN-ээр ирсэн зочдын холимогийг хуваалцдаг. Сүлжээний багууд ихэвчлэн хоёр орох хаалгыг тусад нь тохируулдаг бөгөөд энэ нь хэвийн, хэрэв программа тэгэхгүй бол. Доорх шалгалтууд програмд байх ёстой бөгөөд хүсэлт аль хаалгаар орсоноос үл хамааран адилхан ажиллах ёстой.

Нэгдүгээрт: хостын нэр зөвхөн түрээслэгчийг нэрлэдэг

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

Нэг хостын нэрийн хайлтаас контекст болон зөвшөөрлийг хоёуланг нь буцаадаг хуваалцсан туслах функц нь алдааны эхлэл юм.

Хоёрдугаарт: гишүүнчлэл сессээс ирдэг

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

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

Cookie-ийн хамрах хүрээ болон нэг удаагийн нэвтрэлт нь бүртгэлийг хаана танилцуулж болохыг тодорхойлно. Тэд тэр бүртгэл юу уншиж болохыг тодорхойлохгүй.

Гуравдугаарт: сүлжээ хүний тухай юу ч батлахгүй

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

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

Ханан дээр наах нэг өгүүлбэр: сүлжээ хүсэлт хэрхэн ирэхийг, програм юу уншиж болохыг шийддэг.

Дөрөвдүгээрт: матрицыг хоёр орох хаалга дээр ажиллуул

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

curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-b.example.com/records/42
curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-a.example.com/records/42

Дараа нь зөвшөөрлийн жагсаалтын нэг бичлэгийг өөрчилж дахин ажиллуул. Хөдөлсөн үр дүн нь сүлжээний хяналт зөвшөөрлийн шийдвэр гаргаж байгааг илтгэнэ.

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