Linux හි IPsec නොමැතිව L2TP: xl2tpd, pppd සහ NAT
සැහැල්ලු L2TP යනු විවෘත PPP ය: xl2tpd, pppd විකල්ප සහ chap-secrets සකසන්න, MTU 1460 තෝරන්න, UDP 1701 එක් කෙළවරක සිට අනෙක් කෙළවර දක්වා අවසර දෙන්න, පසුව සේවාලාභී ප්රවේශය සඳහා NAT එකතු කරන්න.
සැහැල්ලු L2TP යනු ලියුම් කවරයක් තුළ ඇති PPP ය, ඊට වඩා කිසිවක් නොවේ. එය ඔබේ රාමු රැගෙන යයි; ඒවා සංකේතනය නොකරයි, අනෙක් කෙළවරේ කවුරුන් සිටීද යන්නද ඔප්පු නොකරයි, එබැවින් සෑම වින්යාසයක්ම පාහේ ඊට යටින් IPsec තබයි. නිර්මල අනුවාදය ධාවනය කිරීමට අවංක හේතු තවමත් ඇත: පරීක්ෂණාගාර බංකුවක්, සංක්රමණ පියවරක්, හෝ දැනටමත් වෙනත් ආරක්ෂිත මාර්ගයක් තුළ පවතින සබැඳියක්.
ඔබ ඉදිරියට යන්නේ නම්, එම අනතුරු ඇඟවීම නිර්මාණ සටහනේ ලියා එහිම තබන්න. ඊළඟට ඇත්තේ Debian සහ RHEL පවුලේ සත්කාරකවල මා භාවිතා කරන මෙහෙයුම් මාර්ගයයි: කුමන ගොනුව කුමකට වගකිව යුතුද, සම්භාව්ය අවහිරතාව වළක්වන MTU, සහ උමඟ වටිනා කරන යොමු කිරීමේ නීති.
ගොනු තුනක් වැඩ බෙදා ගනී
xl2tpd පාලන සම්බන්ධය අවසන් කර සෑම සැසියක්ම PPP ඩේමනයට භාර දෙයි, එබැවින් වින්යාසය එකිනෙකාගේ ගොනු නොකියවන වැඩසටහන් දෙකක් අතර බෙදී යයි. ශ්රාවකය /etc/xl2tpd/xl2tpd.conf තුළ, [lns default] කොටස තුළ ජීවත් වේ; එය ලිපින තටාකය ip range ලෙසද, සේවාදායක පැත්ත local ip ලෙසද, PPP වෙත භාර දීම pppoptfile ලෙසද නම් කරයි. require authentication = yes සක්රීය කරන්න, length bit සහ flow bit සක්රීයව තබන්න, සත්කාරකයේ වෙනත් කිසිවක් භාවිතා නොකරන තටාකයක් තෝරන්න.
PPP ප්රතිපත්තිය එම විකල්පය නම් කරන ගොනුවට අයත් වේ, සාමාන්යයෙන් /etc/ppp/options.xl2tpd: auth, pap, chap සහ mschap සඳහා ප්රතික්ෂේප, require-mschap-v2, 1460 හි MTU සහ MRU, සහ සබැඳිය ඉහළ නැඟීමෙන් පසු සේවාලාභියාට ළඟා විය හැකි DNS ලිපිනය. අක්තපත්ර නැවතත් තෙවන ගොනුවකි, /etc/ppp/chap-secrets, එහි දෙවන ක්ෂේත්රය LNS කොටසේ නමට ගැළපිය යුතු අතර සිව්වන ක්ෂේත්රයට තටාකයෙන් නිශ්චිත ලිපිනයක් සවි කළ හැක.
උමඟ සම්බන්ධ වී පසුව ඇලී යන්නේ ඇයි
1500 බයිට් Ethernet රාමුවක් තමන්ගේම ශීර්ෂවලට බයිට් වැය කරන මාර්ගයක් තුළ නොගැළපේ. පිටත IPv4 ශීර්ෂය 20ක් ගනී, UDP 8ක්, සහ L2TP ශීර්ෂය ආසන්න වශයෙන් 12ක්, එයින් PPP සහ එහි භාරය සඳහා 1460ක් ඉතිරි වේ. PPP තුළ එම කුඩා සංඛ්යාව ප්රකාශ කිරීම විශාල පැකට් කැබලි වීමෙන් හෝ මැද කොහේ හෝ නිහඬව වැටීමෙන් වළක්වයි.
රෝග ලක්ෂණය වන්නේ සැබෑ රථවාහන එනතෙක් නිරෝගී ලෙස පෙනෙන උමඟකි: පිංග සහ පාලන පණිවිඩ ගමන් කරයි, ගොනු පිටපතක් එකතැන ඇලී යයි, ලොගයේ කිසිවක් එය පැහැදිලි නොකරයි. දෙකෙළවරේම MTU සහ MRU එකට අඩු කරන්න. සේවාලාභියා පමණක් සකස් කිරීම සාමාන්යයෙන් තද ඇලීමක් වරින් වර එන ගැටලුවක් බවට පත් කරයි, එය නිර්ණය කිරීම වඩා නරකය.
එක් වරායක් සංවාද දෙකක් ගෙන යයි
UDP 1701 ප්රොටොකොලයේ දෙකොටස් දෙකටම යටින් පවතී, එම එකම කරුණ සැකසුමේ වෙනත් ඕනෑම කොටසකට වඩා firewall නීති බිඳ දමයි. මුලින්ම පාලන සම්බන්ධය ආරම්භ කිරීමේ ඉල්ලීම සහ එහි පිළිතුර එයි; ඉන්පසු එන සැසි ඉල්ලීම සහ තහවුරු කිරීම හඳුනා ගන්නා යුගලයට වඩා කිසිවක් ස්ථාපිත නොකරයි. පසුව PPP වගකීම ගනී: සබැඳි පාලනය, පසුව සත්යාපනය, පසුව ලිපින එකඟ කිරීමට IP පාලන ප්රොටොකොලය. සෑම අදියරකටම ලොගයේ තමන්ගේම වචන මාලාවක් ඇත, සහ කිසිවක් තමන් L2TP අසාර්ථකත්වයක් ලෙස ප්රකාශ නොකරයි.
හරියටම එම අනුපිළිවෙලින් ග්රහණයක් කියවීමෙන් කුමන අදියර අසාර්ථක වියද යන්න කියයි, PPP සත්යාපන අසාර්ථකත්වය xl2tpd සංස්කරණය කිරීමෙන් නොතැකී යයි. හවුල් වරාය තවත් පොදු අසාර්ථකත්වයක් පැහැදිලි කරයි: ප්රවාහයක පළමු පැකට් පමණක් අවසර දෙන නීතිය සැසිය ස්ථාපිත වීමට ඉඩ දී පසුව මාරු කිරීම අවහිර කරයි. මුළු සංවාදය සඳහාම 1701, දෙපැත්තටම අවසර දෙන්න.
උමඟ ප්රයෝජනවත් කිරීම: යොමු කිරීම සහ NAT
සැසියක් තනිවම සේවාදායකයට පමණක් ළඟා වේ. සේවාලාභී අන්තර්ජාල ප්රවේශයට යොමු කිරීම, ඉහළ සබැඳියේ තටාකය සඳහා NAT නීතියක්, සහ සබැඳිය ඉහළ නැඟීමෙන් පසු සේවාලාභියාට සැබවින්ම විමසිය හැකි DNS අවශ්ය වේ. තටාකය LAN පරාසයෙන් පිටතද තිබිය යුතුය, නැතහොත් සේවාලාභීන්ට යැවූ පිළිතුරු උමඟට ආපසු තල්ලු කරනවා වෙනුවට දේශීයව බෙදා හරිනු ලැබේ.
සේවාදායකයේ sysctl -w net.ipv4.ip_forward=1 සමඟ යොමු කිරීම සක්රීය කරන්න, iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE සමඟ තටාකය පරිවර්තනය කරන්න, පසුව -i ppp0 -o eth0 සඳහා FORWARD නීතියකින් පිටතට යන උමං රථවාහන සහ දර්පණ නීතිය සමඟ -m state --state RELATED,ESTABLISHED මගින් ආපසු එන රථවාහන පිළිගන්න. එම නීති නැවත ඇරඹීම් අතර රඳවා තබන්න, මන්ද ඒවා නොමැතිව ආපසු එන සේවාදායකය කැඩුණු L2TP වින්යාසයක් මෙන්ම පෙනේ.
සේවාදායකයේම LAN වෙත ළඟා වීම වෙනත් කාර්යයකි: LAN රවුටරයේ තටාකය සඳහා ආපසු මාර්ගයක් එකතු කරන්න, නැතහොත් සේවාදායකයේ proxy ARP භාවිතා කරන්න. LAN තුළ කිසිවක් සේවාලාභීන් ඍජුවම ආමන්ත්රණය කළ යුතු විට ඔවුන් NAT පිටුපස සැඟවීම පසුවට දෙවන නිදොස් කිරීමේ සැසියක් සැලසුම් කිරීම පමණි.
නිර්මල තට්ටුව කුමක් නොකරයිද, සහ තහවුරු කරන්නේ කෙසේද
මෙම තට්ටුවේ කිසිදු කොටසක් PPP රාමු සංකේතනය නොකරයි, එහි කිසිවක් ඔබ සැබවින්ම තෝරාගත් සේවාදායකය ලෙස දුර කෙළවර සත්යාපනය නොකරයි. MS-CHAPv2 බලා සිටින ශ්රාවකයෙකුගෙන් අක්තපත්ර හුවමාරුව ආරක්ෂා කරයි, නමුත් මාර්ගයේ සිටින ප්රහාරකයෙකුට තවමත් සැසියට බාධා කළ හැක. Windows හි ස්වදේශීය සේවාලාභියා L2TP ලබා දෙන්නේ IPsec සමඟ පමණක් බැවින් Linux, රවුටර භාස්තුර සහ තෙවන පාර්ශ්ව සේවාලාභීන් ඔබේ සහකරුවන් ලෙස සලකන්න. නිර්මල වින්යාසය නිර්ණයේ පියවරක් ලෙස සලකන්න, කිසිදා නැවතීමේ ස්ථානයක් ලෙස නොවේ.
නිශ්චිත අනුපිළිවෙලකින් තහවුරු කරන්න: xl2tpd -D ඉදිරිපසින් ධාවනය කරන්න, PPP අදියර සඳහා ජර්නලය නිරීක්ෂණය කරන්න, දෙකෙළවරේම ip addr වෙතින් පවරන ලද ලිපිනය කියවන්න, පසුව සැසිය ඉහළ නැඟීමෙන් පසු දත්ත ගලා යන බව තහවුරු කිරීමට UDP 1701 ග්රහණය කරන්න. හතරම ගැළපුණත් රථවාහන තවමත් අසාර්ථක නම්, දෝෂය යොමු කිරීම, NAT හෝ MTU තුළ ය, L2TP තුළම නොවේ.