లాగ్లో GRE రాత వైఫల్యం, మరియు మొదటి ప్రవృత్తి వినియోగదారు పాస్వర్డ్ను రీసెట్ చేయడం. ఆ ప్రవృత్తి దాదాపు ఎల్లప్పుడూ తప్పు. ఈ సందేశాలు క్రెడెన్షియల్ తనిఖీ కాదు, డేటా మార్గాన్ని వివరిస్తాయి: క్లయింట్ విజయవంతంగా ప్రామాణీకరించబడి తర్వాత నెట్వర్క్లో నమోదు చేసుకునే దశలో నిలిచిపోయి ఉండవచ్చు. రెండు వేర్వేరు సందేశాలు రెండు వేర్వేరు వైఫల్యాలను సూచిస్తాయి, ఏదీ కొత్త పాస్వర్డ్తో పరిష్కారం కాదు.

రెండు సందేశాలు, రెండు వేర్వేరు వైఫల్యాలు

చదవడంలో వైఫల్యం అంటే GRE ప్యాకెట్లు డీమన్కు ఎప్పుడూ చేరవు, లేదా లోపలికి వచ్చేటప్పుడు విసిరివేయబడతాయి. నియంత్రణ కనెక్షన్ పూర్తిగా ఆరోగ్యంగా కనిపించవచ్చు, కానీ డేటా మార్గం ద్వారా ఏమీ దాటదు. ప్రామాణీకరణ మాత్రమే స్పష్టంగా పని చేసింది.

రాయడంలో వైఫల్యం సాధారణంగా సెషన్ కెర్నల్ లేదా క్లయింట్ ఉపయోగించలేని ఏదో చర్చించిందని అర్థం. నియంత్రణ ఛానెల్ పూర్తైంది, మరియు ఆ మార్పిడిలో అంగీకరించిన ఎంపికలు చివరి బిందువులు నిజంగా చేయగలిగే దానితో సరిపోలవు. ఇది కాన్ఫిగరేషన్ అసమ్మతి, ప్రామాణీకరణ సంఘటన కాదు.

ఏదైనా మార్చే ముందు రెండింటిలో ఏది కనిపిస్తుందో చదవండి. అవి మిమ్మల్ని వేర్వేరు పొరలకు పంపుతాయి, వాటిని ఒకే లక్షణంగా చూడటమే ఒకే సర్వర్ సంబంధం లేని కారణాలతో రెండుసార్లు ప్యాచ్ అవ్వడానికి కారణం. లాగ్ లైన్ మాత్రమే మీకు లభించే ఏకైక ఉచిత నిర్ధారణ.

ప్రోటోకాల్ 47 పోర్ట్ 47 కాదు

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

మార్గంలోని రౌటర్కు PPTP passthrough లక్షణం లేదా స్పష్టమైన GRE అనుమతి అవసరం. అది లేకుండా TCP హ్యాండ్షేక్ పూర్తవుతుంది మరియు టన్నెల్ ఎప్పుడూ ప్యాకెట్ మోయదు, ఇది పైన చెప్పిన చదవడంలో వైఫల్యాన్నే సృష్టిస్తుంది. ఫైర్వాల్లో పోర్ట్ 47 నియమాలు ఈ ప్రోటోకాల్లో అత్యధికంగా వృథా అయిన మధ్యాహ్నం.

ఏ వైపు ట్రాఫిక్ను విసిరివేస్తుందో ఊహించడం బదులు సర్వర్పై రెండు దిశలను ఒకేసారి గమనించండి: tcpdump -ni any port 1723 or proto gre.

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

హోస్ట్ నిజంగా ఫార్వర్డ్ చేసే చోట GRE ను అనుమతించండి

GRE కోసం forward నియమాన్ని చేర్చడం టన్నెల్ ట్రాఫిక్ను ఫార్వర్డ్ చేసే హోస్ట్పై సమంజసమైన పరీక్ష, అది విధానం కాదు. ఒక ప్రోటోకాల్ యొక్క సమస్తాన్ని అంగీకరించే పరీక్షా నియమం నిర్ధారణ, రూపకల్పన కాదు. ఏదో నేర్చుకోవడానికి సరిపడా ఉంచి, తర్వాత పరిమిత నియమంతో భర్తీ చేయండి.

