PPTP కనెక్ట్ అవుతుంది, ఆపై Linux NAT వెనుక వేలాడుతుంది: GRE సహాయకుడు

ఎవరో 1723ని ఫార్వర్డ్ చేస్తారు, క్లయింట్ సర్వర్కు చేరుకుంటుంది, ప్రామాణీకరణ ప్రారంభమవుతుంది, ఆపై అన్నీ లోపం లేకుండా ఆగిపోతాయి. సహజమైన ముగింపు తప్పు పాస్వర్డ్, కాబట్టి పాస్వర్డ్ మూడుసార్లు మళ్లీ టైప్ చేయబడుతుంది. ఫార్వర్డ్ బాగానే ఉంది మరియు ఆధారాలు బాగానే ఉన్నాయి. విరిగినది ఫార్వర్డ్ ఎప్పుడూ కవర్ చేయని రెండవ ప్రోటోకాల్, మరియు దానితో సహాయం చేయడాన్ని నిశ్శబ్దంగా ఆపిన కెర్నల్ డిఫాల్ట్.

ఫార్వర్డ్ ఎప్పుడూ సమస్య కాదు

పోర్ట్-ఫార్వర్డ్ నియమం TCP లేదా UDP ట్రాఫిక్ను వివరిస్తుంది. సెషన్ మధ్యలో మరో IP ప్రోటోకాల్కు మారే పేలోడ్ను అది వివరించలేదు, PPTP సరిగ్గా అదే చేస్తుంది.

అందుకే కనెక్షన్ వేలాడే క్షణం వరకు ఆరోగ్యంగా కనిపిస్తుంది. పోర్ట్ నియమం నియంత్రించగల భాగం విజయవంతమైంది, నియంత్రించలేని భాగమే విఫలమైన భాగం.

నియంత్రణకు TCP, డేటాకు GRE

కాల్ TCP 1723పై చర్చించబడుతుంది. అది లేచిన తర్వాత పేలోడ్ GRE లోకి, IP ప్రోటోకాల్ 47 లోకి వెళుతుంది, అది ఎలాంటి పోర్ట్ నంబర్లను మోసుకుపోదు. పోర్టులపై ఆధారపడే నియమానికి సరిపోల్చడానికి ఏమీ లేదు.

GRE మోసేది దాని హెడర్లోని కాల్ గుర్తింపుదారు, మరియు NAT అనువాదకుడు ఆ ఫీల్డ్ను రెండు దిశలలో స్థిరంగా తిరిగి రాయాలి, లేకపోతే సెషన్ రెండు భాగాలు ఒకదానితో ఒకటి ఏకీభవించడం ఆపేస్తాయి. ఒక దిశ తిరిగి రాయబడి మరొకటి కాకపోతే ప్రామాణీకరించి ఆపై ప్రతి డేటా ప్యాకెట్ను విసిరే సెషన్ ఏర్పడుతుంది. లక్షణం ఆకారం సరిగ్గా అదే: విజయం, ఆపై నిశ్శబ్దం.

PPTP లేని బేర్ GRE కి అలాంటి పునర్లేఖనం అవసరం లేదు, అందుకే అదే మార్గంలో PPTP క్లయింట్కు విఫలమయ్యే రూటర్ గుండా సాధారణ GRE టన్నెల్ పనిచేయగలదు.

నాలుగు మాడ్యూల్స్ మరియు వాటిని ఆఫ్ చేసిన 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 చాలా కాలం క్రితమే పాతబడ్డాయి, కాబట్టి మాడ్యూల్ లోడ్ను తాత్కాలిక సరిదిద్దుగా పరిగణించి, నిర్వహించబడే ప్రోటోకాల్కు మారడానికి ప్రణాళిక వేయండి.