pptpd இல் GRE எழுத்து தோல்விகள் கடவுச்சொல் பிரச்சினை அல்ல

பதிவில் GRE எழுத்து தோல்வி, முதல் உணர்வு பயனரின் கடவுச்சொல்லை மீட்டமைப்பது. அந்த உணர்வு கிட்டத்தட்ட எப்போதும் தவறு. இந்த செய்திகள் அடையாளச் சான்று சரிபார்ப்பை அல்ல, தரவுப் பாதையை விவரிக்கின்றன: வாடிக்கையாளர் வெற்றிகரமாக அங்கீகரிக்கப்பட்டு பின்னர் பிணையத்தில் பதிவு செய்யும் நிலையில் நின்றிருக்கலாம். இரண்டு வெவ்வேறு செய்திகள் இரண்டு வெவ்வேறு தோல்விகளைச் சுட்டுகின்றன, எதுவும் புதிய கடவுச்சொல்லால் தீரவில்லை.

இரண்டு செய்திகள், இரண்டு வெவ்வேறு தோல்விகள்

படிக்கும் தோல்வி என்பது GRE பொதிகைகள் ஒருபோதும் டீமனை அடையவில்லை அல்லது உள்ளே வரும்போது தூக்கி எறியப்படுகின்றன என்பதாகும். கட்டுப்பாட்டு இணைப்பு முழுவதும் ஆரோக்கியமாகத் தோன்றலாம், ஆனால் தரவுப் பாதையில் எதுவும் கடக்கவில்லை. அங்கீகாரம் மட்டுமே வெளிப்படையாக வேலை செய்தது.

எழுத்து தோல்வி பொதுவாக கர்னல் அல்லது வாடிக்கையாளரால் பயன்படுத்த முடியாத ஒன்றை அமர்வு பேச்சுவார்த்தை செய்தது என்று பொருள். கட்டுப்பாட்டு கால்வாய் முடிந்தது, அந்த பரிமாற்றத்தில் ஒப்புக்கொள்ளப்பட்ட விருப்பங்கள் இறுதிப் புள்ளிகள் உண்மையில் செய்யக்கூடியவற்றுடன் பொருந்தவில்லை. இது கட்டமைப்பு முரண்பாடு, அங்கீகார நிகழ்வு அல்ல.

எதையும் மாற்றுவதற்கு முன் இரண்டில் எது தோன்றுகிறது என்பதைப் படியுங்கள். அவை உங்களை வெவ்வேறு அடுக்குகளுக்கு அழைத்துச் செல்கின்றன, அவற்றை ஒரே அறிகுறியாகக் கருதுவதே ஒரே சேவையகம் தொடர்பற்ற காரணங்களுக்காக இரண்டு முறை இணைக்கப்படுவதற்குக் காரணம். பதிவு வரி மட்டுமே உங்களுக்குக் கிடைக்கும் ஒரே இலவச கண்டறிதல்.

நெறிமுறை 47 துறை 47 அல்ல

PPTP அழைப்பை அமைக்க TCP 1723 மற்றும் சுமையை எடுத்துச் செல்ல GRE பயன்படுத்துகிறது. GRE என்பது துறை எண் அல்ல, IP நெறிமுறை 47, எனவே துறை 47 ஐத் திறக்கும் ஃபயர்வால் விதி பயனுள்ள எதையும் அனுமதிக்கவில்லை.

பாதையில் உள்ள ரவுட்டருக்கு PPTP passthrough அம்சம் அல்லது வெளிப்படையான GRE அனுமதி தேவை. அது இல்லாமல் TCP கைக்குலுக்கல் முடிந்து சுரங்கப்பாதை ஒருபோதும் பொதியை எடுத்துச் செல்லாது, இது மேலே உள்ள படிக்கும் தோல்வியையே உருவாக்குகிறது. ஃபயர்வாலில் துறை 47 விதிகள் இந்த நெறிமுறையில் மிக அதிகம் வீணாகும் பிற்பகல்.

எந்தப் பக்கம் போக்குவரத்தைத் தூக்கி எறிகிறது என்று ஊகிப்பதற்குப் பதிலாக சேவையகத்தில் இரு திசைகளையும் ஒரே நேரத்தில் கவனியுங்கள்: tcpdump -ni any port 1723 or proto gre.

1723 அழைப்பு அமைப்பைக் காட்டி GRE அமைதியாக இருந்தால், தடுப்பு ஹோஸ்டுக்கு மேலே உள்ளது. GRE வந்து டீமன் இன்னும் தோல்வியடைந்தால், பிரச்சினை உள்ளூர் மற்றும் விருப்பங்களே அடுத்து பார்க்க வேண்டிய இடம்.

ஹோஸ்ட் உண்மையில் எங்கு அனுப்புகிறதோ அங்கு GRE ஐ அனுமதிக்கவும்

GRE க்கு forward விதியைச் செருகுவது சுரங்கப்பாதைப் போக்குவரத்தை அனுப்பும் ஹோஸ்டில் நியாயமான சோதனை, அது கொள்கை அல்ல. ஒரு நெறிமுறையின் அனைத்தையும் ஏற்கும் சோதனை விதி கண்டறிதல், வடிவமைப்பு அல்ல. எதையாவது கற்கும் அளவுக்கு வைத்திருந்து, பின்னர் வரையறுக்கப்பட்ட விதியால் மாற்றுங்கள்.

