strongSwan ESP-in-UDP: හඳුනා ගැනීමට NAT නොමැති විට

NAT හඳුනාගැනීම ලිපින පරිවර්තනය සොයා ගනී, firewall ප්‍රතිපත්තිය නොවේ. NAT නොමැති අඩවි සම්බන්ධතාවයකට තවමත් පැහැදිලි ESP-in-UDP තේරීමක් අවශ්‍ය විය හැක.

NAT හඳුනාගැනීම එක් ප්‍රශ්නයකට පිළිතුරු දෙයි: මාර්ගයේදී ලිපින හෝ වරායන් වෙනස් වී තිබේද? firewall එකක් IP ප්‍රොටෝකෝලය 50 ට ඉඩ දෙන්නේද යන්නට එය පිළිතුරු නොදෙයි. කිසිදු පරිවර්තනයක් නොමැති අඩවි ද්වාර native ESP ඉවත දමන ප්‍රතිපත්තියක පිටුපස තවමත් සිටිය හැක, එම අවශ්‍යතාව හඳුනා ගැනීම වෙනුවට වින්‍යාස කළ යුතුය. යාන්ත්‍රණය ESP-in-UDP වන අතර එය තීරණයක් මිස තනිවම දිස්වන විකල්පයක් නොවේ.

හඳුනාගැනීම ලිපින මත ගණිතයක්, firewall පරීක්ෂාවක් නොවේ

IKEv2 NAT හඳුනාගැනීමේ ගෙවුම් දරයි, ඒවායේ මූලාශ්‍ර සහ ගමනාන්ත ලිපින සහ වරායවල hash අඩංගු වේ. සෑම පැත්තක්ම ලැබුණු දේ දේශීයව දකින දේ සමඟ සසඳයි, නොගැළපීමක් එයට කියන්නේ යමක් packet එක පරිවර්තනය කළ බවයි. එම හුවමාරුවේ කිසිවක් මැද ඇති රවුටරයක් ප්‍රොටෝකෝලය 50 ඉදිරියට යවන්නේද යන්න පරීක්ෂා නොකරයි.

ප්‍රායෝගික ප්‍රතිවිපාකය සෘජුවම කීම වටී. native ESP සමඟ ක්‍රියා කළ උමගක් නව සීමාකාරී firewall එකක් තනිවම හඳුනා නොගනී, IKE දිගටම සාර්ථක වන අතර එහි ඊළඟ උත්සාහය දත්ත අදියරේදී අසාර්ථක වේ. ඔබට ස්ථාපිත IKE ආරක්ෂක සම්බන්ධතා පෙනෙනු ඇත, සහ ආරක්ෂිත ගමනාගමනයක් නැත, මෙය රැහැනේ ග්‍රහණය කරන තෙක් මාර්ගගත කිරීමේ දෝෂයක් ලෙස පෙනේ.

එබැවින් සංකේතනය යනු ඔබ වින්‍යාස කරන සම්බන්ධතාවයේ ගුණාංගයක් මිස ජාලයේ හැසිරීමෙන් පාර්ශ්වකරුවන් සාකච්ඡා කරන ප්‍රතිඵලයක් නොවේ.

encap හුවමාරුව වෙනස් කරන ආකාරය

නවීන strongSwan යෙදවුමක, එය swanctl.conf හරහා කළමනාකරණය වේ, සම්බන්ධතාවයේ encap = yes සැකසුම NAT හඳුනාගැනීමේ හුවමාරුවට බලපායි, එවිට දෙපැත්තම ESP සඳහා UDP සංකේතනය භාවිත කරයි. ආරක්ෂිත packet පසුව UDP තුළ, සාමාන්‍යයෙන් 4500 වරායේ ගමන් කරයි, දෙකෙළවරම එම සැකැස්මට එකඟ විය යුතුය.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

එම කොටස සැබෑ සම්බන්ධතා නිර්වචනයක් තුළට අයත් වන අතර සම්පූර්ණ අඩවි පැතිකඩක් නොවේ. ඔබ දැනටමත් ධාවනය කරන peer ලිපින, සත්‍යාපනය සහ child ගමනාගමන තේරීම් රඳවා ගන්න; එකතු කළ එකම යතුර ආරක්ෂිත දත්ත ඔතන ආකාරය වෙනස් කරයි, ඒවා ආරක්ෂා කරන දේ නොවේ.

