OpenVPN ఇంట్లో పనిచేస్తుంది కానీ ఒక నెట్‌వర్క్‌లో పనిచేయదు: UDP లేదా TCP?

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

ఏ దశ విఫలమైంది అనేది ఏ పోలిక ముఖ్యమో చెబుతుంది

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

తరువాత కాదు, పునఃప్రయత్నించే సమయంలో క్యాప్చర్ చేయండి. క్లయింట్‌లో tcpdump -ni any udp port 1194 ఏదైనా ప్రతిస్పందన తిరిగి వస్తుందా అని చూపిస్తుంది. మీరు నియంత్రించే సర్వర్ యొక్క WAN ఇంటర్‌ఫేస్‌లో దాన్ని పునరావృతం చేయండి, ఇది ఆ ప్యాకెట్‌లు దూరపు చివరకు చేరుతాయా అని వెల్లడిస్తుంది.

ఒకవైపు ట్రాఫిక్ ఇక్కడ అందుబాటులో ఉన్న అత్యంత ఉపయోగకరమైన ఫలితం, ఎందుకంటే ఇది అడపాదడపా వచ్చే ఫిర్యాదును విచారణ దిశగా మారుస్తుంది. క్యాప్చర్ ఫైళ్లను ఉంచండి, ఎందుకంటే అదే సమస్య యొక్క తదుపరి నివేదికను వివరణ కంటే సాక్ష్యంతో ముగించడం సులభం.

UDP ఫిల్టరింగ్ మరియు మూసిన పోర్ట్

అనేక యాక్సెస్ నెట్‌వర్క్‌లు నిరంతర UDP ను అనుమానాస్పదంగా భావిస్తాయి, కొన్ని ISP లు కూడా అంగీకరిస్తాయి. మూసిన పోర్ట్ క్లయింట్ వైపు నుండి అదే నిశ్శబ్దాన్ని ఉత్పత్తి చేస్తుంది. తేడా ఎంపికశీలత: ఫిల్టర్ ఏ గమ్యస్థానాలు లేదా పోర్ట్‌లను వదిలివేస్తుందనే విషయంలో ఎంపిక చేస్తుంది, మూసిన పోర్ట్ ఆ పోర్ట్ వైపు మళ్లించిన ప్రతిదాన్ని తిరస్కరిస్తుంది.

పోర్ట్ 443 పై TCP ప్రొఫైల్ సాధారణ పరిష్కారం, ఎందుకంటే ఇది సాధారణ HTTPS ప్రవాహాన్ని పోలి ఉంటుంది మరియు చాలా క్యాప్టివ్ పోర్టల్స్ మరియు ఎగ్రెస్ ఫిల్టర్లను దాటుతుంది. రెండు షరతులు తీరాలి. సర్వర్ proto tcp-server తో వినాలి మరియు క్లయింట్ proto tcp-client తో సరిపోలాలి, మరియు ఆపరేటర్ ఆ ప్రత్యామ్నాయ ఎండ్‌పాయింట్‌ను ప్రచురించాలి. పనిచేస్తున్న UDP ప్రొఫైల్‌ను TCP 443 అని తిరిగి రాయడం అవతల ఎవరూ విననప్పుడు ఏమీ సాధించదు.

మూసిన పోర్ట్ సెన్సార్‌షిప్ సమస్య కాదు, కాన్ఫిగరేషన్ సమస్య. ఇంటి రౌటర్ వెనుక ఉన్న సర్వర్‌కు దాని UDP పోర్ట్ ఫార్వార్డింగ్ అవసరం, మరియు రౌటర్ ఫయర్‌వాల్ దానిని అనుమతించాలి. పోర్ట్‌కు ఎప్పుడూ అనుమతి ఇవ్వకపోతే, ఆధారాలతో సంబంధం లేకుండా ప్రతి క్లయింట్ చర్చలలో విఫలమవుతుంది, మరియు వైఫల్యం నెట్‌వర్క్‌ను కాదు సర్వర్‌ను అనుసరిస్తుంది.

పాత ప్రోటోకాల్‌లు ఈ అక్షంలో బాగా పోల్చబడవు. PPTP కి TCP 1723 ప్లస్ GRE అవసరం, GRE పోర్ట్ కాదు, IP ప్రోటోకాల్ 47, కాబట్టి సాధారణ పోర్ట్ ఫార్వార్డింగ్ దానిని వ్యక్తపరచదు.