சேவையகத்திற்கே அனுப்பப்படும் பொதிகைகளுக்கு input விதியைச் சேர்க்கவும், ஏனெனில் forward சங்கிலி அவற்றைப் பார்க்கவில்லை. பின்னர் இணைப்பு முயற்சிக்கு முன்னும் பின்னும் விதியின் கவுண்டர்களைப் பாருங்கள், அது பொதிகைகள் வருகின்றனவா என்று சொல்லும்.

ஒவ்வொரு மறுதொடக்கத்திற்குப் பிறகும் மீண்டும் இயக்குவதற்குப் பதிலாக விநியோகத்தின் ஃபயர்வால் சேவை வழியாக விதியை நிரந்தரமாக்குங்கள். nftables ஹோஸ்டில் input மற்றும் forward இரண்டு சங்கிலிகளிலும் ip protocol gre பொருத்துங்கள்.

ppp_generic தொகுதியும் ஏற்றப்பட்டுள்ளதை உறுதிசெய்து, இணைப்பு கண்காணிப்பு திரும்பும் திசையைத் தூக்கி எறிகிறதா எனச் சரிபார்க்கவும். இரண்டும் ஃபயர்வால் பிரச்சினை போலத் தோன்றும் ஆனால் அல்லாத தோல்விகளை உருவாக்குகின்றன. இல்லாத கர்னல் தொகுதி சரிபார்க்கும் வரை தடுக்கப்பட்ட நெறிமுறை போலவே தோன்றும்.

உங்களிடம் உண்மையில் உள்ள வாடிக்கையாளருக்கு விருப்பங்களைப் பொருத்துங்கள்

மற்ற அறிக்கையின் திருத்தம் /etc/ppp/pptpd-options இல் உள்ளது, அங்கு செய்முறை PAP, CHAP மற்றும் MSCHAP ஐ நிராகரித்து, தொடர்புடைய require வரிகளை கருத்துரையாக்கி, நிலை MPPE ஐ வைத்திருக்கிறது. அந்த செய்முறை ஒரு வாடிக்கையாளர் கலவைக்கு எழுதப்பட்டது, கண்மூடித்தனமாக நகலெடுப்பது சாதாரண நிலையை உடைக்கிறது. நிராகரிப்பு வரிகளை பரிந்துரையாக அல்ல, ஆசிரியரிடம் எந்த வாடிக்கையாளர்கள் இருந்தனர் என்பதற்கான அறிக்கையாகப் படியுங்கள்.

Windows வாடிக்கையாளருக்கு பொதுவாக MS-CHAPv2 உடன் MPPE-128 தேவை. அந்தத் தேவைகளை வைத்திருந்து, வாடிக்கையாளர் உண்மையில் பேச்சுவார்த்தை செய்ய முடியாத விருப்பங்களை மட்டும் நீக்குங்கள்.

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

இணைப்பு வெற்றிபெற மறையாக்கத்தை அணைப்பது தரம் குறைப்பு, பழுது அல்ல. அத்தகைய மாறுபாட்டை ஆய்வக இணைப்பில் சோதித்து, சேவை உண்மையான வாடிக்கையாளர்களைச் சந்திப்பதற்கு முன் மறையாக்கத்தை மீட்டெடுங்கள். பாதுகாப்பற்ற முறையில் செயல்படும் இணைப்பு நேர்மையாகத் தோல்வியடையும் இணைப்பை விட மோசம்.

வாடிக்கையாளரின் பிழை எண்ணைப் படியுங்கள்

வாடிக்கையாளரின் எண் குறியீடு சேவையகப் பதிவை விட வேகமாக நிலையைக் குறைக்கிறது. வேறு எதையும் படிப்பதற்கு முன் அதைப் படியுங்கள். 691 என்பது அடையாளச் சான்றுகள் நிராகரிக்கப்பட்டன, 721 என்பது சேவையகம் ஒருபோதும் பதிலளிக்கவில்லை, 619 என்பது இணைப்பு துண்டிக்கப்பட்டது. எண்ணுடன் இரண்டு நிமிடங்கள் கட்டமைப்புடன் ஒரு மணி நேரத்தைச் சேமிக்கின்றன.

எதையும் திருத்துவதற்கு முன் அந்தக் குறியீட்டை சேவையகப் பதிவுடன் ஒப்பிட்டு, ஒவ்வொரு மாற்றத்திற்குப் பிறகும் அதே வாடிக்கையாளரிடம் மீண்டும் சோதியுங்கள். இல்லையெனில் இரண்டாவது தோல்வி முதல் தோல்விக்குப் பின்னால் மறைந்து திருத்தம் பயனற்றதாகத் தோன்றும்.

உள்நுழைவு வெற்றிபெற்று போக்குவரத்து நகரவில்லை என்றால், GRE இன்னும் சந்தேகத்திற்குரியது. அடையாளச் சான்று கிடங்கிற்குப் பதிலாகப் பிடிப்புக்குத் திரும்ப வேண்டிய தருணம் அது.