සයිට් දෙකක්, එක් සබ්නෙට් එකක්, එක් 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 නීතියකට කිසිදා ගැළපිය නොහැක, මන්ද එම 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 දෙකක් නොවේ.

අදාළ ලිපි