வீட்டு ரவுட்டருக்குப் பின்னால் PPTP சேவையகம்: முதலில் 1723 மற்றும் GRE சரிசெய்யுங்கள்

வீட்டு ரவுட்டருக்குப் பின்னால் PPTP இரண்டு தொடர்பற்ற வழிகளில் தோல்வியடைகிறது, அவற்றைக் குழப்புவது ஒரு முழு மாலையை வீணாக்கும். ஒரு தோல்வி அனுப்புதலில் உள்ள இடைவெளி: ரவுட்டர் TCP 1723 ஐக் கடத்தி IP நெறிமுறை 47 ஐ வீசுகிறது, அதனால் வாடிக்கையாளர் பிழை 619 இல் நிற்கிறது. மற்றொன்று அளவுப் பிரச்சினை: சுரங்கம் எழுகிறது, அங்கீகரிக்கப்படுகிறது, பின்னர் முழு அளவுப் பொதி கடக்க வேண்டியிருக்கும்போது உறைகிறது. இவற்றில் எது உங்களிடம் உள்ளது என்பதைக் கண்டறிவதே முதல் உண்மையான படி; மீதம் உங்கள் ரவுட்டர் எதை வெளிப்படுத்த முடியும் என்பதை ஒப்பிடுகிறது, எந்த பிராண்டு சிறந்தது என்பதை அல்ல.

இரண்டு கடத்திகள், அவற்றில் ஒன்றுக்கு மட்டுமே துறைமுகம் உள்ளது

PPTP இரண்டு கடத்திகளாகப் பிரிகிறது: TCP 1723 இல் கட்டுப்பாட்டு இணைப்பு, மற்றும் விரிவாக்கப்பட்ட GRE இல் சுற்றப்பட்ட PPP சட்டகங்கள், அதாவது IP நெறிமுறை 47. GRE க்கு துறைமுக எண் இல்லை, எனவே துறைமுகம் 1723 அனுப்புதல் என எழுதப்பட்ட விதி அதை மூட முடியாது, வலை இடைமுகம் அந்தப் புலத்திற்கு எந்தப் பெயர் கொடுத்தாலும். வீட்டு ரவுட்டர் பொதுவாக நெறிமுறை விதிக்குப் பதிலாக PPTP கடவு எனும் பெட்டியை வழங்குகிறது, அந்தப் பெட்டி இரண்டு வேலைகளைச் செய்கிறது: தீச்சுவர் வழியாக நெறிமுறை 47 ஐக் கடக்க விடுகிறது, NAT க்கு GRE ஓட்டத்தைப் பின்தொடரக் கற்பிக்கிறது. லினக்ஸ் ரவுட்டரில் இந்த வேலைகள் தனித் தொகுதிகள் மற்றும் தனி விதிகள், எனவே பாதி அமைக்கப்பட்ட கடவும் செயல்படும் கட்டுப்பாட்டு கால்வாயைத் தருகிறது. எதையும் மாற்றுவதற்கு முன் எந்தப் பாதி உள்ளது என்பதைக் கண்டறியுங்கள்.

சேவையகத்தின் சொந்தத் தீச்சுவரும் ரவுட்டர் முகவரியிலிருந்து நெறிமுறை 47 ஐ அனுமதிக்க வேண்டும். 1723/tcp மட்டும் ஏற்கும் புரவன் தீச்சுவர் LAN உள்ளிருந்து பிழை 619 ஐ மீண்டும் உருவாக்குகிறது, இது உடைந்த அனுப்புதலும் உடைந்த புரவன் விதியும் ஒரே மாதிரி தோற்றமளிக்கச் செய்கிறது.

sudo iptables -S FORWARD | grep -i gre
sudo nft list ruleset | grep -i gre
lsmod | grep -E 'nf_conntrack_proto_gre|nf_nat_proto_gre'

தொகுதிகள் இல்லாவிட்டால் sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre மூலம் ஏற்றி ஏற்றுதலை நிரந்தரமாக்குங்கள், ஏனெனில் உதவியாளரை மறக்கும் மறுதொடக்கம் செயல்படும் சுரங்கத்தை மீண்டும் பிழை 619 ஆக்குகிறது. அனுப்புதல் விதி நெறிமுறை 47 ஐ சேவையக முகவரி நோக்கி மட்டும் ஏற்க வேண்டும், முழு LAN அல்ல. RFC 2637 வரையறை கட்டுப்பாடு மற்றும் தரவுப் பாதையைப் பிரிக்கிறது, எனவே எந்த ஒரு துறைமுக அனுப்புதல் திரையும் PPTP ஐ முழுமையாக விவரிக்கவில்லை.

கடவு பெட்டியா அல்லது வெளிப்படையான நெறிமுறை விதியா

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

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

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

ரவுட்டரைக் குறை சொல்வதற்கு முன் சுரங்கத்தை அளவிடுங்கள்

PPTP பயனுள்ள சுமையைக் குறைக்கிறது, அந்தக் குறைவு மர்மமல்ல, கணிதம். ஒவ்வொரு சுரங்கப் பொதியும் வெளிப்புற IP தலைப்பு, விரிவாக்கப்பட்ட GRE தலைப்பு, PPP தலைப்பு, மறையாக்கத்துடன் MPPE தலைப்பு ஆகியவற்றைச் சுமக்கிறது. பாதை விளைந்த சட்டகத்தைச் சுமக்க முடியாதபோது, சிறிய பொதிகள் கடக்கின்றன, உள்நுழைவு முடிகிறது, கோப்புப் பரிமாற்றம் அல்லது TLS கைக்குலுக்கல் முழு அளவுப் பொதியை அனுப்பும் முதல் முறையில் அமர்வு நிற்கிறது.

