Эки сайт, бир ички тармак, бир 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 чыныгы дарекке айланган жер

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ту ушундай тартипте окуңуз. Aliaska каршы жазылган 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 эмес.