Хоёр сайт, нэг дэд сүлжээ, нэг WireGuard төв зангилаа: ажиллуулаарай

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

Яагаад давхцал жинхэнэ асуудал биш вэ

WireGuard очих хаягаар дамжуулдаг: peer-ийн AllowedIPs нь аль peer пакетийг авахыг тодорхойлно. Хоёр peer нэгэн зэрэг 10.10.7.0/24 зарлаж чадахгүй, хэрэв тэдний нэг нь бүх хайлтыг ялахгүй бол. Энэ нь peer хүснэгтийн шинж чанар, туннелийн биш, тиймээс энд шийдэл нь хаягийн төлөвлөгөө, чиглүүлэлтийн заль биш.

Төлөвлөгөө нь LAN-ыг огт зарлахгүй байх явдал юм. Оронд нь үйлчилгээ бүрд alias зарлаж, сайт бүрд нэг хаяг өгч, сайт бүрийн гарц тэр alias-ыг өөрийн бодит программд хөрвүүлэх болтугай.

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

Сайт бүрт хэрэглэгчийн чиглүүлж чадах alias өгнө үү

Хэрэглэгчийн машин, төв зангилаа эсвэл хоёр LAN-ын аль нэгтэй ч зөрчилдөхгүй мужаас хаяг сонгоно уу. Энд төв зангилаа 10.66.0.1, хэрэглэгч 10.66.0.10, гарцууд 10.66.0.21 ба 10.66.0.22, хоёр alias нь 10.77.1.20 ба 10.77.2.20 байна. Төв зангилаа alias бүрийг түүнийг эзэмшдэг peer-ээр дамжуулан нийтэлдэг тул нэг alias-д хаягласан гарах пакет зөвхөн тохирох сайтаар гарч чадна:

[Interface]
Address = 10.66.0.1/32
ListenPort = 51820
PrivateKey = HUB_KEY

[Peer]
PublicKey = USER_PUBLIC_KEY
AllowedIPs = 10.66.0.10/32

[Peer]
PublicKey = SITE_A_PUBLIC_KEY
AllowedIPs = 10.66.0.21/32, 10.77.1.20/32

[Peer]
PublicKey = SITE_B_PUBLIC_KEY
AllowedIPs = 10.66.0.22/32, 10.77.2.20/32

Хэрэглэгчийн талд зөвхөн хоёр alias хэрэгтэй бөгөөд энэ нь клиентийн тохиргоог хоёр LAN угтвараас чөлөөтэй байлгана. Тэр тохиргоонд бодит LAN-ын аль нь ч дурдагдахгүй:

[Interface]
Address = 10.66.0.10/32
PrivateKey = USER_KEY

[Peer]
PublicKey = HUB_PUBLIC_KEY
Endpoint = hub.example.net:51820
AllowedIPs = 10.77.1.20/32, 10.77.2.20/32
PersistentKeepalive = 25

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

Төв зангилаа өөрийн хоёр peer-ийн хооронд юуг зөвшөөрөх ёстой вэ

Төв зангилаа пакетуудыг өөрийн хоёр peer-ийн хооронд дамжуулдаг бөгөөд энэ нь forward гинжин хэлхээний шийдвэр, оролтын шийдвэр биш. IPv4 дамжуулалтыг платформын ердийн механизмаар идэвхжүүлж, дараа нь загварт хэрэгтэй хосуудыг яг зөвшөөрнө үү.

Доорх дүрэм хэрэглэгчид нэг alias, нэг порт руу зөвшөөрөл өгч, холболт хянах замаар буцах трафикийг зөвшөөрнө. Энэ нь forward зам дээрх бусад бүхнийг хаядаг бөгөөд энэ нь гол зүйл:

nft add table inet hub_transit
nft add chain inet hub_transit forward '{ type filter hook forward priority 0 ; policy drop ; }'
nft add rule inet hub_transit forward ct state established,related accept
nft add rule inet hub_transit forward iifname wg0 oifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 accept

