සයිට්-ටු-සයිට් VPN හරහා IPv6 උපසර්ග බලයාපනය: පිරික්සුම් ලැයිස්තුව

ටනලය ඉහළට ගැනීම පහසු භාගයයි. සයිට්-ටු-සයිට් සම්බන්ධය දින ගණනක් ස්ථාපිතව තිබියදී, දුර LAN හි සෑම සත්කාරකයකුටම නිශ්ශබ්දතාවයක් පමණක් ආපසු ලැබුණු අයුරු මම දැක ඇත, මන්ද එම ගේට්වේ පිටුපස ඇති බලයාපනය කළ උපසර්ගය අතුරුමුහුණතක වින්‍යාසගතව තිබුණත් කිසිදාක ටනලයට රවුට් කර නොතිබුණි. ටනලයේ ලිපින එම කාලය පුරාම පිංගවලට පිළිතුරු දුන් අතර, ඒ නිසාම කිසිවෙක් උපසර්ගය දෙස බැලුවේ නැත. බලයාපනය කළ IPv6 උපසර්ගයක් සයිට් VPN හරහා යා යුතු විට මා පරීක්ෂා කරන අනුපිළිවෙල මෙයයි: උපසර්ග සිතියම, ට්‍රැෆික් තේරීම්, ඉදිරියට යැවීම සහ ෆයර්වෝලය, පසුව ආපසු මාර්ගය.

ටනලය ස්පර්ශ කිරීමට පෙර උපසර්ග සිතියම ලියන්න

උපසර්ග බලයාපනය ඉල්ලූ රවුටරයට කොටසක් ලබා දෙයි. එය සහකරු මත මාර්ගයක් ස්ථාපනය නොකරයි, එම කොටස on-link ලෙස දිගු නොකරයි, ඉල්ලන රවුටරය පිටුපස කුමක්දැයි දුර ගේට්වේට නොකියයි. මේ තුන ඔබම වින්‍යාස කළ යුතු අතර, කිසිදු වින්‍යාස ගොනුවක් වෙනස් වීමට පෙර ඒවා ලිපින සැලැස්මක තිබිය යුතුය.

එක් එක් සයිටය සඳහා බලයාපනය කළ උපසර්ගය, LAN හි සැබවින්ම භාවිතා වන /64, ටනලයේ ලිපින සහ සෑම මාර්ගයකම හිමිකරු සටහන් කරන්න. සපයන්නා සයිට් A ට 2001:db8:a1::/56 බලයාපනය කරයි, එය තම LAN හි 2001:db8:a1:10::/64 සපයයි; සයිට් B 2001:db8:b2::/64 රඳවා ගනී. සයිට් A එම එකම /64 පමණක් සපයන්නේ නම්, දෙපැත්තම සම්පූර්ණ /56 වෙනුවට 2001:db8:a1:10::/64 නම් කළ යුතුය.

සෑම විටම පාහේ වැරදි දෙකක් දිස්වේ. එකක් වන්නේ දුර උපසර්ගය on-link ලෙස සැලකීම, එය පාලම් කිරීම හෝ ටනල් අතුරුමුහුණතට තැබීම, එවිට ගේට්වේට ළඟා විය නොහැකි සත්කාරක සඳහා අසල්වැසි ඉල්ලීමට පිළිතුරු දෙයි. අනෙක සකසා ඇත්තේ එක් /64 පමණක් විට මුළු /56 ප්‍රචාරණය කිරීමයි: මාර්ග වගුව කොටස ළඟා විය හැකි බව පවසන අතර බොහෝ ලිපින කළු කුහරයකට වැටේ.

දෙපැත්තේම ට්‍රැෆික් තේරීම් මාර්ග සමඟ ගැලපෙන්න

IKEv2 සහ WireGuard දෙකම නොගැලපෙන ට්‍රැෆික් ප්‍රතික්ෂේප කරයි, ටනලය තවමත් නිරෝගී ලෙස පෙනෙන තරමට නිහඬව.

strongSwan තුළ තේරීම් පැහැදිලිය. සයිට් A හි:

conn a-to-b
    left=2001:db8:ff::1
    leftsubnet=2001:db8:a1:10::/64
    right=2001:db8:ff::2
    rightsubnet=2001:db8:b2::/64
    auto=start

