Docker இல் PPTP அங்கீகரிக்கிறது ஆனால் எந்த டிராஃபிக்கையும் எடுத்துச் செல்லவில்லை

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

அதிக நேரத்தைச் சேமிக்கும் வரிசையில் ஐந்து சோதனைகள்.

சோதனை 1: கட்டுப்பாட்டு சேனலை பேலோடிலிருந்து பிரிக்கவும்

PPTP TCP 1723 இல் அங்கீகரிக்கிறது, பின்னர் PPP பேலோடை GRE, IP நெறிமுறை 47 க்குள் எடுத்துச் செல்கிறது. GRE TCP அல்லது UDP அல்ல, எனவே கட்டுப்பாட்டு துறைமுகத்தை அனுப்பும் ஒவ்வொரு விதியும் அதைப் பற்றி எதுவும் கூறவில்லை. 1723 ஐ அனுமதிக்கும் NAT அல்லது ஃபயர்வால் 47 நெறிமுறையைப் புகாரின்றி விட்டுவிடலாம், மேலும் அமர்வு வெற்றி போலத் தோன்றும் வகையில் பாதியாகக் கட்டப்பட்டே இருக்கும்.

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

சோதனை 2: ஹோஸ்ட் கர்னலில் உதவியாளரை உறுதிப்படுத்தவும்

இணைப்பு கண்காணிப்பு உதவியாளர் இல்லாமல் TCP கட்டுப்பாட்டு இணைப்பை GRE ஓட்டத்துடன் இணைக்க முடியாது. தொகுதி nf_conntrack_pptp ஆகும், அது ஹோஸ்ட் கர்னலில் வாழ்கிறது, கண்டெய்னர் படத்திற்குள் அதை ஏற்றுவதால் எதுவும் ஆகாது ஏனெனில் தொகுதிகள் முழு ஹோஸ்ட்டுக்கும் பொருந்தும். Docker ஹோஸ்ட்டில் lsmod | grep nf_conntrack_pptp தான் சோதனை. அது இல்லாவிட்டால், modprobe nf_conntrack_pptp அதை இயங்கும் கர்னலுக்கு ஏற்றுகிறது, அடுத்த துவக்கத்தைப் பற்றி எதுவும் கூறவில்லை, எனவே அதை ஹோஸ்ட் உள்ளமைவிலும் சேர்க்கவும்.

மறுதுவக்கத்தில் மறையும் தொகுதி அடுத்த மாதம் அதே டிக்கெட்டாக மாறும்.

சோதனை 3: அதை முடக்கும் கர்னல் கொள்கையைப் படிக்கவும்

தொகுதி இருந்தாலும், 4.7 முதல் கர்னல்கள் net.netfilter.nf_conntrack_helper ஐ இயல்பாக 0 ஆக அமைக்கின்றன, இது ஒவ்வொரு நெறிமுறைக்கும் தானியங்கி உதவியாளர் ஒதுக்கீட்டை அணைக்கிறது. அந்த இயல்புநிலை காரணமாகவே சரியாக நிறுவப்பட்ட தொகுதியும் எதுவும் செய்யவில்லை: குறியீடு உள்ளது, கொள்கை அதைப் பயன்படுத்த வேண்டாம் என்கிறது. sysctl net.netfilter.nf_conntrack_helper தற்போதைய மதிப்பைப் புகாரளிக்கிறது, இயக்க நேரத்தில் அதை 1 ஆக அமைப்பது உதவியாளரை மீண்டும் கிடைக்கச் செய்கிறது. வடிவமைப்பு அனுமதித்தால் ஹோஸ்ட்டின் sysctl உள்ளமைவு மூலம் மதிப்பை நிலைநிறுத்தவும்.

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

சோதனை 4: கண்டெய்னரின் பாதையைத் தனியாகப் பார்க்கவும்

ஏற்றப்பட்ட உதவியாளர் ஒரு பாதையை உருவாக்காது. கண்டெய்னருக்கு PPTP சேவையகத்திற்கு பாதை தேவை, ஹோஸ்ட் அனுப்புதல் இரு திசைகளிலும் GRE ஐ அனுமதிக்க வேண்டும்: iptables -L FORWARD -v -n 47 நெறிமுறை ஏற்கப்படுகிறதா, கவுண்டர்கள் நகர்கின்றனவா என்பதைக் காட்டுகிறது. Docker இன் masquerade விதிகள் TCP மற்றும் UDP ஐ மொழிபெயர்க்கின்றன, 47 நெறிமுறையை அல்ல, எனவே பிரிட்ஜ் கண்டெய்னருக்கு வெளிப்படையான forward அனுமதியும் சில ஹோஸ்ட்களில் அதன் சொந்த மொழிபெயர்ப்பு விதியும் தேவைப்படலாம். கண்டெய்னர் அதன் படம் எதிர்பார்க்கும் PPP சாதன ஆதரவைக் கொண்டிருப்பதையும் உறுதிப்படுத்தவும்.

விதியின் உரையை அல்ல, கவுண்டர்களைப் படிக்கவும். இருக்கும் ஆனால் எதனுடனும் பொருந்தாத விதி அலங்காரம்.

சோதனை 5: GRE கண்காணிக்கப்படுவதை நிரூபித்து, பின்னர் PPTP பற்றி முடிவு செய்யவும்

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

PPTP தானே பழையது, MS-CHAPv2 பலவீனமானது. சேவையகம் L2TP/IPsec, IKEv2 அல்லது WireGuard ஐயும் வழங்கினால், அவற்றில் ஒன்றுக்கு மாறுவது இந்த முழு வகைப் பிரச்சினைகளையும் நீக்குகிறது.

PPTP இருக்க வேண்டிய இடத்தில், கண்டெய்னருக்குள் அல்லாமல் ஹோஸ்ட்டில் கிளையண்டை இயக்குவது NAT மற்றும் வடிகட்டுதலின் ஒரு அடுக்கை நீக்குகிறது, இது பெரும்பாலும் மலிவான முடிவு.