Երկու կայք, մեկ ենթացանց, մեկ 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 քարտեզագրումը կայքի uplink-ում․ այն չի լիազորում երթևեկությունը, և firewall-ը դեռ որոշում է, թե ինչ ընդունվի։ Մի դարպասի կարգավորումը մյուսին պատճենելը նորմալ է, քանի դեռ մասնավոր բանալին, ինտերֆեյսի հասցեն և 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-ի ընտրությունը սխալ է, նախքան ցանկացած firewall կանոն նշանակություն կունենա։ Եթե alias-ը ճիշտ է, և անունը դեռ ձախողվում է, ապա խնդիրը տեղափոխվել է DNS և վկայականներ։ Հենց երկու անուններն էլ պատասխանեն, և երրորդ պորտը մնա փակ, ձևավորումն անում է այն, ինչ պնդում է․ երկու նեղ հրապարակված ծառայություն, ոչ թե երկու միավորված LAN։