PPTP passthrough இல்லை: Windows VPN பிழை 807 சரிசெய்தல்

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

போர்ட் அட்டவணையில் நெறிமுறை எண்ணுக்கு வரிசை இல்லை

PPTP வெவ்வேறு வழிகளில் தோல்வியடையும் இரண்டு உரையாடல்களைப் பயன்படுத்துகிறது. TCP 1723 இல் உள்ளது அழைப்பைத் தொடங்கி, இணைப்புத் தகவலைக் கடத்தி, பயனர் துண்டிக்கும்போது அதைக் கலைக்கிறது. சுமைப் பகுதி GRE இன் உள்ளே இயங்குகிறது, அதை IP தலைப்பு நெறிமுறை எண் 47 எனக் குறிக்கிறது, அந்தச் சுரங்கப்பாதையின் உள்ளே PPP இணைப்பைப் பேசுகிறது, MS-CHAPv2 சான்றுகளைச் சரிபார்க்கிறது.

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

தரவுப் பாதை இறக்கும்போது Windows என்ன தெரிவிக்கிறது

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

கடவுச்சொல்லைத் தொடுவதற்கு முன் போக்குவரத்தில் வேலை செய்யுங்கள். 807 ஐத் துரத்தி சான்றுகளை மாற்றுவது உண்மையான குறையை அப்படியே வைத்து அடுத்த முயற்சியைப் படிக்கக் கடினமாக்குகிறது.

இரண்டாவது கிளையண்ட் வேலை செய்யும் சுரங்கப்பாதையை உடைப்பது ஏன்

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

இரண்டு கிளையண்டுகளும் அழைக்கும்போது இணைப்பு அட்டவணையைப் பாருங்கள். முதல் ஹோஸ்ட் மட்டுமே எப்போதும் மேப்பிங்கை வைத்திருந்தால், ரவுட்டர் தான் ஆதரிக்கும் எல்லையை அடைந்துவிட்டது, கிளையண்ட் பக்க அமைப்பு எதுவும் அதை நகர்த்தாது.

எந்தப் பாதி தோல்வியடைகிறது என்பதை நிரூபியுங்கள்

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

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

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

tcpdump -ni any proto 47

Wireshark சமன்பாடு காட்சி வடிகட்டி ip proto 47, இதை shell இல் வசதியில்லாத ஒருவரிடம் கொடுப்பது எளிது. பதிலாக எதுவும் வெளியேறாமல் GRE வந்தால், திரும்பும் பாதையைச் சரிசெய்ய வேண்டும்.

பிழையை உண்மையில் சரிசெய்வது எது

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

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

PPTP ஐ மாற்றுவது மற்ற விருப்பம், பெரும்பாலும் மலிவானது. VPN ஐ தானே முடிக்கும் ரவுட்டர் உள்வரும் கிளையண்டுகளுக்கு இரட்டை NAT ஐத் தவிர்க்கிறது, போர்ட் அடிப்படையிலான NAT ஏற்கனவே கையாளும் நெறிமுறைக்கு passthrough தேவையே இல்லை: UDP மீது OpenVPN, TCP 443 மீது SSTP, அல்லது ESP ஐ UDP 4500 இல் சுற்றும் NAT-T உடன் L2TP/IPsec. PPTP MS-CHAPv2 ஐச் சார்ந்துள்ளது, அதன் ஆவணப்படுத்தப்பட்ட பலவீனங்கள் பிழை நீங்கிய பிறகும் புதிய பயன்பாட்டுக்கு அதை மோசமான தேர்வாக்குகின்றன.

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