PPTP कनेक्ट होते आणि नंतर Linux NAT मागे अडकते: GRE हेल्पर

कोणीतरी 1723 फॉरवर्ड करतो, क्लायंट सर्व्हरपर्यंत पोहोचतो, प्रमाणीकरण सुरू होते आणि मग सर्व काही त्रुटीशिवाय थांबते। स्वाभाविक निष्कर्ष चुकीचा पासवर्ड असतो, म्हणून पासवर्ड तीन वेळा पुन्हा टाइप केला जातो। फॉरवर्ड ठीक होता आणि क्रेडेन्शियल्स ठीक होते। जे तुटले ते म्हणजे दुसरे प्रोटोकॉल जे फॉरवर्डने कधीच झाकले नाही, आणि कर्नेलचे डीफॉल्ट मूल्य ज्याने त्यात मदत करणे शांतपणे थांबवले।

फॉरवर्ड कधीच समस्या नव्हता

पोर्ट-फॉरवर्ड नियम TCP किंवा UDP रहदारी वर्णन करतो। सत्राच्या मध्यात दुसऱ्या IP प्रोटोकॉलवर जाणारे पेलोड तो वर्णन करू शकत नाही, आणि PPTP नेमके तेच करते।

म्हणूनच कनेक्शन अडकण्याच्या क्षणापर्यंत निरोगी दिसते। पोर्ट नियम ज्या भागावर नियंत्रण ठेवू शकतो तो यशस्वी झाला, आणि ज्या भागावर ठेवू शकत नाही तोच अपयशी भाग आहे।

नियंत्रणासाठी TCP, डेटासाठी GRE

कॉल TCP 1723 वर वाटाघाटी केला जातो। तो उभा राहिल्यावर पेलोड GRE मध्ये, IP प्रोटोकॉल 47 मध्ये जाते, जो पोर्ट क्रमांक अजिबात वाहत नाही। पोर्टवर अवलंबून असलेल्या नियमाकडे जुळवण्यासाठी काहीच नाही।

GRE जे वाहते ते त्याच्या हेडरमधील कॉल ओळखकर्ता असते, आणि NAT अनुवादकाने ते क्षेत्र दोन्ही दिशांमध्ये सातत्याने पुन्हा लिहावे, अन्यथा सत्राचे दोन अर्धे एकमेकांशी सहमत होणे थांबवतात। एक दिशा पुन्हा लिहिली आणि दुसरी नाही तर प्रमाणीकरण होऊन नंतर प्रत्येक डेटा पॅकेट टाकून दिले जाते असे सत्र तयार होते। लक्षणाचा आकार नेमका हाच आहे: यश, आणि मग शांतता।

PPTP शिवाय नग्न GRE ला अशा पुनर्लेखनाची गरज नसते, म्हणूनच साधा GRE बोगदा त्याच मार्गावर PPTP क्लायंटसाठी अपयशी ठरणाऱ्या राउटरमधून काम करू शकतो।

चार मॉड्यूल्स आणि त्यांना बंद केलेला 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 फार पूर्वीपासून अप्रचलित आहेत, म्हणून मॉड्यूल लोड करणे तात्पुरती दुरुस्ती माना आणि देखभाल केलेल्या प्रोटोकॉलकडे जाण्याची योजना करा।