OpenBSD VPN ගේට්වේ එකක tun0 හරහා LAN සඳහා NAT
OpenBSD tun0 පිටවීමකින් එළියට යන LAN රහදහට මූල NAT හෝ ආපසු මාර්ගය අතරින් එකක් තෝරන්න, පසුව nat-to නියමය pf තවමත් ඉඩ දෙන තැනට තබන්න.
එකම OpenBSD ගේට්වේ එකක් ඇති ඉංජිනේරුවන් දෙදෙනෙක් දුරස්ථ ජාලයකට ළඟා වීමට බොහෝ විට ඔබට වෙනස් නියම කට්ටල දෙකක් දෙනු ඇත, දෙකම ආරක්ෂා කළ හැකිය. මූල පරිවර්තනය සහ ආපසු මාර්ගය අතර තේරීම කිසිසේත් වාක්‍ය ව්‍යූහයේ ප්‍රශ්නයක් නොවේ. එය රඳා පවතින්නේ අනෙක් පැත්ත 192.168.88.0/24 ගැන දැනටමත් දන්නා දේ සහ ඔබේ ලොග් තුළ තබා ගත යුතු දේ මත ය. මෙහි වැරදුණොත් nat-to පේළිය සම්පූර්ණයෙන් නිවැරදි ලෙස පෙනෙන අතර පිළිතුරු දුරස්ථ පෙරනිමි ගේට්වේ තුළ අතුරුදහන් වේ.
මාර්ගගත කිරීම සහ නැවත ලිවීම වෙනස් ප්‍රශ්නවලට පිළිතුරු දෙයි
172.20.0.0/16 tun0 හරහා ළඟා කළ හැකි බව මාර්ගගත වගුව තීරණය කරයි, එම තීරණය කිසිදු pf පරිවර්තනයක් විමසීමට පෙර ගනු ලැබේ. පසුව මූල පරිවර්තනය පැකට් ශීර්ෂය වෙනස් කරයි, එවිට දුරස්ථ කෙළවරට LAN සත්කාරකය වෙනුවට ගේට්වේහි උමං ලිපිනය පෙනේ. කිසිදු යාන්ත්‍රණයක් අනෙක ආදේශ නොකරයි: nat නියමයකට මාර්ගයක් නිර්මාණය කළ නොහැක, මාර්ගයකට ඔබේ පෞද්ගලික උපජාලය ගැන කිසිදා නොඇසූ දුරස්ථ රවුටරයක් ඒත්තු ගැන්විය නොහැක. අනෙක් පැත්තට ආපසු මාවතක් නොමැති විට පිළිතුරු ඉවතලනු ලැබේ හෝ එහි පෙරනිමි ගේට්වේ වෙත යවනු ලැබේ, නියම කොපමණ සකස් කළත් එය නොසකස් වේ.
සරලව කියතොත්, යැවීම පිළිතුරු දෙන්නේ රහදහ කොහේ යනවා ද යන්නට, පරිවර්තනය පිළිතුරු දෙන්නේ එය කොහේ සිට පැමිණෙන ලෙස පෙනේ ද යන්නට. නියම කට්ටලය නිර්මාණය කරන අතරතුර දෙකම වෙන වෙනම මානසික පෙට්ටිවල තබා ගන්න.
තීරණය කරන කොන්දේසි තුන
ප්‍රශ්න තුනක් පිළිවෙලින් අසන්න, නිර්මාණය සාමාන්‍යයෙන් තමන්ම තෝරා ගනී. දුරස්ථ ජාලයට 192.168.88.0/24 සඳහා උමං ලිපිනයට යොමු වන ස්ථිතික මාර්ගයක් තිබේ ද, නැතහොත් එහි පරිපාලකයා එම මාවතේ රවුටර පාලනය කරයි ද? ඔව් නම්, LAN ලිපින නොවෙනස්ව යාමට ඉඩ දී පරිවර්තනය සම්පූර්ණයෙන් මඟ හරින්න. අනෙක් පැත්තේ සෑම සේවාදායකයකුට දෘශ්‍යතාව අවශ්‍ය ද, ප්‍රවේශ ප්‍රතිපත්තිය සඳහා හෝ විගණන මාවත සඳහා? ඔව් නම්, මූලය ආරක්ෂා කිරීම මාර්ගගත කිරීමේ වැඩයට වටී. උමං ලිපිනය දුරස්ථ මාර්ගයක ලිවීමට තරම් ස්ථාවර ද, නැතහොත් නැවත සම්බන්ධ වීම් අතර වෙනස් වේ ද?
කිසිදු පිළිතුරක් නැත හෝ නොදන්නා නම්, nat-to ප්‍රායෝගික විකල්පය වන අතර එය ප්‍රතිවර්තනය කළ හැකි ද වේ. අනෙක් පැත්ත සුදුසු මාර්ගයක් එකතු කළ විගස පරිවර්තන නියමය එක පේළියකින් ඉවත් වේ. කිසිදා ස්ථාපනය නොකළ ආපසු මාර්ගයක්, උමං එක් දිශාවකට පමණක් ක්‍රියා කරන්නේ ඇයි දැයි කවුරුන් හෝ ඇසූ සෑම විටම එක් ආධාරක නූලක් ගනී.
pf එය සැබවින්ම ඇගයීමට ලක් කරන ලෙස කොටස තබන්න
පහත කොටස උපකල්පනය කරන්නේ LAN 192.168.88.0/24, දුරස්ථ ජාලය 172.20.0.0/16, උමං අතුරු මුහුණත tun0 බවයි. එහි කිසිවක් ඊළඟ පිම්ම තෝරන්නේ නැත. එය දැනටමත් උමං හරහා පිටව යන පැකට්වල මූලය පමණක් නැවත ලියයි.
match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep stateඑම පළමු පේළියේ විස්තර දෙකක් වැඩිපුරම බර උසුලයි. tun0 වටා ඇති වරහන් pf ට කියන්නේ තත්ත්ව සටහනක් ගොඩනඟන සෑම විටම අතුරු මුහුණතේ ලිපිනය කියවන ලෙසයි, එය නැවත සම්බන්ධ වීමකින් පසු උමං නැවත අංකනය වන විට වැදගත් වේ. match යන වචනයෙන් අදහස් වන්නේ නියමය නැවත ලියා පසුව පහළට වැටෙන බවයි, එබැවින් වෙනම pass නියමයක් තවමත් ගැලීමට ඉඩ දිය යුතුය. match පේළියේ නම් කර ඇති අතුරු මුහුණත ද මාර්ගගත වගුව තෝරා ගන්නා එකම විය යුතුය, එසේ නොවුණහොත් pf නියමය ඇගයීමට ලක් කරන්නේ පැකට් ඇත්තටම යන මාවතට වඩා වෙනස් පිටවන මාවතක ය.
කර්නල් පැත්ත අමතක නොකරන්න. IPv4 යැවීම සක්‍රීය කළ යුතු අතර, උමං සහ LAN සඳහා තත්ත්වසහිත pass නියම මේ සියල්ල අර්ථවත් වීමට පෙර තිබිය යුතුය. මෙහි මූල පද අනුපිළිවෙල සඳහා OpenBSD FAQ හි PF NAT කොටස නිවැරදි යොමුවයි.
රහදහ විශ්වාස කිරීමට පෙර නියම කට්ටලය සත්‍යාපනය කරන්න
මුලින්ම pfctl -nf /etc/pf.conf සමඟ වාක්‍ය ව්‍යූහය පරීක්ෂා කරන්න, එය ගොනුව පූරණය නොකර විශ්ලේෂණය කරයි. පසුව ප්‍රතිපත්තිය පූරණය කර කර්නලය සැබවින්ම රඳවා ගන්නා දේ නැවත කියවන්න, මන්ද පිරිසිදුව විශ්ලේෂණය වූ නියමයක් වුවද සෙවනැලි විය හැක හෝ වැරදි අතුරු මුහුණතකට සම්බන්ධ විය හැක. pfctl -sn පරිවර්තන නියම පූරණය වූ ආකාරයෙන් මුද්‍රණය කරයි, pfctl -sr පෙරහන් නියම ඇගයීම් අනුපිළිවෙලින් මුද්‍රණය කරයි.
ඊළඟට රැහැන නිරීක්ෂණය කරන්න. ගේට්වේහි tcpdump -ni tun0 'host 172.20.0.10' මඟින් උමං හරහා පිටවන මූල ලිපිනය උමං ලිපිනය ද LAN සත්කාරකය ද යන්න පෙන්වයි. ඉක්මන් netstat -rn -f inet මඟින් ගමනාන්තය විසඳෙන අතුරු මුහුණත තහවුරු කරයි. රහදහ ගලා යාම ආරම්භ වූ පසු pfctl -ss තත්ත්ව සටහන් ලැයිස්තුගත කරයි; ගැලීමක් තත්ත්වයක් නිර්මාණය නොකළේ නම්, පැකට් එය නිර්මාණය කරන නියමයකට කිසිදා හසු නොවීය.
උමං පැත්ත නිවැරදි ලෙස පෙනුණත් පිළිතුරු තවමත් නොපැමිණේ නම්, pf සංස්කරණය කිරීම නවත්වන්න. ඉතිරි අසාර්ථකත්වය දුරස්ථ රවුටරයේ ඇත, එහිදී පිළිතුර එම පැත්තට ළඟා විය නොහැකි පෞද්ගලික ලිපිනයක් වෙත යවනු ලැබේ.
පරිවර්තනය ඉතිරි කරන දෙයට වඩා මිල අධික වන විට
පරිවර්තනය සේවාදායකයන් සඟවයි, සමහර විට එය හරියටම වැරදි ගනුදෙනුව වේ. එකිනෙක මුදුන් වන උපජාල එක් අවස්ථාවකි: අනෙක් පැත්ත ද ඇතුළත 192.168.88.0/24 භාවිත කරන්නේ නම්, LAN සත්කාරක ගේට්වේ ලෙස ඉදිරිපත් කිරීම ගැටුම සුවපත් කරනවාට වඩා නරක අතට හරවයි. ලිපින යුගලයෙන් රහදහ තෝරන IPsec ප්‍රතිපත්ති තවත් අවස්ථාවකි, මන්ද ආරක්ෂක ප්‍රතිපත්ති දත්ත සමුදාය පරිවර්තනයට පෙර ගැළපෙන අතර ඔබේ නැවත ලියන ලද පැකට් කිසිදා නොදකී. සෑම පරිශීලකයකුටම බිල් කරන, සීමා කරන හෝ විගණනය කරන ඕනෑම යෙදවුමක් ද මූලය එක් ලිපිනයකට කඩා වැටෙන මොහොතේ අවශ්‍ය අනන්‍යතාව අහිමි කර ගනී.
ගෙන යා හැකි pf ව්‍යුත්පන්න වෙනම උගුලකි. තමන්ගේම නියම ගොනු උත්පාදනය කරන නිෂ්පාදන අපේක්ෂා කරන්නේ NAT ඒවායේ අතුරු මුහුණත හරහා වින්‍යාසගත වන බවයි, අතින් සංස්කරණය කළ කොටස් ඊළඟ නැවත පූරණයේදී උඩින් ලියැවේ. match මූල පදය පැමිණීමට පෙර ලියූ මාර්ගෝපදේශවලින් පිටපත් කළ නියම කට්ටල වර්තමාන කර්නලයේ පූරණය නොවේ, එබැවින් වාක්‍ය ව්‍යූහය මාරු කර අනුමාන කිරීම වෙනුවට දෝෂය කියවන්න.
සැබෑ ජාල සමඟ සම්බන්ධ වීමෙන් පවතින තීරණ නියමය කෙටිය: හැකි විට ආපසු මාර්ගයක් ස්ථාපනය කරන්න, නොහැකි විට පරිවර්තනය කරන්න, සහ කොන්දේසි තුනෙන් කුමක් ඔබට එම තේරීම කළේ දැයි ලියන්න. එම සටහන ඊළඟ පුද්ගලයාගේ අඩක් දවස ඉතිරි කරයි.