Linux இல் IPsec இல்லாமல் L2TP: xl2tpd, pppd மற்றும் 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 இல் அல்ல.