PPTP இணைக்கிறது பிறகு Linux NAT பின்னால் தொங்குகிறது: GRE உதவியாளர்
TCP 1723 இணைக்கிறது, தரவுப் பாதை இறக்கிறது: PPTP போர்ட்டுகள் இல்லாத GRE-க்குள் பயணிக்கிறது. உதவியாளர்களை ஏற்றி, வெளிப்படையாக இணைத்து, நெறிமுறை 47-ஐத் திறக்கவும்.
யாரோ 1723-ஐ முன்னனுப்புகிறார்கள், வாடிக்கையாளர் சேவையகத்தை அடைகிறார், அங்கீகாரம் தொடங்குகிறது, பிறகு அனைத்தும் பிழையின்றி நிற்கிறது. இயல்பான முடிவு தவறான கடவுச்சொல், எனவே கடவுச்சொல் மூன்று முறை மீண்டும் தட்டச்சு செய்யப்படுகிறது. முன்னனுப்புதல் சரியாக இருந்தது, சான்றுகளும் சரியாக இருந்தன. உடைந்தது என்பது முன்னனுப்புதல் ஒருபோதும் மூடாத இரண்டாவது நெறிமுறை, மற்றும் அதற்கு உதவுவதை அமைதியாக நிறுத்திய கர்னல் இயல்புநிலை.
முன்னனுப்புதல் ஒருபோதும் சிக்கலாக இருக்கவில்லை
போர்ட் முன்னனுப்புதல் விதி TCP அல்லது UDP போக்குவரத்தை விவரிக்கிறது. அமர்வின் நடுவில் வேறு IP நெறிமுறைக்கு மாறும் பேலோடை அது விவரிக்க முடியாது, PPTP அதைத்தான் செய்கிறது.
அதனால்தான் இணைப்பு தொங்கும் தருணம் வரை ஆரோக்கியமாகத் தெரிகிறது. போர்ட் விதியால் நிர்வகிக்கக்கூடிய பகுதி வெற்றியடைந்தது, நிர்வகிக்க முடியாத பகுதியே தோல்வியடைந்த பகுதி.
கட்டுப்பாட்டுக்கு TCP, தரவுக்கு GRE
அழைப்பு TCP 1723 மீது பேச்சுவார்த்தை செய்யப்படுகிறது. அது எழுந்ததும் பேலோடு GRE-க்கு, IP நெறிமுறை 47-க்கு நகர்கிறது, அது எந்த போர்ட் எண்ணையும் சுமக்கவில்லை. போர்ட்டுகளைச் சார்ந்த விதிக்கு பொருத்த எதுவும் இல்லை.
GRE சுமப்பது அதன் தலைப்பகுதியில் உள்ள அழைப்பு அடையாளங்காட்டி, NAT மொழிபெயர்ப்பாளர் அந்தப் புலத்தை இரு திசைகளிலும் தொடர்ந்து மீண்டும் எழுத வேண்டும், இல்லையெனில் அமர்வின் இரு பகுதிகளும் ஒத்துப்போவதை நிறுத்தும். ஒரு திசை மீண்டும் எழுதப்பட்டு மற்றொன்று இல்லாவிட்டால், அங்கீகரித்த பிறகு ஒவ்வொரு தரவுப் பொதியையும் தூக்கி எறியும் அமர்வு உருவாகும். அறிகுறியின் வடிவம் அதுவே: வெற்றி, பிறகு மௌனம்.
PPTP இல்லாத வெறும் GRE-க்கு அத்தகைய மீளெழுத்து தேவையில்லை, அதனால்தான் அதே பாதையில் PPTP வாடிக்கையாளருக்கு தோல்வியடையும் திசைவழியாக்கியின் வழியாக சாதாரண GRE சுரங்கம் செயல்பட முடியும்.
நான்கு தொகுதிகள் மற்றும் அவற்றை அணைத்த sysctl
இரண்டு தொகுதிகள் சட்டகமாக்கலைக் கையாளுகின்றன, nf_conntrack_proto_gre மற்றும் nf_nat_proto_gre. மேலும் இரண்டு அழைப்பு அடையாளங்காட்டியைக் கையாளுகின்றன, nf_conntrack_pptp மற்றும் nf_nat_pptp. கடைசியை ஏற்றினால் மற்றவை சார்புகள் வழியாக வரும், எனவே தொகுதிப் பட்டியலில் நான்கும் காட்டப்பட வேண்டும்.
பழைய வழிமுறைகள் 2.6 காலத்தின் ip_ முன்னொட்டைப் பயன்படுத்துகின்றன. அந்தக் கட்டளைகள் எதையும் ஏற்றாமல் இயங்குவது போலத் தோன்றலாம், எனவே வெளியேறும் நிலையை அல்ல, ஏற்றப்பட்ட பட்டியலைச் சரிபார்க்கவும்.
அவற்றை ஏற்றியிருப்பது இனி போதாது. Linux 4.7 முதல் net.netfilter.nf_conntrack_helper sysctl இயல்பாக 0 ஆகும், இது புதிய ஓட்டங்களுக்கு தானியங்கி உதவியாளர் ஒதுக்கீட்டை முடக்குகிறது. ஒரு திசைவழியாக்கியில் எல்லா தொகுதிகளும் இருந்தும் எதையும் மொழிபெயர்க்காமல் இருக்கலாம். தொகுதிப் பட்டியலை மீண்டும் பார்க்கும் முன் பயனுள்ள மதிப்பைச் சரிபார்க்கவும்.
ஒன்று தானியங்கி ஒதுக்கீட்டை மீண்டும் உலகளவில் இயக்கவும், அல்லது தேவைப்படும் ஓட்டங்களில் உதவியாளரை இணைத்து மற்றதை அப்படியே விடவும்:
iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptpஇரண்டாவது விருப்பமே விரும்பத்தக்கது. முழு திசைவழியாக்கியிலும் தானியங்கி ஒதுக்கீட்டை மீண்டும் இயக்குவதற்குப் பதிலாக, நடத்தையை PPTP போக்குவரத்துக்கு மட்டுப்படுத்துகிறது.
போர்ட்டுகள் இல்லாத நெறிமுறையைத் திறப்பது
1723-ஐ அனுமதிக்கும் தீச்சுவர் விதி நெறிமுறை 47 பற்றி எதுவும் சொல்லவில்லை. firewalld-ல் வாடிக்கையாளரை நோக்கிய மண்டலத்தில் நெறிமுறையை அனுமதிக்கவும். சாதாரண iptables-ல் உள்ளீட்டுச் சங்கிலியில் gre நெறிமுறையை ஏற்கவும்.
பிறகு இரு பக்கமும் பிடிப்பு செய்யவும். வாடிக்கையாளரை விட்டுச் செல்லும் பொதிகளுக்கு பதில்கள் வரவில்லை என்றால் திரும்பும் பாதை வடிகட்டப்பட்டுள்ளது, அது நிராகரிக்கப்பட்ட சான்றிலிருந்து வேறுபட்ட குறைபாடு.
இணைந்த பிறகு, அளவு வரம்பு
GRE ஒரு தலைப்பைச் செருகுகிறது, அதற்குள் PPP இன்னும் சேர்க்கிறது, எனவே வேலை செய்யும் இணைப்பு 1500-க்கு மிகக் கீழே MTU தெரிவிக்கிறது. சிறிய பதில்கள் ஏற்றப்படுகின்றன, பெரியவை தொங்குகின்றன, இது முதல் சிக்கல் தீர்க்கப்படும் தருணத்தில் தோன்றும் இரண்டாவது, தொடர்பில்லாத சிக்கல் போலத் தெரிகிறது.
வாடிக்கையாளரின் PPP அடாப்டரில் MTU-வைப் படித்து திசைவழியாக்கியின் சொந்தக் கணக்கீட்டுடன் ஒப்பிடுங்கள் ஏதாவது வேலை செய்யும் வரை எண்களைக் குறைப்பதற்குப் பதிலாக. முழு அளவுப் பொதிகள் வெளியேறி எதுவும் திரும்பவில்லை என்றால் அது மொழிபெயர்ப்பை அல்ல, அந்த வரம்பைச் சுட்டுகிறது.
பாதையைச் சரிசெய்வது பயனரை வேலைக்குத் திரும்பக் கொண்டுவரும், அது PPTP-ஐ நல்ல தேர்வாக ஆக்காது. MS-CHAPv2 மற்றும் RC4 நெடுங்காலமாக வழக்கொழிந்தவை, எனவே தொகுதி ஏற்றுவதைத் தற்காலிகத் திருத்தமாகக் கருதி, பராமரிக்கப்படும் நெறிமுறைக்கு மாறத் திட்டமிடுங்கள்.