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 మరియు ఫిల్టరింగ్ యొక్క ఒక పొరను తొలగిస్తుంది, ఇది తరచుగా చౌకైన నిర్ణయం.