strongSwan හි NAT-traversal මාර්ගෝපදේශය මෙම හැසිරීම විස්තර කරයි, MOBIKE භාවිත කරන විට වරාය පාවෙන අන්තර්ක්‍රියාවද ඇතුළුව.

ඔබේ backend එකට අයත් සැකසුම භාවිත කරන්න

strongSwan ට වින්‍යාස backend දෙකක් ඇත, යතුර ඒවා අතර වෙනස් වේ. swanctl.conf සම්බන්ධතාවයක් encap ගනී, පැරණි ipsec.conf සම්බන්ධතාවයක් forceencaps ගනී. එක් backend එකක keyword එක අනෙකට දැමීමෙන් පැමිණිල්ලක් නොමැතිව load වන සහ කිසිවක් නොවනස් කරන වින්‍යාසයක් සාදයි, එය දෝෂයකටත් වඩා නරකය.

කිසිවක් සංස්කරණය කිරීමට පෙර ඇත්තටම ධාවනය වන daemon එක කුමක්දැයි පරීක්ෂා කරන්න. බොහෝ බෙදාහැරීම්වල දෙකම ගොනු පවතින්නේ එකක් පෙර සංක්‍රමණයක ඉතිරියක් වන බැවිනි, සක්‍රීය එක වන්නේ සේවා ඒකකය ආරම්භ කරන එකයි. ගොනු වේලා මුද්‍රාවලින් අනුමාන කිරීම වෙනුවට එම ඒකකය කියවන්න. මෙහි තත්පර පහක පරීක්ෂාවක් කිසිවක් load නොකළ සැකසුමක් පැය ගණනක් පරීක්ෂා කිරීම වළක්වයි.

සම්බන්ධතාවයේ හිමිකරු හරහා වෙනස යොදන්න, පාලිත කවුළුවක් තුළ සම්බන්ධය නැවත ස්ථාපිත කරන්න. දැනටමත් ස්ථාපිත child එකක් ප්‍රතිස්ථාපනය වන තෙක් එහි වර්තමාන සංකේතනය රඳවා ගනී, එබැවින් ගොනුව සංස්කරණය කිරීම පමණක් නව සැකැස්ම භාවිතයේ ඇති බව ඔප්පු නොකරයි.

ඔතා ඇති දත්ත සත්‍යාපනය කරන්න, වරාය පමණක් නොවේ

ආරක්ෂිත ගමනාගමනය ගලා යන අතරේ ද්වාරයේ ග්‍රහණය කරන්න, පසුව එය strongSwan හිම දර්ශනය සමඟ සසඳන්න:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

native ESP IP ප්‍රොටෝකෝලය 50 ලෙස පෙනෙන අතර UDP සමඟ කිසිසේත් සමාන නොවේ. ඔතා ඇති ESP 4500 මත UDP ඩේටාග්‍රෑම් ලෙස පෙනෙන අතර ඒවායේ පේලෝඩය IKE නොවේ. එම වරායේම IKE ගමනාගමනය සංකේතනයේ සාක්ෂියක් නොවේ, මන්ද MOBIKE IKE එහි ගෙන යා හැකි අතර දත්ත මාර්ගය native ලෙස පවතී, එබැවින් වරාය අංකය නොව පේලෝඩය කියවන්න.

මාර්ගයේ MTU ද සිතේ තබා ගන්න. ආවරණය අමතර වියදමක් එකතු කරයි, native ESP ගෙන ගිය මාර්ගයකට packet විශාල වන විට සකස් කිරීම් අවශ්‍ය විය හැක. අවශ්‍ය ICMP හැසිරවීම දැනටමත් නිර්මාණයේ කොටසක් විය යුතුය; සංකේතනය එම යැපීම ඉවත් නොකරයි.

උමග තුළ නව යෙදුම් ගමනාගමනය දෙකෙළවරම ඔතා ඇති ESP ලෙස ග්‍රහණයේ දිස්වන විට, සහ අභ්‍යන්තර සේවාව සහ එහි ආපසු මාර්ගය තවමත් ක්‍රියා කරන විට වෙනස පිළිගන්න. ඊට අඩු ඕනෑම දෙයක් ගොනුවක නිවැරදිව පෙනෙන වින්‍යාසයකි.

අදාළ ලිපි