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

యూనిట్ పేరును అది లోడ్ చేసే డైరెక్టరీతో సరిపోల్చండి

Upstream 2.6 రెండు టెంప్లేట్ యూనిట్లను అందిస్తుంది, [email protected] మరియు [email protected]. సర్వర్ టెంప్లేట్ /etc/openvpn/server లో ప్రారంభమై అక్కడి నుండి %i.conf లోడ్ చేస్తుంది. క్లయింట్ టెంప్లేట్ /etc/openvpn/client లో ప్రారంభమవుతుంది. roaming అనే ఇన్స్టాన్స్ ఒకే సమయంలో రెండు ప్రదేశాలలో ఉండవచ్చు, సర్వర్గా మరియు క్లయింట్గా, సంబంధం లేని రెండు కాన్ఫిగరేషన్లతో మరియు స్ట్రింగ్ తప్ప వాటి మధ్య ఎటువంటి లింక్ లేకుండా.

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

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

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

ప్యాకెట్ దిశతో నిర్ణయించండి, ఇంటర్ఫేస్ పేరుతో కాదు

సర్వర్ ఇన్స్టాన్స్కు వినే సాకెట్ ఉంటుంది మరియు అది కనెక్షన్లను అంగీకరిస్తుంది. దాని ఎన్క్రిప్టెడ్ రవాణా Pi-లో స్థానిక ఇన్పుట్ మరియు స్థానిక అవుట్పుట్, అయితే వినియోగదారుల కోసం అది ఫార్వార్డ్ చేసే ట్రాఫిక్ ఫార్వార్డింగ్ మార్గాన్ని అనుసరిస్తుంది మరియు మరొక నియమ సముదాయానికి లోబడుతుంది. క్లయింట్ ఇన్స్టాన్స్కు ఆ అర్థంలో వినేవాడు లేడు: అది ఒక సహచరుడిని కాల్ చేస్తుంది, కాబట్టి దాని ఎన్క్రిప్టెడ్ రవాణా క్రింది పొర వైపు స్థానిక అవుట్పుట్.

ఆ భేదం ఒక నియమం ఎక్కడ చెందుతుందో చెబుతుంది. ఫార్వార్డింగ్ గొలుసులోని ఇంటర్ఫేస్తో సరిపోలే నియమం రూటింగ్ ఇప్పటికే ఎంచుకున్న ట్రాఫిక్ను మాత్రమే అనుమతిస్తుంది; అది ఎప్పుడూ మార్గాన్ని ఎంచుకోదు. తిరుగుతున్న వినియోగదారు ప్యాకెట్లు తప్పు మార్గం ద్వారా బయటకు వెళ్ళినప్పుడు, పరిశీలించవలసిన గొలుసు forward, output కాదు.

సిద్ధాంతం చేయడానికి ముందు సాకెట్లను చూడండి. udp/1194 కు కట్టుబడిన సర్వర్ వినే సాకెట్ను చూపిస్తుంది. క్లయింట్ ప్రదాత చిరునామాతో అనుబంధాన్ని చూపిస్తుంది మరియు వినేది ఏమీ లేదు.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

ఒక ఇన్స్టాన్స్ డిఫాల్ట్ మార్గం మరొకదాని జవాబులను పట్టుకోవచ్చు

ఎగువ క్లయింట్ నెట్టే redirect-gateway మెషీన్పై మిగతా అన్నింటితో పోటీపడే డిఫాల్ట్ మార్గాన్ని ఇన్స్టాల్ చేస్తుంది, సర్వర్ తిరుగుతున్న వినియోగదారులకు పంపే జవాబులు కూడా సహా. OpenVPN సొరంగం చేరుకోగలిగేలా ఉండటానికి తన సొంత సహచర చిరునామాకు మినహాయింపు ఇస్తుంది, కానీ ఆ మినహాయింపు హోటల్ నెట్వర్క్లో కూర్చున్న ఫోన్ గురించి ఏమీ చెప్పదు.

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

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

ip route get 203.0.113.44
ip rule show

ఒక పాత్రను పునఃప్రారంభించి మరొకటి బతికిందని నిరూపించండి

రెండు పాత్రలు ఒకే క్రింది పొరపై ఆధారపడినప్పుడు క్రమం ముఖ్యం. వినియోగదారు ట్రాఫిక్ ఫార్వార్డ్ చేయడానికి ముందు ఎగువ మార్గం ఉండాల్సి ఉంటే మొదట క్లయింట్ను పునఃప్రారంభించండి, మరియు దాని వినేవాడిని లేదా దాని పూల్ను మాత్రమే మారుస్తుంటే మొదట సర్వర్ను పునఃప్రారంభించండి. ఏ సందర్భంలోనైనా తర్వాత రెండు యూనిట్లను నిర్ధారించండి, ఎందుకంటే విఫలమైన పునఃప్రారంభం మరొక పాత్రను పాత స్థితితో నడుస్తూ ఉండనివ్వగలదు.

మార్పుకు ముందు ఆపే షరతును రాయండి: ఎగువ సొరంగం పోవడం తిరుగుతున్న వినియోగదారులను నిరోధిస్తుందా, లేదా Pi యొక్క సొంత ఎగువ లింక్కు తిరిగి వస్తుందా? DNS మరియు IPv6 కూడా స్పష్టమైన సమాధానం కావాలి, ఎందుకంటే నెట్టబడిన రిజాల్వర్ తాను ఉపయోగకరంగా చేసిన మార్గం కంటే ఎక్కువ కాలం జీవిస్తుంది.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

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

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