இரு தளங்கள், ஒரு துணைவலை, ஒரு 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 கள் அல்ல.