ஊகிப்பதற்குப் பதிலாக எண்ணைக் கணக்கிடுங்கள். விரிவாக்கப்பட்ட GRE க்கு 8 பைட், PPP க்கு 4, MPPE க்கு 4, வெளிப்புற IP தலைப்புக்கு 20 ஆகும், எனவே சுரங்கம் எந்தச் சுமைக்கும் முன் 36 பைட்டை உண்ணும். 1492 இல் முடியும் PPPoE WAN இல் பொருந்தும் மிகப்பெரிய PPP MTU 1492 கழித்தல் 36, அதாவது 1456. PPP விருப்பங்களில் mtu மற்றும் mru ஐ அந்த மதிப்பில் அமைத்து துண்டாக்காத பிங்குடன் மீண்டும் சோதியுங்கள்.

ping -M do -s 1464 198.51.100.7
grep -E '^(mtu|mru)' /etc/ppp/options.pptpd

பிங் பாதையை அளவிடுகிறது, சுரங்கத்தை அல்ல: 1464 பைட் சுமை கூட்டல் 28 பைட் IP மற்றும் ICMP தலைப்புகள் 1492 பைட் சட்டகத்தை சரியாக நிரப்புகின்றன. அந்தப் பிங் தோல்வியடைந்தால் கடக்கும் வரை எண்ணைக் குறைத்து முடிவிலிருந்து 36 ஐக் கழியுங்கள். பாதையின் எல்லைக்கு மேல் அமைக்கப்பட்ட சுரங்க MTU அளவைக் குறிப்பிடும் ஒரு பதிவு வரியும் இல்லாமல் உறைவை உருவாக்குகிறது.

ஒரே ரவுட்டரில் PPTP, L2TP/IPsec அல்லது OpenVPN

ஒரே ரவுட்டர் மூன்று பொதுவான சுரங்கங்களில் எதையும் சுமக்க முடியும், வேறுபாடு அது எதை வெளிப்படுத்த வேண்டும் என்பதில். PPTP க்கு இரண்டு வெவ்வேறு அடுக்குகளில் இரண்டு விதிகள் தேவை. IPsec மேல் L2TP க்கு விசைப் பரிமாற்றத்திற்கு UDP 500 மற்றும் 4500 தேவை, NAT-T அதைச் சுமக்காவிட்டால் சுமைக்கு நெறிமுறை 50 தேவை. OpenVPN க்கு ஒரு UDP துறைமுகம் போதும், உதவியாளர் எதுவும் தேவையில்லை.

L2TP நிரல் தானாக GRE ஐ விட நட்பானது அல்ல. ESP என்பது IP நெறிமுறை 50, அதற்கும் துறைமுகம் இல்லை, எனவே நெறிமுறை 47 உடன் சிரமப்படும் ரவுட்டர் அதே காரணத்தால் நெறிமுறை 50 உடனும் சிரமப்படலாம். ESP ஐ UDP 4500 க்குள் சுற்ற NAT-T உள்ளது, இரு முனைகளும் ஆதரித்தால் நெறிமுறை 50 விதி தேவையற்றதாகிறது. அது முனைகளின் பண்பு, ரவுட்டரின் PPTP பெட்டியின் பண்பு அல்ல. இரண்டிற்கும் விதிகள் எழுதுவதற்கு முன் வாடிக்கையாளர் உண்மையில் எந்த மறையாக்கத்திற்கு உடன்பட்டது என்பதை உறுதிசெய்யுங்கள்.

OpenVPN ரவுட்டர் பக்கத்தில் மிகக் குறைந்த நகரும் பகுதிகள் கொண்ட விருப்பம். ஒரு UDP துறைமுகம், ஒரு அனுப்புதல், இணைப்பு-கண்காணிப்பு உதவியாளர் இல்லை, அழைப்பு அடையாள மீளெழுத்தும் இல்லை. பேரம் என்பது உள்ளமைந்த டயலருக்குப் பதிலாக நிறுவ வேண்டிய வாடிக்கையாளர், PPTP உரையாடலில் நீடிப்பதற்கான ஒரே காரணம் பெரும்பாலும் அதுவே.

எதைச் சரிசெய்வது, எதை மாற்றுவது

அனுப்புதல் மற்றும் MTU ஐச் சரிசெய்வது செயல்படும் சுரங்கத்தைத் தரும், வைத்திருக்க வேண்டியதை அல்ல. PPTP இன் MSCHAPv2 அங்கீகாரம் பல ஆண்டுகளாகத் தாக்குதலுக்கு உட்பட்டது, செயல்படும் சுரங்கம் இணைப்பில்லாமல் மீட்கக்கூடிய சான்றுகளைக் கடத்துகிறது. தொலைச் சாதனம் L2TP/IPsec அல்லது OpenVPN இயக்க முடிந்தால், சரிசெய்தலைத் தேதியுள்ள தற்காலிக நடவடிக்கையாகக் கருதுங்கள்.

முடிவு தொலை முனை எதை ஆதரிக்கிறது மற்றும் ஏற்பாடு எவ்வளவு காலம் நீடிக்க வேண்டும் என்பதைப் பொறுத்தது. PPTP மட்டும் பேசும் பழைய சாதனம் சரிசெய்தலைப் பெறும்; வாடிக்கையாளரை நிறுவக்கூடிய அனைத்தும் இடம்பெயர்கிறது.

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