සම්පූර්ණ ටනල් VPN එකක් ඉහළ ගිය පසුවත් සත්කාරකය SSH ට පිළිතුරු දෙමින් සිටියි, නමුත් එම යන්ත්‍රයේම Docker මගින් ප්‍රකාශිත සේවාව නිශ්ශබ්ද වේ. අසන්නා තුළ කිසිදු දෝෂයක් නැත: කන්ටේනරය ක්‍රියාත්මකයි, පෝට් සිතියම පවතී, පැකට්ටුව පැමිණේ. කන්ටේනරය සුවපත්ය, ඉල්ලීම ඇත්තෙන්ම එයට ළඟා වේ. වෙනස වන්නේ Linux එහි මාර්ගය තෝරන විට පිළිතුර ආරම්භ වන්නේ කොහෙන්ද යන්නයි, එම වෙනසම පහත මාදිලි දෙකෙන් ඔබට අවශ්‍ය කුමක්ද යන්න තීරණය කරයි.

ගමනාන්ත NAT හරහා ටියුපලය අනුගමනය කරන්න

සත්කාරකයක් ගන්න 192.0.2.10 හි, එය TCP 2222 172.30.240.5:22 හි කන්ටේනරයට ප්‍රකාශ කරයි. 198.51.100.25 වෙතින් එන ඉල්ලීම කන්ටේනරයට ළඟා වීමට පෙර පරිවර්තනය වේ, කන්ටේනරය තමා ලෙසම පිළිතුරු දෙයි.

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

සත්කාරකයේ මාර්ග තීරණයේදී පිළිතුර තවමත් කන්ටේනරයේ මූල ලිපිනය දරයි. ප්‍රතිලෝම පරිවර්තනය පසුව ප්‍රකාශිත ටියුපලය ප්‍රතිසාධනය කරයි, ඒ නිසාම මාර්ගය තෝරන හරියටම එම මොහොතේ පැකට්ටුව වැරදි ලෙස පෙනේ.

සත්කාරකයට පමණක් වන නියමය එය අතපසු කරන්නේ ඇයි

WAN වගුව 192.0.2.10 වෙතින් එන පැකට්ටු සඳහා පමණක් තෝරන නියමය සත්කාරකයේම ඩීමන ආවරණය කරන අතර මෙම ඉදිරියට යවන ලද පිළිතුර සම්පූර්ණයෙන්ම අතපසු කරයි. පිළිතුරේ මූල ලිපිනය 172.30.240.5 ය, සත්කාරකය නොවේ.

අධික නිවැරදි කිරීම වන්නේ කන්ටේනරයේ සියල්ල WAN හරහා මාර්ගගත කිරීමයි, එය කන්ටේනරයේ සම්බන්ධයක් නැති පිටතට යන සම්බන්ධතා ද VPN වෙතින් නිදහස් කරයි. එය ඉල්ලා ඇති ප්‍රතිපත්තියට වඩා වෙනස් වන අතර සාමාන්‍යයෙන් පසුව යමෙකු පුදුම කරයි.

DNAT පසු ගැළපීම වෙනත් හුක් එකකි

Docker හි ෆයර්වෝල් ලේඛන සඳහන් කරන්නේ සාමාන්‍ය පරිශීලක පෙරහැර DNAT පසු ගමනාන්තය දකින බවයි, එබැවින් සාමාන්‍ය නියමයක ප්‍රකාශිත පෝට් 2222 ගැළපීම කන්ටේනර් පෝට් 22 ගැළපීමට සමාන නොවේ. මුල් ටියුපලය වැදගත් නම්, කුමන පෝට් දිස්වේද යන්න අනුමාන කිරීම වෙනුවට සහාය දක්වන මූල-ගමනාන්ත යාන්ත්‍රණය භාවිත කරන්න.

මෙම හුක් ව්‍යාකූලත්වය නිවැරදි ලෙස පෙනෙන නමුත් කිසි විටෙක නොගැළපෙන නියම සාදයි. ප්‍රතිපත්තිය නැවත ලිවීමට පෙර නියමයේම කවුන්ටර පරීක්ෂා කරන්න. ශුන්‍ය පහරවල් ඇති නියමයක් ඔබට කියන්නේ එය පැකට්ටුව කිසි විටෙක නොළඟා වන තැනක ඇගයෙන බවයි.

