కనెక్షన్ తిరస్కరించబడటం సర్టిఫికెట్ సమస్య కాదు: VPN రన్‌బుక్

మీరు CRL ను తిరిగి సృష్టించిన వెంటనే కనెక్షన్ తిరస్కరించబడిందని క్లయింట్ చెబుతుంది, కాబట్టి CRL నిందితుడిగా కనిపిస్తుంది. అలా కాదు. తిరస్కరణ రవాణా పొర యొక్క సమాధానం, సర్టిఫికెట్ ధృవీకరణ తర్వాత, టన్నెల్ హ్యాండ్‌షేక్ లోపల జరుగుతుంది. సమయం సరిపోవడం సందర్భం, రుజువు కాదు.

రెండు తనిఖీలు ఒక నిమిషం కంటే తక్కువ సమయంలో కేసులను వేరు చేస్తాయి, వాటిలో ఏదీ విశ్వాస సెట్టింగ్‌లను తాకదు.

లోపాన్ని సృష్టించిన పొరలోనే చదవండి

connect నుండి ECONNREFUSED అంటే రవాణా ప్రయత్నం తిరస్కరించబడింది: ఏదో reset తో సమాధానం ఇచ్చింది, లేదా స్టాక్ చేరుకోలేని పోర్టును నివేదించింది. సర్టిఫికెట్ సమస్య ఆ లోపాన్ని సృష్టించలేదు, ఎందుకంటే రవాణా కనెక్షన్ లేకుండా TLS హ్యాండ్‌షేక్ ఎప్పుడూ ప్రారంభం కాదు. తిరస్కరణ కనిపిస్తే, క్లయింట్ సర్టిఫికెట్ సమర్పించే దశకే చేరలేదు. ఆ ఒక్క వాస్తవం రద్దును కారణంగా మినహాయిస్తుంది.

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

TCP తిరస్కరణ: ఎవరూ వినడం లేదు

TCP కోసం, ఉద్దేశించిన ఇన్‌స్టాన్స్ నడుస్తోందో మరియు ప్రొఫైల్‌లోని చిరునామా మరియు పోర్టుకు బద్ధమైందో తనిఖీ చేయండి. ss -lntp వినేవారిని చూపిస్తుంది, వాటిలో ఒకటి లేకపోవడమే సాధారణ వివరణ. విస్మరించడం బదులు తిరస్కరించే ఫైర్‌వాల్ క్లయింట్ వైపు అదే సందేశాన్ని సృష్టిస్తుంది, అందుకే రెండింటినీ తనిఖీ చేస్తారు.

చిరునామా కుటుంబాన్ని కూడా తనిఖీ చేయండి. 127.0.0.1 లేదా IPv6 కి మాత్రమే బద్ధమైన సేవ మరొకదానికి పరిష్కరించబడే క్లయింట్‌ను తిరస్కరిస్తుంది.

తర్వాత ఊహించకుండా సేవా లాగ్ చదవండి. CA నిర్వహణ తర్వాత పునఃప్రారంభం చదవలేని లేదా లేని ఫైల్‌లో విఫలమవుతుంది, వినే స్థితికి ఎప్పుడూ చేరకపోవచ్చు, లాగ్ ఫైల్ పేరును చెబుతుంది. అది ప్రారంభ వైఫల్యం, తిరస్కరించిన సర్టిఫికెట్ కంటే భిన్నమైన బగ్.

UDP కి తిరస్కరించడానికి హ్యాండ్‌షేక్ లేదు

UDP పై OpenVPN TCP అర్థంలో కనెక్షన్‌ను ఏర్పాటు చేయదు, కాబట్టి connect సమయంలో తిరస్కరించడానికి ఏమీ లేదు. Linux లో, UDP సాకెట్ చూపించే లోపం మునుపటి డేటాగ్రామ్ సృష్టించిన ICMP port-unreachable నుండి రావచ్చు. udp(7) మాన్ పేజీ ఆ అసమకాలిక ప్రవర్తనను వివరిస్తుంది.

అందుకే UDP క్లయింట్ సర్వర్ ప్రాసెస్ నడుస్తున్నప్పటికీ ఆశించిన చిరునామాకు బద్ధం కాకపోతే తిరస్కరణను ముద్రించగలదు.

CRL నిజంగా ఎక్కడ తనిఖీ చేయబడుతుంది

CRL ను TLS హ్యాండ్‌షేక్ సమయంలో, ఎదుటి పక్షం తన సర్టిఫికెట్‌ను సమర్పించిన తర్వాత, సర్వర్ కాన్ఫిగరేషన్ అనుమతిస్తే మాత్రమే సంప్రదిస్తారు. OpenVPN యొక్క crl-verify ఎంపిక ఫైల్‌ను సూచిస్తుంది, వైఫల్యం సర్వర్ లాగ్‌లో సర్టిఫికెట్‌ను పేర్కొనే ధృవీకరణ లోపంగా కనిపిస్తుంది.

అందువల్ల రద్దు చేసిన క్లయింట్ రవాణా పొరలో కనెక్ట్ అవుతుంది, తర్వాత ప్రామాణీకరణలో విఫలమవుతుంది. అదే సర్వర్, అదే పోర్టు, పూర్తిగా భిన్నమైన సందేశం.

ఆ దశకు చేరినప్పుడు CRL యొక్క జారీచేసినవారు మరియు చెల్లుబాటు తేదీలను తనిఖీ చేయండి. తప్పు CA సంతకం చేసిన CRL, లేదా క్లయింట్ కనెక్ట్ అవ్వకముందే గడువు ముగిసిన CRL, క్లయింట్ స్వంత సర్టిఫికెట్‌తో ఎటువంటి సంబంధం లేని ధృవీకరణ లోపాలను సృష్టిస్తుంది.

తదుపరి సారికి చిన్న రన్‌బుక్

మొదట రవాణాను నిర్ధారించండి: వినేవాడు ఉన్నాడు, సరైన చిరునామా కుటుంబం, ఫైర్‌వాల్ తిరస్కరించడం లేదు. తర్వాత ప్రారంభ లాగ్ చదివి సేవ వినే స్థితికి చేరిందని నిర్ధారించండి. ఆ తర్వాత మాత్రమే ధృవీకరణ సందేశాల కోసం హ్యాండ్‌షేక్ లోపాలను చూడండి. ఈ క్రమాన్ని స్థిరంగా ఉంచండి, ఎందుకంటే ప్రతి అడుగు ఒక పూర్తి కారణ వర్గాన్ని తొలగిస్తుంది.

రవాణా, పరిష్కరించబడిన గమ్యం, పోర్టు మరియు లోపం యొక్క ఖచ్చితమైన పాఠ్యాన్ని రాసుకోండి. క్లయింట్ మళ్లీ ఇన్‌స్టాల్ చేయడం ఆ రుజువును నాశనం చేస్తుంది, సాధారణంగా ఏమీ మారదు.