NAT L2TP/IPsec කඩනවා යන ප්‍රකාශය අඩක් සත්‍යයි, එබැවින් නිෂ්ප්‍රයෝජනයි. ලිපින පරිවර්තනය සාමාන්‍ය දෙයක්, NAT traversal එයින් ජීවත් වීමටම පවතී, සහ දිනපතා ලක්ෂ ගණන් සේවාදායක රවුටරයක පිටුපසින් සම්බන්ධ වේ. කැඩෙන්නේ යම් නිශ්චිත හුවමාරුවක නිශ්චිත අදියරකි: IKE ට කිසිවිටෙක පිළිතුරක් නොලැබේ, එක් ප්‍රොටොකෝලයකට පමණක් අවසර දෙන ප්‍රතිපත්තියකින් encapsulate කළ ටනලය ඉවතට විසි කෙරේ, නැතහොත් ටනලය නිශ්චලව ඇති විට mapping කල් ඉකුත් වේ. ඔබ කුමන අදියරේද සිටින්නේ දැයි දැනගත් පසු, විසඳුම සාමාන්‍යයෙන් එක් නියමයක් හෝ keepalive එකක් මිස නව VPN නිර්මාණයක් නොවේ.

මිථ්‍යාව යනු වැරදි ප්‍රශ්නයයි

ප්‍රයෝජනවත් ප්‍රශ්නය “NAT මෙය කඩනවාද” යන්න නොව, “හුවමාරුවේ කුමන කොටස පරිවර්තනය වේ ද, පරිවර්තනය කරන උපාංගය එය සමඟ කුමක් කරයි ද” යන්නයි. L2TP/IPsec ස්තරීය ප්‍රොටොකෝලයකි: IKE සාකච්ඡා කරයි, ESP ආරක්ෂා කරයි, සහ L2TP එම ආරක්ෂාව තුළ PPP රැගෙන යයි. ලිපින පරිවර්තනය එක් එක් ස්තරයට වෙනස් ලෙස බලපායි, දෝෂ සංවාදය වෙනුවට සාකච්ඡා අදියර දෙස බැලුවහොත් අසාර්ථකත්වයේ ලක්ෂණ වෙන්කර හඳුනාගත හැක.

වෙබ් බ්‍රවුස් කිරීම සාර්ථක වන රවුටරයක් ඔප්පු කරන්නේ මූල පෝට් පරිවර්තනය සහිත TCP ක්‍රියා කරන බව පමණි. එය UDP 500, UDP 4500 හෝ ප්‍රොටොකෝල් 50 ගැන කිසිවක් නොකියයි, මෙම යෙදවුම රඳා පවතින්නේ එම තුන මතය.

අදියර 1: IKE ට ඕනෑම ලෙසකින් පිළිතුරක් ලැබිය යුතුය

පළමු හුවමාරුව UDP 500 හරහා පිළිතුරු දෙන්නා වෙත යයි. පිළිතුරක් ආපසු නොඑන්නේ නම්, අනෙක් කිසිවක් වැදගත් නොවේ: කලින් බෙදාගත් යතුර, යෝජනාව සහ සත්‍යාපන දත්ත කියවා නැතිව පවතී. සේවාදායකයාගේ කාල සීමාවෙන් අනුමාන කරනවාට වඩා ඉල්ලීම සහ පිළිතුර නිරීක්ෂණය කරන්න:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

පිළිතුරක් නැති ඉල්ලීමක් සාමාන්‍යයෙන් අදහස් වන්නේ firewall එකක් හෝ ඉහළ ප්‍රවාහකය පැකට්ටුව ඉවතට විසි කරන බව මිස සේවාදායකය එය ප්‍රතික්ෂේප කළ බව නොවේ. යෝජනාවක් හෝ සහතික ගැටලුවක් නම් කරන දැනුම්දීම් ගෙනයන පිළිතුරක් යනු පැකට්ටු පැමිණ ඇති බවත්, අන්තර්ගතය නිසා සාකච්ඡාව අසාර්ථක වූ බවත් ය; එය සම්පූර්ණයෙන්ම වෙනස් අලුත්වැඩියාවකි.

