Екі сайт, бір ішкі желі, бір WireGuard хабы: іске қосыңыз

Екі LAN да 10.10.7.0/24 желісінде, сондықтан хаб сайтты межелік бойынша таңдай алмайды. Әр қызметке alias беріп, оның қақпасында аударыңыз.

Екі сайт та бірдей 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 нақты мекенжайға айналатын жер

A сайты 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

Содан кейін A сайтының forward саясаты аударылған ағынды туннель интерфейсінен LAN интерфейсіне жіберуге, қайтару бағытымен бірге рұқсат беруі керек. forward hook межелікті межелік аудармасынан кейін және көзді қайта жазбас бұрын көреді, сондықтан ереже нақты қолданба мекенжайын атайды. Ереже ештеңеге сәйкес келмейтін сияқты көрінген сайын осы екі hook-ты осы ретпен оқыңыз. Alias-қа қарсы жазылған forward ережесі ешқашан сәйкес келе алмайды, өйткені alias ол hook-та енді жоқ.

B сайты мұны өзінің alias-ымен және өз кілтімен қайталайды. Ол A сайтының жеке кілтін қайта пайдаланбауы керек, өйткені екі 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 емес.

Қатысты мақалалар