Хоёр дэлгэрэнгүйг дурдах нь зүйтэй, учир нь тэд чимээгүй алдаа үүсгэдэг. Нэг үндсэн гинжин дэх accept нь нөгөө дэх drop-ыг цуцалдаггүй тул үүнийг одоо байгаа бодлоготой нэгтгэж, хажууд нь ачаалахгүй байгаарай. Мөн эх хаяг нь хүнийг бус, төхөөрөмжийг тодорхойлдог; програмын баталгаажуулалтыг сүлжээний зөвшөөрлөөс тусгаарлаж байгаарай.

Alias бодит хаяг болох газар

А сайт 10.77.1.20 руу хүсэлт хүлээн авч, очих хаягыг бодит программ руу дахин бичээд, эх хаягыг өөрийн LAN хаяг руу дахин бичдэг тул хариулт туннель рүү чиглүүлэхгүйгээр буцаж чадна. Хоёр хөрвүүлэлтийг нэг газар хийх нь сүлжээний бусад хэсгийг alias-ын талаар мэдэхгүй байлгана. Доорх дүрмүүд нь бүх механизм:

nft add table ip site_a_nat
nft add chain ip site_a_nat pre '{ type nat hook prerouting priority -100 ; policy accept ; }'
nft add chain ip site_a_nat post '{ type nat hook postrouting priority 100 ; policy accept ; }'
nft add rule ip site_a_nat pre iifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 dnat to 10.10.7.20:443
nft add rule ip site_a_nat post iifname wg0 oifname lan0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.10.7.20 snat to 10.10.7.2

Дараа нь А сайтын forward бодлого нь хөрвүүлсэн урсгалыг туннелийн интерфейсээс LAN интерфейс рүү, буцах чиглэлийн хамт зөвшөөрөх ёстой. forward hook нь очих хаягыг очих хаягийн хөрвүүлэлтийн дараа, эх хаягийг дахин бичихээс өмнө хардаг тул дүрэм бодит програмын хаягыг нэрлэдэг. Дүрэм юу ч тохирохгүй мэт санагдах бүрт эдгээр хоёр hook-ыг энэ дарааллаар уншина уу. Alias-ын эсрэг бичсэн forward дүрэм хэзээ ч тохирч чадахгүй, учир нь тэр hook дээр alias байхгүй болсон.

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

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

Нийтэлсэн хоёр нэр хариулж байгааг хэрхэн батлах вэ

Alias бүрд DNS нэр өгч, програмыг болон сертификатыг тэр нэрэнд тохируулна уу, учир нь хөрвүүлэлт нь дахин чиглүүлэлт эсвэл суулгасан абсолют URL-ыг дахин бичихгүй. Сайт бүрд нэг нэр ашигласнаар сертификатын зөрүүг чиглүүлэлтийн гэмтэл гэж андуурахгүй.

Бодит клиентээс туршиж, аль сайт хариулсныг баталж, зөвшөөрөлгүй портыг ч шалгана уу. NAT-ын аливаа өөрчлөлтийн дараа шинэ холболт ашиглана уу, учир нь тогтоосон төлөв хуучин зураглалыг хадгалдаг:

wg show wg0 allowed-ips
sudo nft list ruleset
curl -sS -o /dev/null -w "%{http_code}\n" https://site-a.example.net/

Эхний команд дахь хоосон эсвэл гэнэтийн alias нь ямар ч галт ханы дүрэм чухал болохоос өмнө peer-ийн сонголт буруу гэсэн үг. Хэрэв alias зөв боловч нэр ажиллахгүй хэвээр байвал асуудал DNS болон сертификат руу шилжсэн. Хоёр нэр хариулж, гурав дахь порт хаалттай хэвээр байвал загвар нь өөрийн хэлснийг хийнэ: нарийн нийтэлсэн хоёр үйлчилгээ, нэгтгэсэн хоёр LAN биш.