දෙපැත්තම පරිවර්තනය පිටුපස සිටින විට, ආරම්භකයාට පිළිතුරු දෙන්නා වෙත ළඟා වීමට පමණක් සිදු වේ, එබැවින් බොහෝ සේවාදායක පාර්ශ්වීය යෙදවුම් අදියර 1 සිට ක්‍රියා කරයි. සේවාදායක පාර්ශ්වයේ සත්කාරකත්වය යනු ඇතුළත ගැටලුව ආරම්භ වන තැනය, එබැවින් මෙම අවස්ථා දෙක කිසිවිටෙක එකක් ලෙස සාකච්ඡා නොකළ යුතුය.

අදියර 2: encapsulation එක firewall දකින දේ වෙනස් කරයි

ESP යනු IP ප්‍රොටොකෝලයකි, TCP හෝ UDP පෝට් එකක් නොවේ, සාමාන්‍ය පෝට් ලිපින පරිවර්තනයට නැවත ලිවීමට පෝට් ක්ෂේත්‍රයක් නැත. එබැවින් NAT traversal ආරක්ෂිත ගෙනයනය UDP 4500 තුළට ගෙන යයි: encapsulation එක පරිවර්තනය කරන උපාංගයට එය පරිවර්තනය කරන ආකාරය දන්නා දෙයක් ලබා දෙයි. එය සිදු වූ පසු, UDP 500 සඳහා පමණක් ලියන ලද firewall නියමයක් සාකච්ඡාවට ඉඩ දී ටනලය ඉවතට විසි කරයි, එයින් ලොගයේ සාර්ථක අදියර 1 සහ රථවාහන නොමැති බව පෙනෙන ව්‍යාකූල ප්‍රතිඵලය ඇති වේ.

NAT හඳුනාගත් පසු IKE හුවමාරුව ද UDP 4500 වෙත යා හැක, එය 500 පමණක් අවසර දුන් අයට පුදුමයකි. මාර්ගයේ පෝට් දෙකම දිශා දෙකෙහිම අවසර දෙන්න, සහ තත්ත්ව සහිත firewall එකක් රථවාහන දකින තාක් පමණක් ප්‍රවාහය රඳවා ගන්නා බව මතක තබා ගන්න.

ප්‍රොටොකෝල් 50 පරිවර්තනය නොමැති මාර්ගවල සහ අතරමැදි පෙට්ටියක් එයට අවසර දීමට වින්‍යාස කර ඇති මාර්ගවල තවමත් වැදගත් වේ. ඉවත් කිරීමෙන් රෝග විනිශ්චය කරන්නේ නම්, නියම ගොඩගැසීමට වඩා උපකල්පනය නිවා දමන්න: 500, 4500 සහ ESP අවසර දෙන්න, ටනලය ඉහළ යන බව තහවුරු කරන්න, පසුව අනවශ්‍ය බව පෙනුණු දේ ඉවත් කරන්න. කිසිවෙකුට පැහැදිලි කළ නොහැකි නියමයක් යනු ඊළඟ බාධාවට හේතු වූ විට කිසිවෙකු ඉවත් නොකරන නියමයකි. සීමා කිරීම වෙනස්කම් වාර්තාවේ එය නිවැරදි කළ අදියර සමඟ ලියන්න, ඊළඟ ඉංජිනේරුවා එම මාපටැඟිලි නියමයෙන් නොව ඔබේ සාක්ෂිවලින් ආරම්භ කරන පිණිස.

අදියර 3: mapping කල් ඉකුත් වන අතර ටනලය මිය යයි

