NAT-ын ард байгаа ажлын станцад порт дамжуулалтгүйгээр хүрэх
Орж ирэх портгүй ажлын станцад ч хаб, реле эсвэл аппын брокероор хүрч болно. Нэгийг сонгохын өмнө загвар бүр юуг баталгаажуулдгийг харьцуулна уу.
Операторын NAT-ын ард байгаа хоёр төгсгөлийн цэг болон түгжээтэй оффисын чиглүүлэгч дамжуулах ямар ч орж ирэх порт үлдээхгүй байгаа ч зөн совингоор нэгийг гуйх хэвээр байна. Илүү сайн асуулт бол аль тал гадагш залгаж чадах, ямар хүрэх боломжтой үйлчилгээнд трафик зөөхийг зөвшөөрсөн бэ гэдэг юм. Дөрвөн загвар энэ асуултад өөр өөрөөр хариулж, зам хаагдсан үед өөр өөрөөр бүтэлгүйтдэг. Тэдгээрийн дундаас сонгох нь протоколын нэр биш, баталгааны харьцуулалт юм.
Дөрвөн загвар, дөрвөн өөр амлалт
Доорх хүснэгт бол товч хувилбар. Дунд баганыг туршиж болох амлалт гэж, баруун баганыг хэн ч өгөөгүй амлалт гэж уншина уу.
| Design | Who initiates | Promise you get | Promise you do not get |
|---|---|---|---|
| Routed VPN hub | Both ends, outbound to the hub | A routed path to permitted prefixes | Access to services no policy allows |
| Peer traversal with ICE | Both peers to a rendezvous service | A path tested between the two peers | A direct path through every NAT |
| TURN relay | Client outbound to a relay | Transport that survives symmetric NAT | Peer discovery or a usable directory |
| Application broker | Workstation outbound to a broker | One audited application session | Subnet-wide reachability |
Аль мөр хамаарах нь сонголтоос биш, ажлаас хамаарна. Нэг алсын ширээний сесс, нэг администраторын бүрхүүл, бүхэл хувийн дэд сүлжээнд хандах эрх — эдгээр нь нэг ижил орох цэг шаарддаггүй гурван шаардлага бөгөөд санамсаргүйгээр нэг машинтай холбоотой байсан ч хэвээр.
Хаб нь хэн гадагш залгахыг өөрчилдөг, юуг зөвшөөрөхийг биш
Чиглүүлэлттэй хаб загварт алсын зөөврийн компьютер болон ажлын станц, эсвэл түүний урд байгаа сайтын гарц хоёулаа хүрч чадах үйлчилгээ рүү гардаг шугам нээнэ. Ажлын станцын чиглүүлэгч дээр юу ч хүсээгүй холболтыг хүлээж авахгүй бөгөөд яг ийм учраас энэ загвар NAT-ыг давж, сайтад статик хаяг байхгүй ч ажилладаг. Дараа нь хаб өөрийн бодлогын дагуу хоёр дотоод хаягийн хооронд трафикийг чиглүүлнэ.
Үнэ нь хаб байх ёстой, хоёр талаас хүрэх боломжтой байх ёстой, хэн нэгэн ажиллуулах ёстой. Гардаг шүүлтүүр нь тээврийг зөвшөөрөх ёстой бөгөөд түүнийг хаадаг сүлжээ нь порт дамжуулалт шаардлагагүй байсан ч загварыг сүйтгэнэ.
Нарийн хэсэг нь хүрэх боломж ба эрх олголт нь өөр өөр газарт гаргадаг тусдаа шийдвэр юм. Префикс рүү чиглэсэн зам нь ажлын станц дээрх аль үйлчилгээг таних тэмдэг ашиглаж болохыг хэлэхгүй, шугамыг зөвшөөрсөн галт ханын дүрэм нь бүртгэл нэвтэрч чадах эсэхийг хэлэхгүй. Хоёуланг тохируулж, хоёуланг туршиж, эрх олголтын шийдвэрийг чиглүүлэлтийн хүснэгтэд биш, нөөцийг эзэмшдэг системд үлдээгээрэй.
Нэвтрэлт нь хоёр стек үүнийг хэрэгжүүлсэн үед л ажиллана
Тэнцүү зангилааны хоорондын нэвтрэлт нь тодорхой системийн чадвар бөгөөд VPN-ийг сайжруулах тохиргоо биш. Interactive Connectivity Establishment хэд хэдэн нэр дэвшигч хаягийг цуглуулж, нэг нь ажиллах хүртэл хосыг туршина: орон нутгийн интерфейс дээрх хост нэр дэвшигчид, NAT-ын илчилсэн зүйлээс баригдсан серверийн тусгал нэр дэвшигчид, реле дээр хуваарилагдсан релений нэр дэвшигчид. Ганц хувийн хаяг нь зам биш, учир нь нөгөө тал тэнд чиглүүлж чадахгүй.
Релений тохиолдлыг хасахын өмнө ойлгох нь зүйтэй. RFC 8656 нь TURN-ыг клиент серверээс релеэр дамжсан тээврийн хаяг гуйж, сервер тэр клиент болон түүний тэнцүү зангилааны хооронд трафик дамжуулдаг протокол гэж тайлбарладаг. Тиймээс өгөгдлийг реле зөөнө, энэ нь зөвхөн төгсгөлийн цэгүүдэд уулзахад тусалдаг лавлахаас мэдэгдэхүйц ялгаатай. Релений хаягийг нөгөө талтай солилцох нь апп хийх ёстой зохицуулалтын алхам юм.
Таны амлаж чадахгүй зүйл бол шууд зам юм. Симметрик NAT болон зарим корпорацийн галт хана нүх өрөмдөхийг сүйтгэдэг бөгөөд ийм үед систем реле рүү буцах эсвэл бүтэлгүйтдэг. Орчуулсан хоёр төгсгөлийн цэг хэзээ ч ярьж чадахгүй гэж дүгнэж болохгүй; релений нөөцтэй дэмжигдсэн стек нь тэд ихэвчлэн ярьж чаддаг учраас л байдаг. Боломжтой байдал эсвэл шууд байдал аль нь чухал болохыг шийдээд, таатай тохиолдлыг таамаглахын оронд байршуулалт бодитоор аль замыг сонгосныг шалгана уу.
Брокер нь сүлжээнээс илүү нарийн
Шаардлага нь нэг апп байх үед аппын брокер эсвэл ажлын станцаас эхэлсэн урвуу холболт нь хамгийн бага хариулт байж болно. Ажлын станц брокер рүү гадагш залгаж, брокер алсын хэрэглэгчийг баталгаажуулж, зөвхөн тэр аппын сессийг зөөнө. Ажлын станцын дэд сүлжээ рүү ямар ч зам үүсэхгүй тул алсын сессийн эвдрэл хажууд байгаа бүх төхөөрөмж рүү замыг өвлөхгүй.
Энэ нарийн байдал үнэтэй: нэмэлт апп бүр өөрийн интеграци шаарддаг бөгөөд апп орон нутгийн сүлжээний талаар таамагладаг зүйл, жишээ нь ойролцоох сервер дээр нээдэг файл хуваалт, хүрэхгүй байж болно. Брокерууд бодлого, логыг нэг газар төвлөрүүлдэг нь тэр газар тасалдал болох хүртэл ашигтай.
Итгэлийн хил хязгаарыг харьцуулаад, дараа нь замыг туршина уу
Шугамыг дуусгадаг хаб нь өөрийн чиглүүлж буй трафикийг уншиж чадна. Апп төгсгөлөөс төгсгөл хүртэл шифрлэх үед реле бие даан хамгаалагдсан солилцоог зөөж чадна, брокер ихэвчлэн өөрийн танилцуулж буй сессийг дуусгадаг. Хоёулаа шифрлэгдсэн гэж хоёр загварыг тэнцүү гэж шийдэхийн өмнө хамгаалалт бодитоор хаана дуусдагийг тогтооно уу.
Дараа нь ажлын станц гадагш бодитоор хаа хүрдэгийг шалгана уу, учир нь дээрх загвар бүр үүнээс хамаардаг. Үүнийг ажлын станц дээр ажиллуулж, ашиглахаар төлөвлөж буй хостын нэрийг орлуулна уу.
ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.comЗөвшөөрөгдсөн таних тэмдгийн дор зорьсон алсын үйлдэл амжилттай болсны дараа, зөвшөөрөөгүй таних тэмдэг татгалзагдсаны дараа, шууд эсвэл релений зам байхгүй үеийн зан төлөв мэдэгдэж, баримтлагдсаны дараа л загварыг хүлээн авна уу. Дахин холбогдох болон ажлын станцын ердийн эхлэх контекстийг оруулна уу, учир нь оффис дээр LAN-аар эхэлсэн сесс алсын хандалтаас хамаарах юуг ч туршихгүй.