సర్వర్కు నేరుగా పంపిన ప్యాకెట్లకు input నియమాన్ని జోడించండి, ఎందుకంటే forward గొలుసు వాటిని చూడదు. తర్వాత కనెక్షన్ ప్రయత్నానికి ముందు మరియు తర్వాత నియమం కౌంటర్లను చూడండి, అది ప్యాకెట్లు వస్తున్నాయా అని చెబుతుంది.

ప్రతి రీబూట్ తర్వాత మళ్లీ అమలు చేయడం బదులు పంపిణీ ఫైర్వాల్ సేవ ద్వారా నియమాన్ని శాశ్వతం చేయండి. nftables హోస్ట్పై input మరియు forward రెండు గొలుసుల్లో ip protocol gre సరిపోల్చండి.

ppp_generic మాడ్యూల్ కూడా లోడ్ అయిందని నిర్ధారించండి, మరియు కనెక్షన్ ట్రాకింగ్ తిరిగి వచ్చే దిశను విసిరివేస్తుందా పరిశీలించండి. రెండూ ఫైర్వాల్ సమస్యలా కనిపించే కానీ కాని వైఫల్యాలను సృష్టిస్తాయి. లేని కెర్నల్ మాడ్యూల్ తనిఖీ చేసే వరకు సరిగ్గా నిరోధించిన ప్రోటోకాల్లా కనిపిస్తుంది.

మీ వద్ద నిజంగా ఉన్న క్లయింట్కు ఎంపికలను సరిపోల్చండి

మరొక నివేదిక సవరణ /etc/ppp/pptpd-options లో ఉంది, అక్కడ రెసిపీ PAP, CHAP మరియు MSCHAP ను తిరస్కరిస్తుంది, సంబంధిత require పంక్తులను వ్యాఖ్యానిస్తుంది మరియు స్థితి MPPE ను ఉంచుతుంది. ఆ రెసిపీ ఒక క్లయింట్ మిశ్రమం కోసం రాయబడింది, కళ్లు మూసుకుని కాపీ చేయడం సాధారణ సందర్భాన్ని బద్దలు కొడుతుంది. తిరస్కరణ పంక్తులను సిఫారసుగా కాదు, రచయితకు ఏ క్లయింట్లు ఉన్నాయనే ప్రకటనగా చదవండి.

Windows క్లయింట్కు సాధారణంగా MS-CHAPv2 తో MPPE-128 అవసరం. ఆ అవసరాలను ఉంచి, క్లయింట్ నిజంగా చర్చించలేని ఎంపికలను మాత్రమే తొలగించండి.

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

కనెక్షన్ విజయవంతం కావడానికి ఎన్క్రిప్షన్ ఆఫ్ చేయడం క్షీణత, మరమ్మతు కాదు. అలాంటి రూపాంతరాన్ని ల్యాబ్ లింక్పై పరీక్షించి, సేవ నిజమైన క్లయింట్లను ఎదుర్కొనే ముందు ఎన్క్రిప్షన్ను పునరుద్ధరించండి. అసురక్షితంగా పని చేసే కనెక్షన్ నిజాయితీగా విఫలమయ్యే దానికంటే అధ్వాన్నం.

క్లయింట్ లోపం సంఖ్యను చదవండి

క్లయింట్ సంఖ్యా కోడ్ సర్వర్ లాగ్ కంటే వేగంగా దశను సంకోచిస్తుంది. మరేదైనా చదవక ముందు దాన్ని చదవండి. 691 అంటే క్రెడెన్షియల్స్ తిరస్కరించబడ్డాయి, 721 అంటే సర్వర్ ఎప్పుడూ సమాధానం ఇవ్వలేదు, మరియు 619 అంటే కనెక్షన్ తెగిపోయింది. సంఖ్యతో రెండు నిమిషాలు కాన్ఫిగరేషన్తో ఒక గంటను ఆదా చేస్తాయి.

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

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

సంబంధిత వ్యాసాలు