Гэрийн VPN серверт динамик DNS хэрэгтэй юу?

Динамик DNS нэрийг засдаг, орох замыг засдаггүй. Гурван шалгалт нэрийн хост гэрийн VPN серверт хангалттай эсэх, эсвэл орох зам эвдэрсэн эсэхийг шийднэ.

Хүмүүсийн надаас асуудаг гэрийн VPN-ийн алдааны дийлэнх нь DNS-ийн алдаа биш боловч тэд эхлээд динамик DNS-ийн захиалга авдаг. Юу ч хийхээс өмнө хост нэр эвдэрсэн хэсэг мөн эсэхийг шийдээрэй. Шинэчлэгч нийлүүлэгчийн өгсөн хаяг шилжих үед бичлэгийг дахин бичдэг; энэ нь порт нээх, операторын NAT-ыг нэвтрэх, эсвэл ажиллаж буй WireGuard сессэд түүний төгсгөлийн цэг өөрчлөгдсөнийг мэдрүүлэх боломжгүй. Динамик DNS бүх шийдэл үү, эсвэл түүний зөвхөн нэг мөр үү гэдгийг гурван нөхцөл шийднэ.

Нэгдүгээр нөхцөл: таны хаяг үнэхээр шилждэг

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

Таамаглахын оронд хэмжинэ. Роутерын төлөвийн хуудаснаас WAN хаягийг уншаад, гадаад ертөнцийн харж буй утгатай харьцуулна. Үүнийг LAN дахь машинаас ажиллуулна:

curl -fsS https://api.ipify.org; echo

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

Хоёрдугаар нөхцөл: клиентүүд нэрийг дахин хайдаг

Богино TTL бол хүмүүсийн алгасдаг хэсэг. Рекурсив шийдэгчид бичлэгийн TTL-ийг хүндэтгэдэг боловч клиентийн стекүүд тусдаа кэш хийдэг, аль хэдийн боссон туннель юу ч дахин шийддэггүй. Алдаа засах үед бичлэгийг 60-300 секундэд тохируулна; энэ нь хуучирсан хариулт өгөх цонхыг богиносгож, холбогдсон сессийг шилжүүлэхгүй.

OpenVPN дахин холбогдох бүрт мөрийг remote vpn.example.net 1194 дахин шийдэж, resolv-retry infinite хайлт бүтэлгүйтэх үед гарахын оронд дахин оролдохыг албаддаг. Сервер дээр float тогтсон сессэд эх хаяг нь өөрчлөгдсөн түншийг дагахыг зөвшөөрдөг. WireGuard илүү шууд: wg-quick up тохиргоог хэрэглэх үед Endpoint -г шийдэж, клиент туннелийг дахин барихдаа дахин шийддэг, тиймээс хуучин хаяг руу одоо ч амжилттай болж буй гар барилт зогсох хүртэл амжилттай хэвээр байна.

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

Гуравдугаар нөхцөл: орох зам одоо ч нээлттэй

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

Гаднаас туршиж үзээрэй. Wi-Fi унтраасан гар утасны өгөгдөл дээрх утас хамгийн хямд шударга тест; мөн LAN дахь зөөврийн компьютер тийм биш. Нэр таны нийтийн хаяг руу шийдэгдэж, роутерт NAT гогцоо байхгүй үед дотоод тест бүтэлгүйтдэг ч бичлэг бүрэн зөв байдаг, энэ нь ихэнх хүмүүсийг хэзээ ч буруу байгаагүй бичлэгийг засварлахад илгээдэг.

Гурвуулаа биелэх үед юу ажиллуулах вэ

Жижиг хостод ddclient хамгийн бага гайхмаар шинэчлэгч юм. Хамгийн бага тохиргоо нь нийлүүлэгчийн харж буй хаягийг нийтэлдэг бөгөөд энэ нь давхар NAT-ын алдааг тойрч гардаг:

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

Үүнийг shell давталтын оронд хэдхэн минут тутамд systemd таймераас ажиллуулж, амжилтыг таамаглахын оронд нийлүүлэгчийн хариуг бүртгэ. Итгэмжлэлийг түлхүүр мэт үзээрэй, учир нь клиент бүр хаашаа илгээгдэхийг тэр шийддэг: бүртгэлийн нууц үгийн оронд хязгаарлагдмал шинэчлэлийн токен ашиглаж, файлыг 0600 горимд байлгаж, шинэчлэлүүдийг HTTPS-ээр илгээ.

Амлалт өгөхөөс өмнө шалга

Нэг хайлт үлдсэн ертөнц юу харж буйг хэлж, өөрчлөлтийн дараа хүлээх TTL-ийг хэвлэнэ:

dig +noall +answer vpn.example.net @1.1.1.1

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

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

Хариулт нь үгүй үед

Хэрэв нэгдүгээр эсвэл гуравдугаар нөхцөл бүтэлгүйтвэл тохиргоо биш шийдвэр өөрчлөгдөнө. Операторын NAT-ын ард таны практик сонголт бол нийлүүлэгчээс нийтийн хаяг хүсэх, орох цэгийг тогтвортой хаягтай жижиг VPS руу зөөх, эсвэл өөрийн уулзалтыг хадгалдаг бүрхүүл ашиглах юм. Хэрэв хаяг статик бол шинэчлэгчийг алгас: нэг A бичлэг, IPv6 ашигладаг бол нэг AAAA бичлэг, ижил порт дамжуулалт.

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

Урагшлахын өмнө дөрвөн зүйлийг дараалан баталгаажуул:

  • Шинэчлэгчийн нийтэлсэн хаяг роутерын WAN хаягтай таарч байна.
  • Бичлэгийн TTL нь өөрчлөлт хэдхэн минутад харагдахуйц богино.
  • Порт дамжуулалт интерфейстэй холбогдсон, тогтмол хаягтай биш.
  • Сүүлийн өөрчлөлтөөс хойш нэг бодит клиент дахин холбогдож трафик дамжуулсан.

Хэрэв дөрвүүлээ биелбэл тохиргоог тайван орхи; таны дараагийн алдаа нэршилийн асуудал биш түлхүүр эсвэл галт хананы дүрэм. Хэрэв аль нэг нь бүтэлгүйтвэл өөр нэг хөдөлгөөнт хэсэг нэмэхээс өмнө тэр мөрийг зас. RFC 2136 нь шинэчлэлийн механизмыг өөрөө тайлбарладаг, демон утсан дээр юу тавьдагийг харъя гэвэл.

Холбоотой нийтлэлүүд