Нэг замыг батлах хоёр peer-тэй WireGuard тестийг хэрхэн барих вэ

Өгөгдмөл маршрут, LAN префикс, DNS болон firewall-ийн үл хамаарах зүйлийг агуулсан WireGuard тест аль нь эвдэрснийг хэлж чадахгүй. Үүнийг хоёр peer, нэг хос хаяг, нэг зөвшөөрөгдсөн үйлчилгээ болтол багасгавал алдаа нуугдах газаргүй болно. Уйтгартай суурь нь өөрөө оношилгоо юм. Эхлээд үүнийг барь; арван таван минут шаардаж, эс бөгөөс таамаглахад зарцуулах үдээс хойшийг хэмнэнэ.

Суурь нь юу баталж байгаа нь ихэнх хүмүүсийн хүлээж байгаагаас нарийн юм. Энэ нь хоёр таних тэмдэг санал нийлж байгаа, UDP сонсох портод хүрч байгаа, нэг зөвшөөрөгдсөн очих газар хүсэлт зөөж байгааг батална. Forwarding, NAT, LAN маршрут болон DNS нь дараа нэг нэгээр нэмэгдэх тусдаа функцууд.

Түлхүүр, хаяг болон ганц endpoint

Систем бүр дээр түлхүүрийн хос үүсгэж, тэдгээрийн хооронд зөвхөн нийтийн хагасыг шилжүүл. wg genkey | tee privatekey | wg pubkey > publickey нь баримтжуулсан нэг мөрт команд бөгөөд хувийн түлхүүрийг дараа нь хамгаалж болох файлд үлдээнэ. Туннелийн хаягийг таны өөр ямар ч тохиргоонд тохиолдохгүй мужаас сонго, жишээ нь 10.99.0.1/24 ба 10.99.0.2/24. Аль хаяг аль машинтай холбоотойг бичиж аваарай, учир нь дараагийн шалгалт бүр энэ тохиролцооноос хамаарна.

Хувийн түлхүүр хэзээ ч аялахгүй. Тест нэгийг нөгөө тал руу хуулах шаардлагатай бол тест аль хэдийн буруу болсон. Хоёр систем NAT-ийн ард байвал ядаж нэгэнд нь хүрэх боломжтой UDP порт хэрэгтэй, нөгөө нь түүн рүү заасан Endpoint авч явна, нийтийн хаяг болон порт нь 51820-ийн тухай таамаглалд биш, бичлэгт чинь байх ёстой.

Өөр гадаад порт руу буулгадаг порт forwarding нь Endpoint тохирч байгаа тохиолдолд сайн ажилладаг. Эндхийн зөрүү алдаа биш чимээгүй байдал үүсгэдэг, тиймээс утсан дээр дибаг хийхээс өмнө цаасан дээр шалгах нь зүйтэй.

wg-д хамаарах талбарууд болон хамаарахгүй нь

Гол талбарын багц бага: Interface дор PrivateKey ба ListenPort, Peer дор PublicKey, AllowedIPs ба Endpoint. Address ба DNS нь wg-ийн өөрт нь биш, wg-quick-д хамаарна, мөн ижил тохиргоо өөр хэрэгсэл рүү шилжих тэр мөчид энэ ялгаа хазуулна.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs нэгэн зэрэг хоёр ажил хийнэ. Аль очих газрууд туннельд орохыг сонгох бөгөөд ирэх үед тэдгээр эх хаягийг ашиглах эрхийг peer-т өгнө. Тиймээс нөгөө талын толь бичлэг таны туннелийн хаягийг яг нэрлэх ёстой; буруу peer-ийн /32 нь маршрутын асуудал мэт уншигдаж, зөвшөөрлийн асуудал мэт ажиллана. WireGuard хурдан эхлэл талбарын нэрийг харьцуулахыг хүсвэл ижил хоёр peer хэлбэрийг канон хэллэгээр харуулна.

Дүрсний оронд гар барилтыг унших

Интерфэйсийг эзэмшиж байгаа зүйлээр өргөөд, дараа нь статусын гэрэл биш төлөвийг унш. wg show peer бүрийн хамгийн сүүлийн гар барилтыг байт тоолууртай хамт хэвлэдэг, сүүлийн хэдэн минутын доторх гар барилт нь түлхүүр, endpoint болон UDP зам бүгд ажиллаж байгааг илэрхийлнэ. Зөвхөн нэг чиглэлд өсдөг тоолуур нь өөрийн хариулт бөгөөд энэ нь хэзээ ч болдоггүй гар барилттай ижил гэмтэл биш.

Хоёр гэмтэл өөр өөр шалгалтыг илэрхийлнэ. Гар барилт огт болохгүй байх нь түлхүүрийн зөрүү, буруу Endpoint, хаагдсан UDP эсвэл гар барилтыг өөрөө унагадаг firewall-д заана. Гар барилт амжилттай болж, өгөгдөл хаашаа ч явахгүй бол энэ нь AllowedIPs, туннелийн хаяг дээр сонсдоггүй үйлчилгээ, эсвэл портыг LAN-д хүлээн авдаг ч туннелийн интерфэйсэд хүлээн авдаггүй хост firewall-д заана. Эдгээр нь системийн өөр өөр хагас бөгөөд дүрэм өөрчлөхөөс өмнө суурь нь тэдгээрийг тусгаарладаг.

Нэг зөвшөөрөгдсөн үйлчилгээг батлах, дараа нь эсрэг чиглэл

Нөгөө peer-ийн туннелийн хаяг руу хариу өгөх ёстой үйлчилгээнд хүсэлт илгээж, ping-ээс дээр зүйлийг сонго. ICMP хариу байхгүй байх нь туннелийн гэмтэл биш хост шүүлт байж болох тул чимээгүй ping аль ч чиглэлийг батлахгүй. Нээлттэй гэдгийг чинь мэддэг порт руу TCP холболт, эсвэл өгөгдөл буцаадаг хүсэлт нь тайлбарлаж болох хариулт өгнө.

Эсрэг чиглэлийг өөрийн үр дүнтэй тусдаа тест болгон ажиллуул, учир нь хоёр чиглэл тусдаа firewall болон AllowedIPs бичлэгтэй бөгөөд бие даан бүтэлгүйтэж болно. Гар барилт ажиллаад хүсэлт ажиллахгүй бол асуудал туннельд биш, өгөгдлийн замд байна: AllowedIPs, сонсож байгаа үйлчилгээ эсвэл хост firewall. Forwarding, NAT эсвэл DNS нэмэхээс өмнө үүнийг зас, тэгэхгүй бол хэзээ ч буруутан байгаагүй функцийг дибаг хийж үдээс хойшийг өнгөрөөнө.

Суурийг жишиг болгон хадгалах

Ажиллаж байгаа топологи болон профайлын эх сурвалжийг сэргээж болох газар хадгал, мөн нийтийн үйлчилгээтэй синхрончлогддог ямар ч хавтаснаас гадуур байлга. Дараа нь нэг удаад нэг функц нэмж, тус бүрийн дараа анхны хүсэлтийг давт: forwarding, NAT, LAN маршрут, дараа нь л DNS. Тестийг эвдэж буй нэмэлт бүр одоо танигдахуйц, учир нь өөр юу ч хөдөөгүй.

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