Hairpin NAT: VPN-ийн төгсгөлийн цэг яагаад дотроос ажиллахгүй байна

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

Пакет гадагш гарч буцаж ордог

Пакетыг дагаарай. Клиент нийтийн нэрийг шийдэж, нийтийн хаягт холбогдож, маршрутизаторын очих газрын NAT очих газрыг дотоод сервер рүү дахин бичнэ. Серверийн хариу нь клиентийн LAN хаяг руу хаяглагдсан тул эх сурвалжийг буцааж хөрвүүлэх байсан NAT дүрмийг хэзээ ч давахгүйгээр маршрутизаторын LAN интерфэйсээр буцаж явна.

Одоо клиент хэзээ ч юу ч илгээгээгүй хаягаас пакет хүлээж аваад түүнийг хаяна. Энэхүү тэгш бус байдал нь бүх гэмтэл юм.

RFC 4787 энэ тохиолдолд NAT-аас хүлээгдэх зан төлөвийг тодорхойлдог бөгөөд товч хувилбар нь онолын хувьд тогтоосон газарт ч практикт заавал биш юм. Зарим маршрутизатор энэ тохиргоог NAT loopback гэж нэрлэдэг, бусад нь hairpin NAT эсвэл NAT reflection гэдэг, зарим нь юу ч харуулдаггүй. Энэ функцгүй маршрутизатор буруу тохируулагдаагүй; тэр энгийн зүйлийг хийж байгаа бөгөөд засвар нь өөр газар хамаарна. Локал туршилт бүтэлгүйтсэнээр нийтийн дамжуулах дүрэм буруу гэж дүгнэх хэрэггүй.

Шалгалт 1: хоёр замыг тус тусад нь шалгана

LAN-аас гадна бодит хэрэглэгчийн ашиглах профайлаар холбогдож, сесс үүсэж байгааг батална. Дотроос ижил профайлаар нийтийн хаягт холбогдож, яг алдаа болон цагийг тэмдэглэнэ.

Нарийн локал туршилт хост нэрийг хадгалж, зөвхөн хаягийг солино: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ хүсэлтийг нийтийн хаяг руу илгээхдээ зөв серверийн нэрийг танилцуулна. Энэ нь нэр шийдвэрлэх асуудлыг хөрвүүлэх асуудлаас тусгаарладаг бөгөөд ижил нэр кафедээс ажиллахад тэдгээрийг амархан андуурдаг. Клиент TCP холболт дээр унах уу эсвэл дараа нь TLS дээр унах уу гэдгийг тэмдэглээрэй, учир нь эхнийх нь хөрвүүлэлт, хоёр дахь нь таних тэмдэг рүү заана.

Шалгалт 2: сервер юу харж байгааг уншина

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

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

Шалгалт 3: гадаад замыг хөндөхгүйгээр засна

Гурван дэмжигдсэн хэлбэр байгаа бөгөөд нөлөөний радиус өсөх дарааллаар. Хамгийн нарийн нь хуваагдсан DNS: дотоод бүртгэл нийтэлж, ижил серверийн нэр LAN дахь клиентүүдэд дотоод хаяг руу шийдэгдэхээр болгосноор нийтийн замаас бүрэн зайлсхийнэ. Дараагийнх нь маршрутизаторын баримтжуулсан loopback эсвэл reflection сонголтыг асааж, зөвхөн энэ үйлчилгээнд хэрэглэх юм. Хамгийн өргөн нь маршрутизатор дээрх source-NAT дүрэм бөгөөд LAN-аас ирж буй урсгалыг сервер рүү дахин бичиж, хариу маршрутизатораар буцаж ирнэ; Linux маршрутизатор дээр энэ нь серверийн хаяг болон порттой таарах MASQUERADE дүрэм POSTROUTING болно. Гурвуулаа гадаад замыг хөндөхгүй үлдээдэг бөгөөд хамгаалах ёстой шинж чанар нь энэ юм.

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

Хуваагдсан DNS-д дурдах ёстой нэг урхи бий. Хост нэрийг дур зоргоороо IP-ээр солих нь клиентийн баталгаажуулах зүйлийг өөрчилдөг тул дотоод бүртгэл гэрчилгээний нэртэй тохирох ёстой хэвээр.

Шалгалт 4: дараа нь хоёр замыг шалгана

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

Бүртгэлийг богино байлгаарай: аль клиент аль хаягийг ашигласан, сервер юу харсан, гурван засварын алийг нь хэрэглэсэн. RFC 4787-гийн hairpinning шаардлагууд нь энд NAT-аас юу хүлээгдэж байгаагийн лавлагаа бөгөөд энэ функцгүй маршрутизатор яагаад хэвийн ажиллаж байгааг тайлбарладаг. Гадаад ертөнц давтаж чадахгүй локал бүтэлгүйтэл нь эсрэг нь батлагдах хүртэл хөрвүүлэлтийн асуудал тул түүнийг тийнхүү шалгаарай.