స్విచ్ ప్యాకెట్‌లను వదిలేసినప్పుడు

నిర్వహించిన స్విచ్ టన్నెల్‌ను ఉద్దేశపూర్వకంగా వదిలేయగలదు. కొన్ని HPE మరియు Aruba మోడళ్లు తమ అధునాతన భద్రతా విభాగంలో UDP వరద రక్షణ నియంత్రణను అందిస్తాయి, కొన్నిసార్లు Prevent UDP Blat Attack అని లేబుల్ చేయబడుతుంది. ఆ నియంత్రణ సక్రియంగా ఉన్నప్పుడు, స్విచ్ వెనుక ఉన్న సర్వర్ ఏదానికీ సమాధానం ఇవ్వదు మరియు ప్రతి క్లయింట్ అదే విధంగా సమయం ముగుస్తుంది. దాన్ని తీసివేసి నడుస్తున్న కాన్ఫిగరేషన్‌ను సేవ్ చేయడం మొత్తం మరమ్మత్తు, కానీ స్విచ్ నిజంగా మార్గంలో ఉందని నిర్ధారించిన తర్వాత మాత్రమే.

స్విచ్ వదలడాన్ని ప్రదాత నిరోధం నుండి వేరు చేసేది వ్యతిరేక సాక్ష్యం. ISP తో టికెట్ తెరవడానికి ముందు ఇంటర్‌ఫేస్ కౌంటర్లు మరియు వరద రక్షణ లాగ్ చదవండి. DoS లేదా వరద రక్షణ ఉన్న వినియోగదారు రౌటర్లు అదే రూపంలో విఫలమవుతాయి, మరియు చిన్న UDP నిష్క్రియ సమయ పరిమితి ఉన్న ఏ మిడిల్‌బాక్స్ అయినా అలాగే. ఎప్పటికీ పూర్తికాని హ్యాండ్‌షేక్ వదలడాన్ని సూచిస్తుంది, కొన్ని నిమిషాల నిశ్శబ్దం తర్వాత చనిపోయే టన్నెల్ సమయ పరిమితిని సూచిస్తుంది.

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

DNS వైఫల్యం లాగా కనిపించే చిరునామా అతివ్యాప్తి

10.0.0.0/8 లోపల నంబర్ చేయబడిన యాక్సెస్ నెట్‌వర్క్ టన్నెల్ పూల్‌తో అతివ్యాప్తి చెందవచ్చు, మరియు రిజాల్వర్ సాధారణంగా ఆ పూల్ లోపలే నివసిస్తుంది. ల్యాప్‌టాప్ Wi-Fi లో 10.184.178.50 వంటి చిరునామాను /8 మాస్క్‌తో పొందినప్పుడు, ప్రతి 10.x గమ్యస్థానం నిర్వచనం ప్రకారం స్థానికం. 10.4.0.1 కోసం ప్యాకెట్‌లు అప్పుడు LAN కి వెళ్తాయి, టన్నెల్ పైనే ఉంటుంది, మరియు పేరు పరిష్కారం విఫలమవుతుంది.

ip addr అతివ్యాప్తిని ఒక చూపులో బయటపెడుతుంది, ip route get 10.4.0.1 ప్యాకెట్ నిజంగా ఎక్కడ పంపబడుతుందో చూపిస్తుంది. కనిపించే లక్షణం రిజాల్వర్ వైఫల్యం కాబట్టి, ఇది తరచుగా అనేక రౌండ్ల DNS మార్పులను తట్టుకుంటుంది.

పూల్‌ను తిరిగి నంబర్ చేయండి లేదా ఆ యాక్సెస్ నెట్‌వర్క్‌ను పరిధి వెలుపల ఉంచండి. ఏ క్లయింట్ వైపు సెట్టింగ్ అయినా అతివ్యాప్తి నుండి కోలుకోదు.

TCP బ్యాకప్ మరియు మార్గ సవరణ మధ్య ఎంపిక

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

ఫలితాన్ని వినియోగదారు ప్రకారం కాదు, నెట్‌వర్క్ ప్రకారం నమోదు చేయండి. అదే వైఫల్యం యొక్క తదుపరి నివేదిక అప్పుడు సర్టిఫికెట్ సిద్ధాంతం నుండి కాదు, తెలిసిన దశ నుండి ప్రారంభమవుతుంది. ఆ నమోదే, ఎప్పుడైనా అవసరమైతే, శాశ్వత రెండవ listener ను సమర్థిస్తుంది.