PPTP passthrough లేదు: Windows VPN లోపం 807 పరిష్కారం

TCP 1723 ను ఫార్వార్డ్ చేయడం తరచుగా PPTP మొదటి భాగాన్ని మాత్రమే శుభ్రం చేసి మిగతాది విరిగినట్లే వదిలేస్తుంది, కాబట్టి ప్రయత్నంలో Windows ఇప్పటికీ లోపం 807 ను తిరిగి ఇస్తుంది. తదుపరి ఆలోచన పోర్ట్ 47 కోసం నియమాన్ని జోడించడం, ఆ అడుగే ఒక మధ్యాహ్నాన్ని వృథా చేస్తుంది: GRE అనేది IP హెడర్‌లోని ప్రోటోకాల్ నంబర్, ఫార్వార్డింగ్ పట్టిక సరిపోల్చగల పోర్ట్ కాదు. రౌటర్ ప్రోటోకాల్ 47 ను దాటించి దానిని అదే కాల్‌తో కలిపే వరకు టన్నెల్ ప్రారంభం కాదు. క్రింది విభాగాలు రెండు ఛానెల్‌లను వేరు చేసి, తర్వాత ఒక్కొక్కటిగా పరీక్షిస్తాయి.

పోర్ట్ పట్టికలో ప్రోటోకాల్ నంబర్‌కు వరుస లేదు

PPTP వేర్వేరు విధాలుగా విఫలమయ్యే రెండు సంభాషణలను ఉపయోగిస్తుంది. TCP 1723 లోనిది కాల్‌ను ప్రారంభించి, లింక్ సమాచారాన్ని పంపి, వినియోగదారు డిస్‌కనెక్ట్ అయినప్పుడు దానిని తీసేస్తుంది. పేలోడ్ భాగం GRE లోపల నడుస్తుంది, దానిని IP హెడర్ ప్రోటోకాల్ నంబర్ 47 గా గుర్తిస్తుంది, ఆ టన్నెల్ లోపల PPP లింక్‌ను చర్చిస్తుంది, MS-CHAPv2 ఆధారాలను తనిఖీ చేస్తుంది.

GRE ఎటువంటి రవాణా హెడర్‌ను మోయనందున పోర్టులను బయటపెట్టదు, కాబట్టి పోర్టుల కోసం రాసిన నియమానికి సరిపోల్చడానికి ఏమీ ఉండదు. 1723 ను ఫార్వార్డ్ చేసే రౌటర్ ఆ TCP సెషన్‌కు మ్యాపింగ్‌ను సృష్టించి అక్కడితో ఆగిపోతుంది. రెండో సగాన్ని నిర్వహించే ఫర్మ్‌వేర్ ఈ ఫీచర్‌ను PPTP passthrough లేదా PPTP ALG అని పిలుస్తుంది, కొన్ని ఫర్మ్‌వేర్ రెండింటినీ ఇవ్వదు మరియు ఈ అంతరాన్ని ఎప్పుడూ ప్రస్తావించదు. చెక్‌బాక్స్‌పై ఉన్న లేబుల్ కంటే ప్రోటోకాల్ 47 అసలు గుర్తించబడుతుందా అనేదే ముఖ్యం.

డేటా మార్గం చనిపోయినప్పుడు Windows ఏమి నివేదిస్తుంది

లోపం 807 కనెక్షన్ పూర్తి కాలేదని చెబుతుంది, ఆచరణలో కాల్ సర్వర్‌ను చేరింది కానీ డేటా ఛానెల్ లేవలేదని అర్థం. ఇది ఖాతా గురించిన తీర్పు కాదు, రవాణా గురించిన తీర్పు. లోపం 691 ఆధారాలను లేదా ప్రామాణికత ప్రోటోకాల్ అసమతుల్యతను సూచిస్తుంది, కాబట్టి మిమ్మల్ని పూర్తిగా వేరే చోటికి పంపుతుంది.

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

రెండో క్లయింట్ పనిచేస్తున్న టన్నెల్‌ను ఎందుకు విరుస్తుంది

వేరు చేయడానికి పోర్టులు లేకపోవడంతో, NAT పరికరం రెండు PPTP క్లయింట్లను రెండు HTTPS సెషన్లను వేరు చేసినట్లు వేరు చేయలేదు. అందువల్ల చాలా వినియోగదారు పరికరాలు ఒక PPTP కాల్‌ను మాత్రమే అనుమతించి మూల చిరునామా ద్వారా ట్రాక్ చేస్తాయి. ఒంటరిగా పనిచేసిన ల్యాప్‌టాప్ రెండో యంత్రం కాల్ చేసినప్పుడు పూర్తి చేయడం ఆపేస్తుంది, క్లయింట్ వైపు నుండి వైఫల్యం యాదృచ్ఛికంగా కనిపిస్తుంది. ఆ నమూనా ఫర్మ్‌వేర్‌కు చెందుతుంది, ఏ ప్రొఫైల్ మార్పు దానిని మార్చదు.