සයිට් B හි conn දෙකොටසම පිළිබිඹු කරයි. ඒවා නොගැලපෙන විට, ප්‍රතිචාර දෙන්නා CHILD_SA එක TS_UNACCEPTABLE සමඟ ප්‍රතික්ෂේප කරයි, එබැවින් IKE_SA ඉහළ ගියත් child SA කිසිදා ඉහළ නොයයි. දෙපැත්තේම වින්‍යාසගත උපජාලය දේශීය කර්නලය ටනලය දෙසට රවුට් කරන දෙයට සමාන විය යුතුය.

WireGuard එකම තොරතුරු AllowedIPs තුළ රැගෙන යයි, එක් හැරවුමක් සමඟ: AllowedIPs ලැබීමේදී මූලාශ්‍ර පෙරහනක් සහ යැවීමේදී මාර්ගයක් වේ. සයිට් B හි සයිට් A සඳහා peer සටහන 2001:db8:a1:10::/64 අත්හැරියහොත්, සයිට් A වෙතින් එන පැකට් වලංගු handshake එකක් මත පැමිණ අවසර නැති ලෙස ඉවත දමනු ලැබේ. එයින් හුරුපුරුදු රටාවක් ඇති වේ: handshake නිරන්තරයෙන් අලුත් වන අතර කිසිදු පිළිතුරක් පිටතට නොයයි. දෙපැත්තම wg show wg0 allowed-ips සමඟ සසඳන්න. බලයාපනය වෙනස් වන සෑම විටම එම ලැයිස්තුව නැවත පරීක්ෂා කරන්න; පැරණි /64 සැසිය ජීවතුන් අතර තබා නව උපසර්ගය ළඟා විය නොහැකි කරයි.

මුලින්ම ඉදිරියට යැවීම, ෆයර්වෝලය සහ MTU ඉවත් කරන්න

තවත් ලොග් පේළියක් කියවීමට පෙර ගේට්වේ සැබවින්ම ඉදිරියට යවනවාදැයි තහවුරු කරන්න. sysctl net.ipv6.conf.all.forwarding දෙකෙන්ම 1 ආපසු දිය යුතු අතර, ටනලයේ සහ LAN හි අතුරුමුහුණත් සඳහාද යෙදිය යුතුය. උගුලක්ද එක්වේ: ඉදිරියට යැවීම සක්‍රීය වූ පසු accept_ra=1 සහිත අතුරුමුහුණත සපයන්නාගෙන් රවුටර ප්‍රකාශන ලබා ගැනීම නවත්වයි, එබැවින් යන්ත්‍රය ටනලය තුළ පරිපූර්ණව රවුට් කරමින්ම ඉහළ පෙරනිමි මාර්ගය අහිමි විය හැක. සපයන්නාගේ RA තවමත් අවශ්‍ය තැන accept_ra=2 සකසන්න.

පසුව ෆයර්වෝල් නීති උපසර්ගය දිශා දෙකටම අවසර දිය යුතු අතර, ICMPv6 ජීවත් විය යුතුය: අසල්වැසි සෙවීම, packet-too-big සහ destination-unreachable අත්‍යවශ්‍යය. ඒවා ඉවත දැම්මොත් මාර්ගයේ MTU සෙවීම බිඳී, විවෘත වී පළමු විශාල පිළිතුරේදී නතර වන සම්බන්ධතා ලැබේ. අවම නීති යුගලය මෙසේය:

nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } accept

MTU මෙයට පිටුපසින් පවතී. ටනලය භාවිත කළ හැකි MTU 1500ට පහළින් කුඩා කරයි, IPv6 සෑම සබැඳියක්ම අවම 1280ක් රැගෙන යා යුතු බව ඉල්ලා සිටී. කුඩා පිංග ගමන් කරයි, SSH සැසිය විශාල පිපිරුමකදී අංශුමාත්‍රව නතර වේ, /proc/net/snmp6 හි කිසිදාක ආපසු නොඑන packet-too-big පණිවිඩ දිස්වේ. ටනලයේ MTU පැහැදිලිව සකසන්න, නැතහොත් mangle වගුවේ TCP MSS සීමා කරන්න, කුඩා MTU දන්වන ICMPv6 ආපසු එන්නට හරින්න.

ටනලයේ ලිපිනය නොව, ආපසු මාර්ගය පරීක්ෂා කරන්න

