Ikki sayt, bitta subnet, bitta WireGuard hub: ishga tushiring

Ikkala sayt ham bir xil LAN diapazonidan foydalanadi va dizaynni aslida buzadigan narsa qoplanish emas. Hub saytni faqat nishon manzili bo'yicha tanlashi kerak, ikkita bir xil nishon esa unga tanlash uchun hech narsa bermaydi. Ishlab turgan ofisni tunnel uchun qayta raqamlash, odatda, har bir e'lon qilingan xizmatga tunnel ko'tara oladigan alohida manzil berishdan yomonroq almashinuv. Quyidagi dizayn har bir saytdan bitta HTTPS xizmatini e'lon qiladi, boshqa hech narsa emas.

Nega qoplanish haqiqiy muammo emas

WireGuard nishon bo'yicha uzatadi: peer-ning AllowedIPs qiymatlari paket qaysi peer-ga borishini belgilaydi. Ikki peer bir vaqtda 10.10.7.0/24 ni e'lon qila olmaydi, agar ulardan biri har bir qidiruvda yutmasa. Bu tunnelning emas, peer jadvalining xossasi, shuning uchun bu yerdagi yechim marshrutlash hiylasi emas, manzillar rejasidir.

Reja LANni umuman e'lon qilishni to'xtatishdir. Buning o'rniga har bir xizmat uchun alias e'lon qiling, har bir saytga bitta manzil, va har bir saytning shlyuzi bu aliasni o'z haqiqiy ilovasiga aylantirsin.

Foydalanuvchi ikkita noyob manzilni marshrutlaydi, noaniq prefiksni hech qachon ko'rmaydi va ikkala ofisda ham hech narsa o'zgarmaydi. Bu chegarani ham halol aytadi: siz har bir saytdan bitta HTTPS xizmatini e'lon qilyapsiz, ikkita tarmoqni birlashtirmayapsiz. Keyingi qoidalar kichik bo'lib qoladi, chunki bayon tor. Kengroq bayon kengroq qoidalarni talab qilardi va bu dizaynlar aynan shunday murakkablashadi.

Har bir saytga foydalanuvchi marshrutlay oladigan alias bering

Manzillarni foydalanuvchi mashinasida, hubda yoki ikkala LANning hech birida hech narsa bilan to'qnashmaydigan diapazondan tanlang. Bu yerda hub 10.66.0.1, foydalanuvchi 10.66.0.10, shlyuzlar 10.66.0.21 va 10.66.0.22, ikkita alias esa 10.77.1.20 va 10.77.2.20. Hub har bir aliasni unga egalik qiluvchi peer orqali e'lon qiladi, shuning uchun bitta aliasga yuborilgan chiquvchi paket faqat mos sayt orqali chiqa oladi:

