ప్రొఫైల్ను తాకే ముందు OpenVPN ప్రక్రియలను లెక్కించండి. రోమింగ్ వినియోగదారులను అంగీకరిస్తూనే అప్స్ట్రీమ్ సేవకు కూడా కాల్ చేసే Pi రెండు డీమన్లను నడుపుతుంది, అందులో ప్రతి ఒక్కటి మీరు టైప్ చేసిన ఇన్స్టాన్స్ పేరుతో ఎంచుకున్న కాన్ఫిగ్ ఫైల్ను చదువుతుంది. ప్యాకేజీ టెంప్లేట్లు తర్వాత ప్రతి డీమన్కు దాని స్వంత పని డైరెక్టరీ, దాని స్వంత రన్టైమ్ స్థితి ఫైల్ మరియు దాని స్వంత టన్నెల్ పరికరాన్ని ఇస్తాయి. ఈ విభజనను తప్పుగా చేస్తే, నడుస్తున్న ప్రక్రియ ఎప్పుడూ తెరవని ఫైల్లోని సరైన సెట్టింగ్ను మారుస్తూ ఒక సాయంత్రం గడుపుతారు.

ప్రతి ఇన్స్టాన్స్ పేరు తన స్వంత ఫైల్ను ఎంచుకుంటుంది

OpenVPN 2.6తో వచ్చే యూనిట్ ఫైళ్లలో, ప్రారంభ ఆర్గ్యుమెంట్లు @ గుర్తు తర్వాతి టెక్స్ట్తో నింపబడే ఇన్స్టాన్స్ ప్లేస్హోల్డర్ను కలిగి ఉంటాయి. సర్వర్ టెంప్లేట్ సర్వర్ కాన్ఫిగ్ డైరెక్టరీ నుండి నడిచి తన ఆర్గ్యుమెంట్ను అక్కడి %i.conf కు వ్యతిరేకంగా పరిష్కరిస్తుంది, క్లయింట్ టెంప్లేట్ క్లయింట్ డైరెక్టరీ నుండి అదే చేస్తుంది. కాబట్టి [email protected] సర్వర్ డైరెక్టరీలోని admits.conf చదువుతుంది, [email protected] క్లయింట్ డైరెక్టరీలోని uplink.conf చదువుతుంది, ఆ పేర్లలో ఏదీ మరొక డైరెక్టరీలో ఎటువంటి అర్థాన్ని కలిగి ఉండదు.

ప్యాకేజీ అప్స్ట్రీమ్ డిఫాల్ట్లను నిలుపుకుందని ఊహించకుండా యంత్రంలోనే మ్యాపింగ్ను నిర్ధారించండి. పంపిణీ యొక్క drop-in పని డైరెక్టరీని లేదా కాన్ఫిగ్ ఆర్గ్యుమెంట్ను పూర్తిగా భర్తీ చేయగలదు.

systemctl cat [email protected]
systemctl cat [email protected]

ఆ అవుట్పుట్లోని WorkingDirectory పంక్తిని మరియు కాన్ఫిగ్ ఆర్గ్యుమెంట్ను చదవండి, ఎందుకంటే ఏ ఫైల్ లోడ్ అవుతుందో ఎనేబుల్ చేసిన యూనిట్ మాత్రమే నిర్ణయిస్తుంది. ExecStart కు --config జోడించే drop-in, టెంప్లేట్ మార్గం సరైనదిగా కనిపించినా టెంప్లేట్ను ఓడిస్తుంది. స్థానిక ఓవర్రైడ్ అమలులో ఉందో లేదో తెలుసుకోవాలంటే ఫ్రాగ్మెంట్ మరియు drop-in మార్గాలను అడగండి. రెండు పాత్రలు ఒకే ఫైల్కు పరిష్కరమైతే, ఒకే ప్రక్రియ సర్వర్ మరియు క్లయింట్ రెండూ కావడానికి ప్రయత్నిస్తోంది, ఆ ఫైల్లోని తర్వాతి ఎంపిక నిశ్శబ్దంగా గెలుస్తుంది.

స్థానిక రవాణా మరియు ఫార్వర్డ్ చేసిన పేలోడ్ వేర్వేరు హుక్లను తాకుతాయి

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

FlowHook that sees itWhat to inspect
Roaming user handshakes to the serverLocal input and local outputListener socket, bind address, rule admitting the UDP port
User payload leaving through the upstream tunnelForwardIPv4 forwarding switch, selected route, permission rule, any translation
Pi's own connection to the upstream peerLocal outputUnderlay route to the provider endpoint, not the tunnel route

ఫార్వర్డ్ చైన్ లోపల బయటకు వెళ్లే ఇంటర్ఫేస్తో సరిపోలే నియమం, రౌటింగ్ ఇప్పటికే ఆ ఇంటర్ఫేస్కు కేటాయించిన ప్యాకెట్ను అనుమతించవచ్చు లేదా పడవేయవచ్చు, కానీ అది ఎప్పుడూ ఇంటర్ఫేస్ను ఎంచుకోదు. ఒక హోస్ట్ ఒక టన్నెల్ను ముగించి మరొకటి ప్రారంభించినప్పుడు, వినియోగదారుల పేలోడ్ను అప్స్ట్రీమ్ టన్నెల్కు పంపే విధానం మరియు Pi యొక్క స్వంత గూఢలిపి ప్రతిస్పందనలను రక్షించే విధానం రెండు వేర్వేరు నిర్ణయాలు. అవి యాదృచ్ఛికంగా ఒకే భౌతిక NICపై పడతాయి, అందుకే గందరగోళానికి గురవుతాయి.

