OpenVPN පිටුපස Docker සහ VM රථවාහනය: මාර්ගයද නැවත අංකනයද?

OpenVPN සේවාදායකය ධාවනය වන සත්කාරකයේ බහාලුම් සහ අමුත්තන් ආපසු මාර්ගය අහිමි වේ හෝ උමං උපසර්ගය සමඟ ගැටේ. ප්‍රශ්න තුනක් විසඳුම තෝරයි.

සත්කාරකය උමං හරහා බ්‍රවුස් කරන අතර අසල ඇති බහාලුම කිසිවකට ළඟා නොවේ. තමන්ගේම VPN සේවාදායකය ධාවනය කරන බහාලුමකින් තොටුපළක් ප්‍රකාශයට පත් කිරීම වඩා නරකය: ඉල්ලීම පැමිණේ, පිළිතුර කිසිදා පිටව නොයයි. දෙකම සත්කාරකයේ මාර්ගගත කිරීමේ තීරණ, සහ Docker නිකම්ම පණිවිඩකරුවා පමණි.

මෙම දෙකෙන් කුමක්ද යන්න ප්‍රශ්න තුනක් තීරණය කරයි, එයට මිනිත්තුවක් පමණ ගත වේ.

එකම ආකාරයෙන් පෙනෙන අසමත්වීම් දෙක

පළමුවැන්න ආපසු මාර්ගයේ ගැටලුවකි. ප්‍රකාශිත තොටුපළ බහාලුමට පරිවර්තනය වේ, ඉල්ලීම පැමිණේ, පිළිතුර සත්කාරකයේ පෙරනිමි මාර්ගය හරහා යවනු ලැබේ, එය OpenVPN සේවාදායකය tun0 වෙත හරවා ඇත. පිළිතුර දුරස්ථ සහකරු බලාපොරොත්තු නොවන ලිපිනයකින් පිටවේ, එය ඉවත දමනු ලැබේ. දෙවැන්න උපසර්ග ගැටුමකි: Docker හි පෙරනිමි පාලම 172.17.0.0/16 හිමිකම් කියයි, ආයතනික උමං එම පරාසයම තල්ලු කරයි.

එකක් මාර්ග වගුවකින් සකස් වේ, අනෙක පාලමක් නැවත අංකනය කිරීමෙන්. කුමක් කුමක්දැයි දැනගැනීමට පෙර සංස්කරණය කිරීම ක්‍රියාකාරී බහාලුමක් බිඳ දැමීමේ ක්‍රමයයි.

ප්‍රශ්න තුනකින් තීරණය කරන්න

පළමු ප්‍රශ්නය: VPN නතර කළ විට අසමත්වීම නැති වේද? උමං වහලා ඇති විට සියල්ල ක්‍රියා කරයි නම්, ආපසු මාර්ගය සැක කරන්න. දෙවන ප්‍රශ්නය: ip route show table all එකම උපසර්ගය දෙවරක් ලැයිස්තුගත කරයිද, එක් වරක් පාලමක සහ එක් වරක් tun0 හි? එයයි ගැටුම. තෙවන ප්‍රශ්නය: බලපෑමට ලක් වූ ලිපිනය බහාලුමක්ද, NAT අමුත්තෙක්ද නැත්නම් පාලම් කළ අමුත්තෙක්ද?

තෙවන ප්‍රශ්නය වැදගත් වන්නේ එක් එක් අයට වෙනස් නිවැරදි විසඳුමක් ඇති බැවිනි, බහාලුම් විසඳුම libvirt අමුත්තෙකුට යෙදීම සවසක් නාස්ති කරයි.

ip route
ip route show table all | grep -E '172\.1[7-9]|10\.8'
docker network inspect bridge --format '{{.IPAM.Config}}'

ආපසු මාර්ගය: එක් මූලාශ්‍ර ලිපිනයක් සඳහා වගුවක්

බහාලුමේ රථවාහනය භෞතික අතුරුමුහුණත හරහා පිටවිය යුතු අතර සත්කාරකයම උමං භාවිතා කරන විට, මූලාශ්‍රය මත පදනම් වූ මාර්ගගත කිරීම කුඩාම වෙනසයි. බහාලුමේ ලිපිනයට ගැළපෙන රීතියක් එකතු කර එය කැපවූ වගුවකට යවන්න. සත්කාරකයේ වෙන කිසිවක් නොසැලේ.

