DD-WRT లో OpenVPN 2.5 లిజనర్ చనిపోయిందా? అది సృష్టించిన కాన్ఫిగ్ చదవండి

DD-WRT లో చనిపోయిన లిజనర్ అంటే సాధారణంగా daemon తన కాన్ఫిగ్‌ను పార్స్ చేస్తున్నప్పుడే నిష్క్రమించింది అని, firewall నియమం పోర్టును నిరోధించింది అని కాదు. OpenVPN 2.5 పాత కాన్ఫిగ్‌లు ఆధారపడిన అనేక డిఫాల్ట్‌లను కఠినతరం చేసింది, మరియు పాత బిల్డ్‌లో పనిచేసిన సృష్టించిన కాన్ఫిగ్ సాకెట్ తెరవకముందే తిరస్కరించబడవచ్చు. కారణం రౌటర్ స్వంత లాగ్‌లో ఉంది, ఇన్‌పుట్ సృష్టించిన ఫైల్‌లో ఉంది. రెండింటినీ ఈ క్రమంలో చదవడం ఏ ప్యాకెట్ క్యాప్చర్ కంటే వేగవంతం.

daemon అనేది firewall కాదు

ఈ భేదం ముఖ్యం ఎందుకంటే బయటినుంచి రెండు వైఫల్యాలు ఒకేలా కనిపిస్తాయి: క్లయింట్ handshake పంపుతుంది, ఏదీ తిరిగి రాదు. ఒకటి నడవని ప్రక్రియ, మరొకటి నడుస్తూ ఫిల్టర్ చేసే ప్రక్రియ.

ఏదైనా మార్చే ముందు రెండు తనిఖీలతో వాటిని వేరు చేయండి, ఎందుకంటే చనిపోయిన daemon పై firewall సవరణ రెండో చరాన్ని మాత్రమే జోడిస్తుంది.

DD-WRT సృష్టించిన కాన్ఫిగ్ చదవండి

DD-WRT మీరు వెబ్ ఇంటర్‌ఫేస్‌లో టైప్ చేసిన టెక్స్ట్‌ను OpenVPN కు ఇవ్వదు. అది సృష్టించిన కాన్ఫిగ్‌ను /tmp/openvpn/openvpn.conf లో రాసి ఆ ఫైల్‌తో daemon ను ప్రారంభిస్తుంది, కాబట్టి ఇంటర్‌ఫేస్ ఫీల్డ్‌లు మరియు Additional Config లోని ఏ టెక్స్ట్ అయినా OpenVPN చూసే ముందే విలీనమవుతాయి. మీరు సృష్టించిన ఫైల్‌కు బదులు ఫారమ్‌ను డీబగ్ చేస్తే, మీరు ఉద్దేశాన్ని చదువుతున్నారు, నిజమైన ఇన్‌పుట్ కాదు. రీబూట్ /tmp ను తుడిచే ముందు ఆ ఫైల్‌ను శాశ్వత స్థానానికి కాపీ చేయండి.

సృష్టించిన ఫైల్‌ను మీరు ఉద్దేశించిన దానితో పోల్చండి, ముఖ్యంగా ఇంటర్‌ఫేస్ మీరు ఎప్పుడూ ఎంచుకోని ఆదేశాన్ని రాసే చోట. పాత ఎంపికను విడుదల చేసే డ్రాప్‌డౌన్ ఫారమ్‌లో కనిపించదు మరియు daemon కు ప్రాణాంతకం.

సృష్టించిన ఫైల్ ఖాళీగా ఉంటే లేదా లేకుంటే, daemon ప్రారంభం వరకూ చేరలేదు, మరియు సమస్య OpenVPN కంటే పైన ఉంది.

OpenVPN 2.5 ఏమి అంగీకరించడం ఆపింది

OpenVPN 2.5 ncp-ciphers data-ciphers తో భర్తీ చేసింది, మరియు డిఫాల్ట్ కనిష్ఠ TLS వెర్షన్‌ను 1.2 కు పెంచింది. కంప్రెషన్ నిర్వహణను కూడా మార్చింది, కాబట్టి కంప్రెషన్ అందించే సహచరుడు కాన్ఫిగ్ స్పష్టంగా అనుమతించకపోతే తిరస్కరించబడతాడు, మరియు ns-cert-type వంటి పాత ఎంపిక పేర్లను remote-cert-tls కు అనుకూలంగా వాడుకలో లేనివిగా ప్రకటించింది. ఈ మార్పుల్లో ప్రతిదీ ముందు పనిచేసిన కాన్ఫిగ్‌ను పార్సింగ్ లేదా చర్చ వైఫల్యంగా మారుస్తుంది.