ఆ భేదం సాధారణ సగం-వైఫల్యాన్ని వివరిస్తుంది. వినియోగదారులు కనెక్ట్ అవుతారు, handshake పూర్తవుతుంది, అయినా వారి ట్రాఫిక్ తప్పు మార్గంలో బయటకు వెళ్తుంది, ఎందుకంటే handshake స్థానికం, పేలోడ్ forward మరియు రెండింటిలో ఒకటి మాత్రమే పరీక్షించబడింది.

దిగుమతి చేసిన మార్గం మీ వినియోగదారులకు వెళ్లే ప్రతిస్పందనలను మింగవచ్చు

క్లయింట్ ప్రొఫైల్ యొక్క భద్రతా సెట్టింగ్ అప్స్ట్రీమ్ Pi యొక్క రౌటింగ్ పట్టికలో ఏమి push చేయగలదో నిర్ణయిస్తుంది, విస్తృత రీడైరెక్ట్ అనేది పనిచేస్తున్న ద్వంద్వ-పాత్ర హోస్ట్ను పాడైనదిగా మార్చే ఎంపిక. push చేసిన మార్గం రోమింగ్ వినియోగదారుల పబ్లిక్ చిరునామాలను కవర్ చేస్తే, సర్వర్ వారి వైపు ఉత్పత్తి చేసే ప్రతిస్పందనలు underlay ద్వారా బయటకు వెళ్లకుండా కొత్త మార్గాన్ని అనుసరించి అప్స్ట్రీమ్ టన్నెల్లోకి ప్రవేశించవచ్చు. ప్రొవైడర్కు ఉన్న టన్నెల్ ఇంకా పనిచేస్తోందని నిర్ధారించి అక్కడే ఆగుతారు, ఎందుకంటే ఆ ట్రాఫిక్ టన్నెల్ యొక్క స్వంత రవాణా మరియు మిగతావన్నీ తప్పుగా ప్రవర్తిస్తున్నప్పుడు కూడా అది ప్రవహిస్తూనే ఉంటుంది.

మూలం లేదా mark ఆధారిత విధానమే రెండు ప్రవాహాలను వేరుగా ఉంచే మార్గం. OpenVPN యొక్క Linux mark ఎంపిక డీమన్ యొక్క స్వంత గూఢలిపి ప్యాకెట్లకు ఫైర్వాల్ mark వేస్తుంది, దాన్ని తర్వాత రౌటింగ్ నియమం ప్రత్యేక పట్టికకు పంపగలదు. సర్వర్ యొక్క బయటి ప్రతిస్పందనలు ఎల్లప్పుడూ ఒకే underlay చిరునామా నుండి బయటకు వెళ్తే మూల చిరునామాలు కూడా అంతే బాగా పనిచేస్తాయి. రెండు విధానాలకూ అది ఎంచుకునే పట్టికలో చెల్లుబాటు అయ్యే మార్గాలు మరియు ప్రొవైడర్ endpoint కోసం మినహాయింపు అవసరం, లేకపోతే టన్నెల్ తానే పైకి రాదు.

ఏ నియమాన్నైనా రాసే ముందు ప్రతిస్పందన నిజంగా ఏ మార్గం తీసుకుంటుందో కెర్నల్ను అడగండి. క్రింది చిరునామాలు Pi యొక్క underlay చిరునామా మరియు ఒక రోమింగ్ వినియోగదారు పబ్లిక్ చిరునామా కోసం ప్లేస్హోల్డర్లు.

ip rule show
ip route get 198.51.100.7 from 192.0.2.10

విభజనను నిర్ధారించి, తర్వాత ఒక పాత్రను ఒకసారి ఆపండి

మూడు ప్రవాహాలను విడివిడిగా పరీక్షించండి, ఎందుకంటే విజయవంతమైన handshake మిగతా రెండు గురించి ఏమీ నిరూపించదు. కొత్త ఇన్బౌండ్ కనెక్షన్ను అంగీకరించండి, అనుమతించిన ఒక అప్లికేషన్ను అప్స్ట్రీమ్ నిర్గమనం ద్వారా పంపండి, రెండు ప్రక్రియలు ఇంకా తమ భాగస్వాములను చేరుకుంటున్నాయని నిర్ధారించండి.

తర్వాత క్లయింట్ పాత్రను ఆపి సర్వర్ పాత్ర ఏమి నిలుపుకుంటుందో చూడండి. ఒక ఇన్స్టాన్స్ కోసం ఉద్దేశించి రెండింటికీ వర్తించిన మార్గం లేదా mark నియమాన్ని కనుగొనే అత్యంత చవకైన మార్గం ఇది.

systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pager

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

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