OpenVPN 3 Linux: వెనక్కి వెళ్లే ముందు D-Bus లోపాన్ని చదవండి
ఐదు సేవలు, ఒక ఫ్రంటెండ్. D-Bus లోపాన్ని నిరాకరించిన భాగానికి ఆపాదించండి, సెషన్ ఉందో లేదో చూడండి, ఆపై ఆ సరిహద్దులో సరిచేయండి.
OpenVPN 3 Linux వైఫల్యాలు తెలియని పేరుతో D-Bus పద్ధతి లోపంగా వస్తాయి, మరియు ప్యాకేజీని పాత సంస్కరణకు దించి ఆశించడం ప్రలోభం. క్లయింట్ ఒక ప్రోగ్రామ్ కాదు: కమాండ్ లైన్ ఫ్రంటెండ్ బస్ ద్వారా ప్రొఫైల్స్, సెషన్లు, VPN ఇంజిన్ మరియు ప్రత్యేక అనుమతి గల నెట్వర్క్ మార్పులను కలిగి ఉన్న సేవలతో మాట్లాడుతుంది. ఈ ఐదింటిలో ఏది విఫలమైన కాల్ కలిగి ఉందో నిర్ణయించడమే నిర్ధారణలో పెద్ద భాగం, అది వెనక్కి వెళ్లడం కంటే ఒక కమాండ్ ఖర్చు. తర్వాత అదే నిర్ణయం, వైఫల్యాలు సాధారణంగా కనిపించే క్రమంలో.
ఒక కమాండ్ వెనుక ఐదుగురు యజమానులు
ఐదు ప్రక్రియలు ముఖ్యం, ప్రతిదానికి దాని సొంత బస్ పేరు ఉంది: మీ కమాండ్ను స్వీకరించే ఫ్రంటెండ్, ప్రొఫైల్స్ మరియు వాటి యాక్సెస్ విధానాన్ని నిల్వ చేసే కాన్ఫిగరేషన్ మేనేజర్, సెషన్ ఆయుష్షును కలిగి ఉన్న సెషన్ మేనేజర్, OpenVPN 3 Core Engine ద్వారా కనెక్షన్ను నడిపే బ్యాకెండ్, మరియు ఇంటర్ఫేస్, మార్గాలు, DNS సెట్టింగ్లను ఇన్స్టాల్ చేసే నెట్వర్క్ కాన్ఫిగరేషన్ సేవ. కాబట్టి కాన్ఫిగరేషన్ ఆబ్జెక్టును పేర్కొనే లోపం బ్యాకెండ్ లోపం కాదు, ప్రారంభం కాని బ్యాకెండ్ ప్రామాణీకరణ వైఫల్యం కాదు. సందేశాన్ని ఆ వరుసల్లో ఒకదానిలో చేర్చడం ఏదైనా మార్చే ముందు జరగాలి, ఎందుకంటే ప్రతి తదుపరి అడుగు ఏ వరుస నిజమో దానిపై ఆధారపడి ఉంటుంది. వరుసను ఊహించడమే చిన్న సవరణ ప్యాకేజీలతో పూర్తి మధ్యాహ్నం పనిగా మారే మార్గం.
మరేదైనా అడిగే ముందు సిస్టమ్ బస్ను ఏ సేవలు ఉన్నాయని అడగండి, తర్వాత ఇన్స్టాల్ చేసిన భాగాలు ఒక సంస్కరణపై ఏకీభవిస్తున్నాయని నిర్ధారించండి. OpenVPN 3 Linux ఆ సేవలను సిస్టమ్ యూనిట్లుగా నమోదు చేస్తుంది, కాబట్టి అడగాల్సిన బస్ సిస్టమ్ బస్, సంస్కరణ ప్రశ్నకు పరిపాలన అధికారం కావాలి, మరియు --user తో తయారు చేసిన జాబితా మీ లాగిన్ సెషన్ను చదువుతుంది, అక్కడ యూనిట్లు ఎప్పుడూ కనిపించవు. సేవలు అభ్యర్థనపై సక్రియమవుతాయి, కొన్ని నిష్క్రియంగా ఉన్నప్పుడు నిష్క్రమిస్తాయి, కాబట్టి మీ మొదటి అభ్యర్థనకు ముందు లేని సేవను ఇంకా ఏదీ అడగలేదు. క్రింది మూడు కమాండ్లు VPN సెషన్ తెరవకుండా ఉనికి, సంస్కరణ మరియు యూనిట్ స్థితిని సమాధానం చెబుతాయి.
sudo busctl list | grep -i openvpn
sudo openvpn3-admin version --services
systemctl list-units 'openvpn3*'ప్రతి జాబితా నిజంగా ఏమి రుజువు చేస్తుంది
క్లయింట్ యొక్క సొంత దృశ్యాలే అందుబాటులో ఉన్న చవకైన రుజువు, వాటిలో ప్రతిదీ కనిపించేదానికంటే తక్కువే రుజువు చేస్తుంది. కాన్ఫిగరేషన్ జాబితాలోని ప్రొఫైల్ ఒక ప్రొఫైల్ దిగుమతి అయిందని చూపిస్తుంది, ఎవరైనా దానితో కనెక్ట్ కాగలరా అనే దాని గురించి ఏమీ చెప్పదు. సెషన్ జాబితాలోని సెషన్ సెషన్ ఆబ్జెక్టు ఉందని చూపిస్తుంది, దూర ప్రామాణీకరణ పూర్తయిందా అనే దాని గురించి ఏమీ చెప్పదు.
openvpn3 configs-list
openvpn3 sessions-listఆ అవుట్పుట్లలోని ఆబ్జెక్టు మార్గాలు బస్పై నిర్వహించబడే ఆబ్జెక్టులను సూచిస్తాయి, ఫైళ్లను కాదు, కాబట్టి వాటిని సవరించలేము, మరియు ముందు నమోదు చేసిన మార్గం ఆ సెషన్ డిస్కనెక్ట్ అయ్యే క్షణంలో పాతదవుతుంది. మీ నోట్స్లోని ఒకదాన్ని మళ్లీ ఉపయోగించడం VPN తో ఎలాంటి సంబంధం లేని "no such object" లోపాలను సృష్టిస్తుంది. క్రింది దశల పట్టిక కనెక్షన్ యొక్క ప్రతి అడుగు ఏమి స్థాపిస్తుంది, ఏమి తెరిచి ఉంచుతుంది అనేది వేరు చేస్తుంది, మరియు వెనక్కి వెళ్లే నిర్ణయం సరిగ్గా ఆ భేదంపైనే నిలుస్తుంది. మీ రుజువుకు సరిపోయే వరుసను చదవండి, తర్వాత లోపం పాఠ్యాన్ని మళ్లీ చదవండి.
| Stage | What exists | What proves it | What it does not prove |
|---|---|---|---|
| Profile imported | A configuration object held by the configuration manager | The profile is listed by the client | That the profile owner permits a connection |
| Session requested | A session object held by the session manager | The session appears in the session list | That the remote side accepted the credentials |
| Connect dispatched | An asynchronous attempt on the VPN backend | Status changes arrive for that session | That an interface was configured |
| Tunnel configured | An interface, routes and DNS settings | The network service reports success and routes appear | That traffic reaches the peer |
కనెక్షన్ కాల్ సొరంగం ఉనికిలోకి రాకముందే తిరిగి వస్తుంది
కనెక్షన్ కాల్ మీకు పర్యవేక్షించడానికి సెషన్ ఇచ్చి తిరిగి వస్తుంది, అందుకే బాహ్యంగా విజయవంతమైన కాల్ తర్వాత నిశ్శబ్దం రావడం సాధారణ మధ్యస్థ స్థితి, వైరుధ్యం కాదు. ఫ్రంటెండ్ ఇంకా స్థితి మార్పులను అనుసరించి ప్రతి పరస్పర చర్య అభ్యర్థనకు సమాధానం చెప్పాలి. ఆధారం అవసరమై సమాధానం రాని ప్రొఫైల్ ఇరుక్కుపోయిన బ్యాకెండ్ లాగా కనిపించే స్థితిలో నిరీక్షిస్తుంది. ఆ నిరీక్షణ స్థితిని గుర్తించాలి, ఎందుకంటే అది ప్రజలను తప్పు భాగానికి పంపుతుంది.
ఒక ప్రయత్నం జరుగుతున్నప్పుడు, ఆ ప్రొఫైల్ కోసం సెషన్ జాబితాను మరియు ఫ్రంటెండ్ సొంత లాగ్ను గమనించండి. తన ప్రారంభ స్థితిని ఎప్పటికీ విడిచిపెట్టని సెషన్ ఆగిన భాగాన్ని పేర్కొంటుంది, లాగ్ సాధారణంగా మొదటి పంక్తుల్లోనే దాన్ని పేర్కొంటుంది. ప్రొఫైల్ పేరును చేతిలో ఉంచుకోండి, ఎందుకంటే లాగ్ కమాండ్ సెషన్ మార్గాన్ని కాదు, ప్రొఫైల్ను తీసుకుంటుంది, ఇది మార్గాన్ని మళ్లీ ఉపయోగించడం కంటే జాబితాను మళ్లీ చదవడానికి మరో కారణం.
openvpn3 sessions-list
openvpn3 log --config <profile> --level 6సెషన్ తెరవకుండా ఒక భాగం యొక్క లాగ్ను చదవడం
ఫ్రంటెండ్ ఉపయోగకరమైనది ఏమీ నివేదించనప్పుడు, కొత్త కనెక్షన్ ప్రారంభించడం కంటే వైఫల్యాన్ని లాగ్ చేసిన భాగం వద్దకు వెళ్లండి. కాన్ఫిగర్ చేసిన systemd-journald లాగర్తో, నిర్వాహకుడి పరిమిత జర్నల్ వీక్షణ ఒక భాగం యొక్క సంఘటనలను చదుతుంది, బస్ విధానాన్ని తాకకుండా సెషన్ తెరవకుండా, ఇది ముఖ్యం ఎందుకంటే కొలవబడుతున్న వ్యవస్థను మార్చే నిర్ధారణ చాలా తక్కువే రుజువు చేస్తుంది. యూనిట్ ఆధారంగా ఫిల్టర్ చేయండి, syslog ట్యాగ్ ఆధారంగా కాదు: వ్యక్తిగత సేవా యూనిట్లు ఉమ్మడి గుర్తింపుకు హామీ ఇవ్వవు, కాబట్టి ట్యాగ్ ప్రశ్న ఖాళీ పేజీని తిరిగి ఇవ్వవచ్చు, అయితే యూనిట్ స్వయంగా వైఫల్యాన్ని నమోదు చేసి ఉండవచ్చు.
ఎవరినైనా సహాయం అడిగే ముందు నాలుగు ఫీల్డ్లను నమోదు చేయండి: లోపం పూర్తి పేరు, సంబంధిత సేవ మరియు ఆబ్జెక్టు, సమయ ముద్ర, ఇన్స్టాల్ చేసిన ప్యాకేజీల సంస్కరణలు. ఇవే నిర్వాహకుడికి కావాల్సినవి, వీటిలో దేనికీ ప్రొఫైల్ లేదా ఆధారాన్ని టికెట్లో అతికించాల్సిన అవసరం లేదు. లోపాన్ని సద్దుమణగడానికి బస్ యాక్సెస్ విధానాన్ని విస్తరించడం నిర్ధారణ కాదు, అది మీ తరఫున భాగాన్ని పేర్కొన్న సరిహద్దును తుడిచివేస్తుంది. ప్రొఫైల్స్ యొక్క ప్రైవేటు కంటెంట్ పంచుకున్న నివేదికలకు వెలుపల ఉంటుంది, ఆధారాలు వెలుపల ఉండటానికి అదే కారణంతో.
journalctl -u 'openvpn3-service-*' -n 50 --no-pager
openvpn3-admin journal --service <name>నిరాకరించిన సరిహద్దును సరిచేయడం
మ్యాప్ యొక్క ప్రతి వరుసకు దాని సొంత సవరణ ఉంది, వరుసలు ఒకదానినొకటి భర్తీ చేయవు. ప్రొఫైల్పై తిరస్కరించిన చర్య విధానం మరియు యాజమాన్యం గురించిన ప్రశ్న, అదే సమయంలో సక్రియం కాని బ్యాకెండ్ సేవలు మరియు ప్యాకేజింగ్ గురించిన ప్రశ్న. ప్రామాణీకరణను తిరస్కరించే సర్వర్ రెండూ కాదు, కాబట్టి పదేపదే పాస్వర్డ్ మార్చడం స్థానిక సక్రియీకరణ సమస్యను సరిచేయలేదు. తప్పు సవరణను ఎంచుకోవడమే విధాన సమస్య పునఃస్థాపనగా మారే మార్గం.
ప్యాకేజీ మార్పు తర్వాత పాత బైనరీని దాని స్థానంలో కాపీ చేయడం కంటే సుసంగతమైన, మద్దతు ఉన్న ఇన్స్టాలేషన్ను ధృవీకరించండి. నియంత్రిత వెనక్కి వెళ్లడం ధృవీకరించబడిన రిగ్రెషన్కు చెల్లుబాటు అయిన సమాధానం, ప్యాకేజీలు సుసంగతంగా ఉండి మద్దతు ఉన్న నిర్వహణకు తిరిగే మార్గం ఉంటే. ఆ మార్గాన్ని సేవ ప్రారంభం కావడం ఆగకముందే ఏర్పాటు చేయండి, తర్వాత కాదు.
మరో వేదిక అదే ప్రధాన VPN లైబ్రరీని Linux యొక్క బస్ సేవలను పంచుకోకుండా పంచుకోవచ్చు, కాబట్టి Windows లో ఇలాంటి వైఫల్యం దీని గురించి ఏమీ చెప్పదు. D-Bus అవలోకనం కాన్ఫిగరేషన్లు మరియు సెషన్ల కోసం బహిర్గతం చేసిన ఆబ్జెక్టు మార్గాలను నమోదు చేస్తుంది, ఈ నిర్ధారణ నిలిచే నిర్మాణ భాగం అదే. ఒకసారి చదవండి, తదుపరి లోపం ఇప్పటికే దానితో జోడించిన భాగంతో వస్తుంది.