બે સાઇટ, એક સબનેટ, એક 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 આ ક્રમમાં વાંચો. alias સામે લખાયેલો forward નિયમ ક્યારેય મેળ ખાઈ શકતો નથી, કારણ કે તે hook પર alias હવે અસ્તિત્વમાં નથી.

સાઇટ 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 નહીં.