පරිවර්තනය කරන උපාංගයක් එය යොමු කරන ප්‍රවාහ සඳහා තත්ත්වයක් රඳවා ගනී, එම තත්ත්වයට ආයුෂක් ඇත. කිසිවෙකු භාවිත නොකරන විට L2TP/IPsec ටනලයක් රථවාහන අල්පයක් රැගෙන යයි, එබැවින් නිශ්චල ටනලයක් එහි mapping ට වඩා ජීවත් වී ආපසු එන රථවාහන ලබා ගැනීම නතර කළ හැක. සේවාදායකයා සම්බන්ධ බව විශ්වාස කරමින් සිටී, සේවාදායකයට කිසිවක් නොපෙනේ, පළමු රෝග ලක්ෂණය සාමාන්‍යයෙන් VPN දෝෂයක් නොව යෙදුම් කාල සීමාවකි.

මියගිය සහකරු හඳුනා ගැනීම සහ NAT keepalive මේ සඳහාම ඇත, කෙළවර දෙකම ඒවා යැවීමට සූදානම් විය යුතුය. ඔබේ සේවාදායකය පරිවර්තනය පිටුපස නම්, Windows පැත්තේ අවශ්‍යතාව වන්නේ සේවාදායකයට තම ස්වකීය පිටවන පැකට්ටු සඳහා UDP encapsulation උපකල්පනය කිරීමට සලස්වන ලේඛනගත රෙජිස්ට්‍රි සැකසුමකි; එය නොමැතිව පිළිතුරු දෙන්නා පරිවර්තන උපාංගයට ආපසු map කළ නොහැකි ESP යවයි. මෙය සේවාදායක වින්‍යාස ගැටලුවකි, සේවාදායකයාගේ නොවේ.

WAN ලිපිනය වෙනස් වීම වෙනත් දිශාවකින් එකම ප්‍රතිඵලය ලබා දෙයි: mapping නව ලිපිනයක් වටා නැවත ගොඩනැගේ, පැරණි ආරක්ෂක සංගමය දැන් නොපවතින tuple එකක් වෙත යොමු වේ. නැවත සම්බන්ධ වීමේ හැසිරීම සේවාදායක ක්‍රියාත්මක කිරීමට අයත් ය, එබැවින් “රවුටරය නැවත ආරම්භ කිරීමෙන් පසු නැවත සම්බන්ධ වන්න” එක් සේවාදායකයක ක්‍රියා කර අනෙකක් අතින් ස්විචයක් අවශ්‍ය වේ.

ප්‍රවාහක ශ්‍රේණියේ NAT පිටුපස සත්කාරකත්වය වෙනස් ගැටලුවකි

ඔබ නිවසේ L2TP/IPsec සේවාදායකයක් සත්කාරකත්වය දී එයට පිටතින් ළඟා වීමට අවශ්‍ය නම්, අවශ්‍යතාව වන්නේ නොඉල්ලා එන ඇතුළත ළඟා විය හැකි බවය, එය NAT traversal ලබා නොදෙන දෙයකි. ඔබේ රවුටරය ඉදිරිපිට ප්‍රවාහක ශ්‍රේණියේ NAT එකක් තිබීම යනු පොදු ලිපිනය බෙදාගෙන ඇති බැවින් හා mapping පිටවීම පමණක් වන බැවින් ඔබව ළඟාවිය හැකි කිරීමට යොමු කළ හැකි පෝට් එකක් නොමැති බවයි.

කිසිදු IPsec pass-through කොටුවක් එය වෙනස් නොකරයි, කිසිදු සේවාදායක වින්‍යාසයක් එය වන්දි නොගනී. අනුග්‍රහය ලබා දෙන පිළිතුරු වන්නේ සැබවින්ම ළඟාවිය හැකි ලිපිනයක්, සත්කාරක අන්ත ලක්ෂ්‍යයක්, හෝ සෑම සහභාගිවන්නෙකුම පිටවන සම්බන්ධතාවක් සිදු කරන තුලනයකි. UDP encapsulation පිරිවිතරය පවතින ප්‍රවාහ සඳහා පරිවර්තන ගැටලුව විසඳයි; ප්‍රවාහකයා ලබා නොදෙන තැන එය ඇතුළත මාර්ගයක් නිර්මාණය නොකරයි.

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

අදාළ ලිපි