[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

Foydalanuvchi tomoniga faqat ikkita alias kerak, bu esa mijoz konfiguratsiyasini ikkala LAN prefiksidan xoli saqlaydi. Bu konfiguratsiyada hech narsa haqiqiy LANlarning birortasini ham eslatmaydi:

[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

Har bir shlyuz hubni va foydalanuvchi manbasini e'lon qiladi, boshqa hech narsa yo'q, shuning uchun sayt hech qachon boshqa saytning LANini bilmaydi. Keepalive saytning yuqori kanalida NAT xaritasini saqlaydi; u trafikka ruxsat bermaydi va xavfsizlik devori hali ham nima qabul qilinishini hal qiladi. Bitta shlyuz konfiguratsiyasini ikkinchisiga ko'chirish mumkin, agar maxfiy kalit, interfeys manzili va alias hammasi o'zgarsa.

Hub o'zining ikki peeri o'rtasida nimaga ruxsat berishi kerak

Hub paketlarni o'zining ikki peeri o'rtasida uzatadi, bu forward zanjiridagi qaror, kirish qarori emas. IPv4 uzatishni platformaning odatiy mexanizmi bilan yoqing, so'ng dizaynga kerakli juftliklarga aniq ruxsat bering.

Quyidagi qoida foydalanuvchiga bitta alias va bitta portga ruxsat beradi va ulanishlarni kuzatish orqali qaytish trafigiga ruxsat beradi. U forward yo'lidagi qolgan hamma narsani tashlaydi va bu asosiy fikr:

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

Ikki tafsilotni aytib o'tish kerak, chunki ular jim nosozliklar keltiradi. Bitta bazaviy zanjirdagi accept boshqasidagi dropni bekor qilmaydi, shuning uchun buni mavjud siyosat bilan birlashtiring, yoniga yuklamang. Va manba manzili odamni emas, qurilmani aniqlaydi; ilova autentifikatsiyasini tarmoqqa ruxsat berishdan alohida saqlang.

Alias haqiqiy manzilga aylanadigan joy

A sayti 10.77.1.20 uchun so'rov oladi, nishonni haqiqiy ilovaga qayta yozadi va manbani o'zining LAN manziliga qayta yozadi, shunda javob tunnelga marshrutsiz qaytishi mumkin. Ikkala tarjimani bir joyda qilish tarmoqning qolgan qismini aliasdan bexabar saqlaydi. Quyidagi qoidalar butun mexanizmdir:

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

Keyin A saytining forward siyosati tarjima qilingan oqimni tunnel interfeysidan LAN interfeysiga, shuningdek qaytish yo'nalishini ham ruxsatlashi kerak. forward hook nishonni nishon tarjimasidan keyin va manba qayta yozilishidan oldin ko'radi, shuning uchun qoida haqiqiy ilova manzilini nomlaydi. Qoida hech narsaga mos kelmayotgandek tuyulganda o'sha ikki hookni shu tartibda o'qing. Aliasga qarshi yozilgan forward qoidasi hech qachon mos kela olmaydi, chunki alias o'sha hookda endi yo'q.

B sayti buni o'z aliasi va o'z kaliti bilan takrorlaydi. U A saytining maxfiy kalitini qayta ishlatmasligi kerak, chunki ikki peerning bitta shaxsni bo'lishishi ko'rish qiyin va faylni ko'chirish bilan yaratish oson bo'lgan konfiguratsiya xatosidir. Ikkala shlyuz hujjatini farq qilishi shart bo'lgan qiymatlardan tashqari bir xil saqlang, ko'rikda farq ko'zga tashlansin. Ko'chirilgan fayl — bu nosozlikning odatiy manbasi.

Manbani qayta yozishning narxi bor. Ilova shlyuzni o'z mijozi deb biladi, shuning uchun uning jurnallari endi qaysi foydalanuvchi ulanganini ko'rsatmaydi. Shlyuzning audit izini saqlang va tarjima olib tashlagan tarmoq shaxsini qoplash uchun ilovaga kirishni zaiflashtirmang.

E'lon qilingan ikkala nom ham javob berishini qanday isbotlash mumkin

Har bir aliasga DNS nom bering va ilova hamda sertifikatni o'sha nom uchun sozlang, chunki tarjima qayta yo'naltirishlarni yoki ichiga joylashtirilgan mutlaq URLlarni qayta yozmaydi. Har bir saytga bitta nomdan foydalaning, sertifikat nomuvofiqligi hech qachon marshrutlash nosozligi deb xato tushunilmasin.

Haqiqiy mijozdan sinab ko'ring, qaysi sayt javob berganini tasdiqlang va ruxsat etilmagan portni ham sinang. Har qanday NAT o'zgarishidan keyin yangi ulanishlardan foydalaning, chunki o'rnatilgan holat eski xaritani saqlaydi:

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

Birinchi buyruqda bo'sh yoki kutilmagan alias har qanday xavfsizlik devori qoidasi muhim bo'lishidan oldin peer tanlovi noto'g'ri ekanini bildiradi. Agar alias to'g'ri bo'lsa-yu nom hali ham ishlamasa, muammo DNS va sertifikatlarga ko'chgan. Ikkala nom javob berib, uchinchi port yopiq qolsa, dizayn o'zi aytganini qiladi: tor e'lon qilingan ikkita xizmat, birlashtirilgan ikkita LAN emas.