ఇద్దరు క్లయింట్లు కాల్ చేస్తున్నప్పుడు కనెక్షన్ పట్టికను గమనించండి. మొదటి హోస్ట్ మాత్రమే ఎప్పుడూ మ్యాపింగ్ కలిగి ఉంటే, రౌటర్ తనకు మద్దతు ఉన్న పరిమితిని చేరుకుంది, క్లయింట్ వైపు ఏ సెట్టింగ్ దానిని కదిలించదు.

ఏ సగం విఫలమవుతుందో నిరూపించండి

రౌటర్‌పై ఏదైనా మార్చే ముందు TCP 1723 వస్తుందని నిర్ధారించండి, ఎందుకంటే ఆ సమాధానం మీరు పరీక్షిస్తున్న సగాన్ని నిర్ణయిస్తుంది. వీటిని Windows క్లయింట్ నుండి మీ స్వంత సర్వర్ పేరుపై అమలు చేయండి. మొదటిది పోర్ట్ సమాధానం ఇచ్చిందో లేదో ముద్రిస్తుంది, రెండోది సంభాషణ లేకుండా కాల్ చేస్తుంది, ఇది పునరావృత ప్రయత్నాలను పోల్చదగినవిగా చేస్తుంది.

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

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

tcpdump -ni any proto 47

Wireshark సమానమైనది డిస్‌ప్లే ఫిల్టర్ ip proto 47, దీనిని shell లో సౌకర్యం లేని వ్యక్తికి అప్పగించడం సులభం. సమాధానంగా ఏదీ బయటకు పోకుండా GRE వస్తే, తిరుగు మార్గాన్ని సరిచేయాలి.

లోపాన్ని నిజంగా పరిష్కరించేది ఏమిటి

రౌటర్ సెట్టింగ్‌ను బయటపెట్టిన చోట PPTP passthrough ను ప్రారంభించండి, లేదా నియమాలను అంగీకరించే ఫర్మ్‌వేర్‌లో ప్రోటోకాల్ 47 ను స్పష్టంగా అనుమతించండి. RouterOS లో forward నియమం ప్రోటోకాల్‌ను నేరుగా సరిపోలుస్తుంది, పోర్ట్ ఆధారిత ఫార్వార్డింగ్ ఎప్పుడూ అలా చేయలేదు. వినియోగదారు ఫర్మ్‌వేర్ అదే నిర్ణయాన్ని చెక్‌బాక్స్ వెనుక దాచుతుంది, కొన్నిసార్లు పోర్ట్ ఫార్వార్డింగ్ కాకుండా భద్రతా సెట్టింగ్‌ల కింద. అలాంటి నియంత్రణ లేకపోతే, క్లయింట్‌లో ఏదీ భర్తీ చేయదు.

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

PPTP ను భర్తీ చేయడం మరో ఎంపిక, తరచుగా చవకైనది. VPN ను తానే ముగించే రౌటర్ లోపలికి వచ్చే క్లయింట్లకు రెట్టింపు NAT ను నివారిస్తుంది, పోర్ట్ ఆధారిత NAT ఇప్పటికే నిర్వహించే ప్రోటోకాల్‌కు passthrough అసలు అవసరం లేదు: UDP పై OpenVPN, TCP 443 పై SSTP, లేదా ESP ను UDP 4500 లో చుట్టే NAT-T తో L2TP/IPsec. PPTP కూడా MS-CHAPv2 పై ఆధారపడుతుంది, దాని నమోదిత బలహీనతలు లోపం తొలగిన తర్వాత కూడా కొత్త అమరికకు అది చెడు ఎంపికగా చేస్తాయి.

ఏ నియమం తేడా సృష్టించిందో రాయండి, ఎందుకంటే రెండో వినియోగదారు ప్రవేశం కోసం అడిగినప్పుడు అదే సైట్ అదే పరిమితిని ఎదుర్కొంటుంది. ప్రోటోకాల్ స్థాయి పరిష్కారం నెట్‌వర్క్ నోట్స్‌లో ఉండాలి, అక్కడ తదుపరి ఇంజనీర్ చూస్తారు.