ip rule add from 172.22.0.3 lookup 10
ip route add default via 172.22.0.1 table 10

මූලාශ්‍රය එම ලිපිනය වන සෑම පැකට්ටුවක්ම මුලින්ම වගුව 10 බලයි, වගුව 10 එය උමං වෙනුවට පාලමේ ද්වාරයට යවයි.

මෙයින් තහවුරු කරන්න: ip route get 1.1.1.1 from 172.22.0.3. පිළිතුරේ පාලම් අතුරුමුහුණත නම් කළ යුතුය, tun0 නොවේ. මෙසේ එකතු කළ රීති නැවත ඇරඹීමේදී අතුරුදහන් වේ, එබැවින් ඒවා බහාලුම හිමි unit හෝ ජාල කොක්කෙහි තබන්න.

එම රටාවම WireGuard බහාලුමකටද ක්‍රියා කරයි, එහිදී පිළිතුරු මාර්ගයටද පැහැදිලි රීතියක් අවශ්‍ය වේ.

උපසර්ග ගැටුම: පාලම නැවත අංකනය කරන්න

මාර්ග වගුවක් එක් උපසර්ගයක් එක් තැනකට යවයි. VPN 172.17.0.0/16 තල්ලු කරන අතර Docker පාලම දැනටමත් එහි නම්, අඩු මෙට්‍රිකය ජය ගනී: Docker එහි සම්බන්ධිත මාර්ගය මෙට්‍රිකය 0 ලෙස ස්ථාපනය කරයි, තල්ලු කළ මාර්ගය 50 දී පැමිණේ. එවිට Docker ක්‍රියා කරන අතරේම උමං බිඳී ඇති ලෙස පෙනේ, නැතිනම් ඊට ප්‍රතිවිරුද්ධව, ස්ථාපන අනුපිළිවෙල අනුව. මෙට්‍රිකය සමඟ සටන් කිරීම වෙනුවට පාලම නැවත අංකනය කරන්න.

{
  "bip": "10.200.0.1/24",
  "default-address-pools": [{"base": "10.201.0.0/16", "size": 24}]
}

වෙනසෙන් පසු Docker නැවත අරඹා පැරණි තටාකයෙන් ගොඩනගන ලද ජාල නැවත සාදන්න. ඒ වෙනුවට මෙට්‍රිකය වෙනස් කිරීම ගැටුම ඊළඟ ඇරඹුමට මාරු කරයි.

VM සඳහා නැවතත් වෙනත් පිළිතුරක් අවශ්‍යයි

පෙරනිමි NAT ජාලයේ libvirt අමුත්තා සත්කාරකයේ මාර්ගගත කිරීම උරුම කර ගන්නා අතර සත්කාරකයේ උමං පෙරනිමි මාර්ගය හිමි වූ පසු පිටතට ළඟා වීම නවතී. අමුත්තා පාලම් හෝ macvtap උපාංගයකට මාරු කිරීම ඔහුට භෞතික ජාලයේ තමන්ගේම මාර්ගයක් ලබා දෙයි. virt-manager හි දෘඩාංග එකතු කරන්න, Network තෝරන්න, මූලාශ්‍රය macvtap සත්කාරක උපාංගයට සකසන්න, ආකෘතිය ලෙස virtio රඳවා ගන්න, පසුව පැරණි NAT අතුරුමුහුණත අක්‍රීය කරන්න.

macvtap අමුත්තා සාමාන්‍යයෙන් තමන්ගේ සත්කාරකයට ළඟා විය නොහැක. එය දෝෂයක් නොව අපේක්ෂිත හැසිරීමකි, එය ඔබ ඉතිරි කරන සටහනේ තිබිය යුතුය.

සත්කාරකයේ LAN පමණක් අවශ්‍ය අමුත්තෙකුට, විකුණුම්කරුගේ සේවාදායකයේ අතුරුදන් වූ ස්විචය තිබිය හැක: Mullvad සමඟ mullvad lan set allow libvirt ස්පර්ශ නොකර දේශීය ළඟාවීම යථා තත්ත්වයට පත් කරයි. බහාලුම උමං හරහා පමණක් ළඟා විය යුතු නම්, ප්‍රකාශිත තොටුපළ උමං ලිපිනයට බැඳ දමන්න, -p 10.8.0.5:8080:8080, සෑම ලිපිනයකම ප්‍රකාශයට පත් කිරීම වෙනුවට.

අදාළ ලිපි