මාදිලිය A: තීරණය සම්බන්ධතා තත්ත්වයක් ලෙස රැගෙන යාම

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

  1. Docker, VPN හෝ වෙනත් ප්‍රතිපත්ති හිමිකරු සමඟ ගැටෙන්නේ නැති ලකුණු ක්ෂේත්‍රයක් සහ නියම ප්‍රමුඛතාවක් වෙන් කරන්න.
  2. සම්බන්ධතා නිරීක්ෂණය ලබා ගත හැකි DNAT-පූර්ව ලක්ෂ්‍යයේදී අපේක්ෂිත නව WAN සම්බන්ධතාව පමණක් හඳුනා ගන්න.
  3. මූල ඉල්ලීමම WAN වගුවට බලකර නොගෙන තීරණය සම්බන්ධතා ලකුණේ සටහන් කරන්න.
  4. පිළිතුරු දිශාවේ, මාර්ගගත කිරීමට පෙර ඔබේම ලකුණු බිටු පමණක් පැකට්ටුවට ප්‍රතිසාධනය කරන්න.
  5. VPN නියමයකට පළමුව ජය ගත නොහැකි වන පරිදි සම්පූර්ණ WAN වගුවක් ප්‍රමාණවත් ලෙස කලින් තෝරන්න.

එම වගුවට සැබෑ සම්බන්ධිත මාර්ග සහ ගේට්වේ අවශ්‍යයි. මාර්ගය නොමැති විට නිර්වචනය කළ හැසිරීමක් ද අවශ්‍යයි. ටනලයට නිශ්ශබ්දව වැටීම නරකම ප්‍රතිඵලයයි, මන්ද වින්‍යාසය තවමත් ක්‍රියා කරන බව පෙනේ. ඒ වෙනුවට වසා අසාර්ථක වී එය ලොග් කරන්න.

මාදිලිය B: සත්කාරකයේ අවසන් කිරීම

කන්ටේනරය ඉදිරිපිට TCP ප්‍රොක්සියක් හෝ ප්‍රතිලෝම ප්‍රොක්සියක් වැනි චේතනාන්විතව වින්‍යාසගත සත්කාරක පැත්තේ ඉදිරිපස, පිළිතුර සත්කාරක ලිපිනයෙන් ආරම්භ වන පරිදි තබා ගනී. එවිට සත්කාරකය සඳහා ලියන ලද නියම අපේක්ෂිත ලෙස හැසිරේ, කන්ටේනරය එහි පෞද්ගලික ජාලයේම රැඳී සිටී.

වියදම වන්නේ තමන්ගේම වින්‍යාසය, මූල ලිපින හැසිරවීම සහ ප්‍රවේශ පාලන සහිත තවත් චලනය වන කොටසකි. එය සාමාන්‍යයෙන් සරලම සහාය දක්වන සීමාව වන අතර, මාර්ගගත කිරීමේ ප්‍රතිපත්තිය ඉවත් විය හැකි එක් පුද්ගලයෙකු විසින් නඩත්තු කරන්නේ නම් එය බොහෝ විට නිවැරදි පිළිතුර වේ.

වෙනස සත්‍යාපනය කරන්න, අභිප්‍රාය නොවේ

පොදු පැත්තෙන් නව අවසර ලත් සම්බන්ධතාවක් විවෘත කර පිළිතුර අපේක්ෂිත අතුරුමුහුණත හරහා පිටවන බව තහවුරු කරන්න. පසුව කන්ටේනරය ආරම්භ කළ සම්බන්ධයක් නැති ඉල්ලීම තවමත් VPN අනුගමනය කරන්නේදැයි පරීක්ෂා කරන්න.

එක් නියමයක් පරීක්ෂා කිරීමට යන්ත්‍රයේ සම්බන්ධතා වගුව ෆ්ලෑෂ් නොකරන්න: පවතින සටහන් ඒවායේ පෙර සිතියම රඳවා ගනී, ෆ්ලෑෂ් කිරීම සත්කාරකයේ අනෙක් සියල්ල බිඳ දමයි. පෝට් ප්‍රකාශ කිරීම ළඟා විය හැකි බව නිර්වචනය කරයි. එය පිළිතුරේ මාර්ගය නිර්වචනය නොකරයි. තෝරාගත් මාදිලිය එහි වගු නම් සමඟ ලියා තබන්න, සිද්ධියකදී ඊළඟ පුද්ගලයාට එය නැවත සොයා ගැනීමට සිදු නොවන පරිදි.

අදාළ ලිපි