වැඩිපුරම කාලය ගන්නා අසාර්ථකත්වය ඒකදිශ මාර්ගකරණයයි. සෑම ගේට්වේක්ම දුර උපසර්ගය ටනලයට රවුට් කරයි, නමුත් සත්කාරක තමන්ගේම පෙරනිමි ගේට්වේ හරහා පිළිතුරු දෙයි, මන්ද ඔවුන්ගේ /64 එහි පිහිටයි. පැකට් එකක් ගමනාන්තයට ගෙන යාම මාර්ගයෙන් අඩක් පමණි.

විධාන දෙකක් බොහොමයක් විසඳයි. සයිට් A හි ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 එම මූලාශ්‍රයෙන් එන පිළිතුර භාවිත කරන අතුරුමුහුණත පෙන්වයි; සයිට් B හි කැඩපතක් වැනි පරීක්ෂාවක් කරන්න. ඉන්පසු ගේට්වේ වෙනුවට සත්කාරකයකින් ට්‍රැෆික් ජනනය කර දෙපැත්තේම ගණක යන්ත්‍ර සසඳන්න.

දුර උපසර්ගය සඳහා අසල්වැසි ඉල්ලීම ටනලය මත දිස්වන්නේ නම්, එම උපසර්ගය නොතිබිය යුතු තැනක on-link වේ; මාර්ග සීරුමාරු කිරීමට පෙර එය නිවැරදි කරන්න. Proxy NDP පාලම් කිරීම සැබවින්ම අවශ්‍ය අවස්ථා ආවරණය කරයි, මාර්ගයක් සඳහා ආදේශකයක් නොවේ.

උපසර්ගය ඔබ යටතේ වෙනස් වන බවට සැලසුම් කරන්න

උපසර්ග බලයාපනය යනු බලයාපනය කරන සහ ඉල්ලන රවුටර අතර බදු දීමකි, සහ අලුත් කිරීම වෙනත් කොටසක් ආපසු දිය හැක: සපයන්නා සංක්‍රමණයෙන් පසු වෙනත් /56, නැතහොත් ටනලය පැවති කාලයට වඩා කෙටි බදුවක්. පැරණි උපසර්ගය නම් කරන සෑම තැනක්ම එකවර පැරණි වේ: මාර්ග, තේරීම්, AllowedIPs, ෆයර්වෝල් නීති, DNS වාර්තා සහ අක්ෂර ලිපින hardcode කරන ඕනෑම අධීක්ෂණයක්. පණිවිඩ ගලා යාම RFC 8415 හි ඇත.

උපසර්ගය ගමන් කරනු ඇතැයි අපේක්ෂා කරන තැන, එය මත රඳා නොපවතින අභ්‍යන්තර ලිපින සැලැස්මක් තබා මායිමේදී පරිවර්තනය කරන්න. NPTv6 තත්ත්ව රහිත විකල්පයයි, අභ්‍යන්තර ප්‍රතිපත්තිය කියවිය හැකිව තබයි, නමුත් එය උපසර්ග පරිවර්තනයකි, මායාකාරී ස්තරයක් නොවේ: /64 මායිම් ගැලපිය යුතුය, චෙක්සම් සකසනු ලැබේ, අක්ෂර ලිපින කාවැද්දූ යෙදුම් තවමත් බිඳේ. සපයන්නාගේ ලිපින කෙළවරේ සිට කෙළවර දක්වා තබා ගන්නේ නම්, බදු හැසිරීම සහ වෙනස්කම් ක්‍රියා පටිපාටිය ලිපින සැලැස්මේ සටහන් කරන්න.

කාලයට ඔරොත්තු දෙන පරීක්ෂණයකින් අවසන් කරන්න: එක් එක් LAN හි අවසර ලත් සත්කාරකයක් අනෙක් LAN හි සේවාවකට ළඟා වේ, පිළිතුර ටනලය හරහා ආපසු එයි, ටනලය නැවත ආරම්භ කිරීමෙන් සහ බලයාපනය අලුත් කිරීමෙන් පසුවත් එම යුගලය ක්‍රියා කරයි. අවසාන කොටස අසාර්ථක වුවහොත්, සැලසුම සතියක් නොපවතින තත්ත්වයක් මත රඳා පවතී.