వైఫల్య విధానం ఆదేశంపై ఆధారపడి ఉంటుంది. తెలియని లేదా తీసివేసిన ఎంపిక ప్రారంభంలోనే daemon ను ఆపుతుంది, అదే మీ చనిపోయిన లిజనర్. చర్చలో అసమతౌల్యం daemon ను నడవనిస్తుంది మరియు క్లయింట్లను తిరస్కరిస్తుంది, ఇది క్లయింట్ వైపు నుంచి firewall సమస్యలా కనిపిస్తుంది.

లాగ్‌లో మొదటి లోపాన్ని చదవండి, చివరిది కాదు. పార్సింగ్ మొదటి చెడు ఆదేశం వద్ద ఆగుతుంది, దాని తర్వాత అంతా ఆపేసే శబ్దం.

Broadcom కు ప్రత్యేకమైన ముందస్తు షరతులు

Broadcom బిల్డ్‌లలో daemon ఉపయోగించే ముందు టన్నెల్ పరికరం ఉండాలి. tun మాడ్యూల్ లోడ్ అయిందా మరియు /dev/net/tun ఉందా అని తనిఖీ చేయండి, ఎందుకంటే పరికరం లేకపోతే ధృవపత్రాలకు ఎటువంటి సంబంధం లేని ప్రారంభ వైఫల్యం ఏర్పడుతుంది. DD-WRT మార్గాలు మరియు DNS కోసం సృష్టించే సహాయక స్క్రిప్ట్‌లకూ ఇదే వర్తిస్తుంది: అవి లేకపోతే లేదా అమలు చేయలేకపోతే, daemon ప్రారంభమైనా తన సెటప్ పూర్తి చేయలేదు.

నిజమైన సందేశం అవసరమైనప్పుడు సృష్టించిన కాన్ఫిగ్‌పై ఎక్కువ వివరాలతో daemon ను ముందు తెరపై నడపండి. ముందు తెర నడక init స్క్రిప్ట్ మింగిన పార్సింగ్ లోపాన్ని ముద్రిస్తుంది.

తర్వాత సాధారణ సేవను పునరుద్ధరించండి, ఎందుకంటే ముందు తెర daemon మరియు init స్క్రిప్ట్ పోర్టు కోసం పోటీపడతాయి.

క్లయింట్లను డీబగ్ చేసే ముందు లిజనర్ ఉనికిని నిరూపించండి

ప్రక్రియ మరియు సాకెట్‌ను విడివిడిగా నిర్ధారించండి: ఒకటి నడుస్తున్న daemon కు, మరొకటి ఆశించిన చిరునామాలో బంధించిన UDP పోర్టుకు. సాకెట్ లేని ప్రక్రియ అంటే అది ఇంకా సెటప్‌లో ఉంది లేదా తప్పు ఇంటర్‌ఫేస్‌కు బంధించబడింది. ఈ జంట ఉపయోగకరమైన పరీక్ష ఎందుకంటే ఒక సగం మరొకటి లేకుండా నిజం కాలేదు.

క్లయింట్ వైపు డీబగ్గింగ్ లిజనర్ ఉన్న తర్వాతే అర్థవంతం. అప్పుడు క్లయింట్ cipher మరియు TLS సెట్టింగ్‌లు సర్వర్ data-ciphers జాబితా మరియు కనిష్ఠ వెర్షన్‌తో సరిపోతాయా, పోర్టు నిజంగా రౌటర్‌కు ఫార్వార్డ్ అవుతోందా అని తనిఖీ చేయండి.

సృష్టించిన కాన్ఫిగ్‌ను మరియు సరిదిద్దుడును నిరూపించిన లాగ్ పంక్తిని ఉంచండి. తదుపరి ఫర్మ్‌వేర్ నవీకరణ డిఫాల్ట్‌లను మళ్లీ మార్చవచ్చు, ఆ నమోదే పునరావృత్తిని ఐదు నిమిషాల తనిఖీగా మారుస్తుంది.