పర్యవేక్షణ లేని VPN సర్వర్ అప్డేట్లకు పరీక్షించిన పునరుద్ధరణ మార్గం అవసరం
ఒక అప్డేట్ సర్వర్ను చేరుకోవడానికి మీరు ఉపయోగించే అదే సేవను పునఃప్రారంభించవచ్చు. ఆటోమేట్ చేయడానికి ముందు బ్యాండ్ వెలుపలి కన్సోల్ను టన్నెల్ మాత్రమే ఆధారిత పునరుద్ధరణ ప్రణాళికతో పోల్చండి.
మీరు దాని స్వంత VPN ద్వారా చేరుకునే సర్వర్కు పర్యవేక్షణ లేని అప్డేట్లు సహేతుకమైన విధానం, అదే సమయంలో అవి మీరే సృష్టించుకునే ఒకే వైఫల్య బిందువు. ప్యాకేజీ చర్య సేవను పునఃప్రారంభిస్తుంది, టన్నెల్ పడిపోతుంది, మీరు ఉపయోగించిన పరిపాలనా మార్గం దానితో పాటు మాయమవుతుంది. పునరుద్ధరణకు రెండు నమూనాలు ఉన్నాయి, వాటి మధ్య ఎంపిక ఒక షరతుపై ఆధారపడి ఉంటుంది: మీ వద్ద అప్డేట్ అవుతున్న విషయం గుండా వెళ్లని ప్రవేశ మార్గం ఉందా.
రెండు పునరుద్ధరణ నమూనాలు, ఒక నిర్ణాయక షరతు
మొదటి నమూనా అప్డేట్ను నమ్ముతుంది మరియు తర్వాత మీరు మళ్లీ కనెక్ట్ కాగలరని ఊహిస్తుంది. VPN హోస్ట్ను చేరుకోవడానికి అనేక మార్గాలలో ఒకటిగా ఉన్నప్పుడు మరియు టన్నెల్ వైఫల్యం దాన్ని నిర్ధారించే మీ సామర్థ్యాన్ని తీసివేయనప్పుడు ఇది పనిచేస్తుంది. రెండవ నమూనా ముందుగానే ఒక స్వతంత్ర మార్గాన్ని, సాధారణంగా హోస్టింగ్ ప్రదాత కన్సోల్ను ఉంచుతుంది, మరియు నిర్వహణ ఎక్కువగా విరగగొట్టే వస్తువుగా టన్నెల్ను పరిగణిస్తుంది. రెండు నమూనాలు సమర్థనీయం, వాటిలో ఒకటి మాత్రమే ముందస్తు పని అవసరం.
నిర్ణాయక షరతు చెప్పడం సులభం, దాటవేయడం కూడా సులభం. యంత్రానికి వెళ్లే ప్రతి పరిపాలనా మార్గం అప్డేట్ అవుతున్న సేవ గుండా వెళితే, మీకు పునరుద్ధరణ నమూనా అసలు లేదు, ఒక ఆశ మాత్రమే ఉంది. మార్పు సమీక్షలో దాన్ని బిగ్గరగా చెప్పండి.
ఆ షరతును పరీక్షించడానికి పది నిమిషాలు పడుతుంది మరియు అది మొదటి పర్యవేక్షణ లేని అప్డేట్కు ముందు జరగాలి, సంఘటన సమయంలో కాదు. అన్నీ పనిచేస్తున్నప్పుడు కన్సోల్ తెరవండి, ఆధారాలు చెల్లుబాటులో ఉన్నాయని నిర్ధారించి, మళ్లీ మూసివేయండి. కన్సోల్ మీరు అనుకునే హోస్ట్పై తెరుచుకుంటుందని నిర్ధారించండి. తర్వాత రాత్రి 3 గంటలకు మీరు నిజంగా ఉపయోగించే లాగిన్ ఇంకా పనిచేస్తుందని నిర్ధారించండి.
ఆ చివరి భాగం వినిపించే దానికంటే ముఖ్యం. ఆరు నెలల క్రితం పాస్వర్డ్ మార్చి ఎప్పుడూ ధృవీకరించని కన్సోల్ ఖాతా పునరుద్ధరణ మార్గం కాదు; అది అలాంటి మార్గాన్ని వివరించే పత్రం.
బ్యాకప్ ఏమి పునరుద్ధరించదు
కాన్ఫిగరేషన్ ఆర్కైవ్ ఫైళ్ల రికార్డు, అప్డేట్ ఫైళ్ల కంటే ఎక్కువ మారుస్తుంది. ప్యాకేజీ స్థితి, కెర్నల్ మాడ్యూల్స్, ప్రారంభించిన యూనిట్ లింక్లు మరియు వేరే సాధనంతో వర్తించిన ఫైర్వాల్ నియమాలు అన్నీ కాన్ఫిగరేషన్ డైరెక్టరీ వెలుపల నివసిస్తాయి, వాటిని పట్టించుకోని పునరుద్ధరణ కాన్ఫిగర్ చేయబడినట్లు కనిపించే కానీ ఫార్వర్డ్ చేయని యంత్రాన్ని ఉత్పత్తి చేస్తుంది.
| What changed | Restored by a configuration backup | Needs its own action |
|---|---|---|
| Service unit or startup ordering | Partly, if the unit file was included | Package state and enabled links |
| Kernel module or interface support | No | Kernel or module rollback, or a boot-time decision |
| Peer or device authorization | Only if the backup predates the revocation | A deliberate decision about which peers return |
| Firewall rules applied outside the config | Only if they were captured | Replaying and verifying each rule |
అధికారం దాని స్వంత వరుసకు అర్హం. రాజీపడిన పరికరం తొలగించబడక ముందు తీసుకున్న బ్యాకప్ ఆ పరికరం యాక్సెస్ను సంతోషంగా పునరుద్ధరిస్తుంది. అంతరాయం సమయంలో దానికి తిరిగి వెళ్లడమే ఒక సంఘటన రెండు కావడానికి మార్గం, మరియు పునరుద్ధరణ నిర్ణయం ఫైళ్ల గురించి ఎంత స్పష్టంగా తీసుకోబడుతుందో అంత స్పష్టంగా సహచరుల గురించి కూడా తీసుకోవాలి.
రోల్బ్యాక్ యొక్క విధానం కూడా ముఖ్యం. ప్యాకేజీ నిర్వహించే ఫైల్పై పాత ఎగ్జిక్యూటబుల్ను కాపీ చేయడం ప్యాకేజీ మార్పు యొక్క మద్దతు ఉన్న రివర్సల్ కాదు, అది ప్యాకేజీ డేటాబేస్ను ఫైల్ సిస్టమ్తో సరిపోలని స్థితిని వివరించనిస్తుంది. ప్యాకేజీ మేనేజర్ యొక్క స్వంత డౌన్గ్రేడ్ మార్గాన్ని లేదా ప్రదాత అందించే స్నాప్షాట్ను ఉపయోగించండి. ప్యాకేజీ డేటాబేస్ నమోదు చేసే డౌన్గ్రేడ్ మీరు పునరావృతం చేయగలిగినది.
ఇవేవీ బ్యాకప్లకు వ్యతిరేకం కాదు. ప్రతి కళాఖండం ఏ పొరను కవర్ చేస్తుందో తెలుసుకోవడం కోసం, ఎందుకంటే పాక్షిక పునరుద్ధరణ యొక్క వైఫల్య విధానం అసలు అంతరాయం కంటే గందరగోళంగా ఉంటుంది. రన్బుక్లో ప్రతి బ్యాకప్ పక్కన పొరను రాయండి.
చెక్పాయింట్, అప్డేట్, తర్వాత బయటి నుండి ధృవీకరణ
మార్పుకు ముందు స్థితిని తర్వాత పోల్చగల రూపంలో నమోదు చేయండి: ఇన్స్టాల్ చేసిన వెర్షన్లు, సంబంధిత సేవా యూనిట్లు, వినిపిస్తున్న సాకెట్లు మరియు ప్రస్తుత సహచరుల జాబితా. లినక్స్ హోస్ట్పై నాలుగు ఆదేశాలు దానిలో ఎక్కువ భాగాన్ని కవర్ చేస్తాయి.
systemctl list-units --type=service | grep -E 'openvpn|wg-quick'
ss -lunp | grep -E ':51820|:1194'
journalctl -u wg-quick@wg0 --since '-10 min'
మొదటిది ఏ యూనిట్లు ఉన్నాయి మరియు అవి నడుస్తున్నాయా చూపిస్తుంది, రెండవది శ్రోత నిజంగా బంధించబడిందని నిర్ధారిస్తుంది, మూడవది గత కొన్ని నిమిషాల గురించి సేవ యొక్క స్వంత వృత్తాంతాన్ని ఇస్తుంది. వాటిలో ఏదీ క్లయింట్ కనెక్ట్ కాగలదని నిరూపించదు, అందుకే తదుపరి దశ హోస్ట్ వెలుపల జరుగుతుంది. ఆ పఠనాలను మీ పోలిక ఆధారంగా ఉంచుకోండి.
టన్నెల్ ఉపయోగించని నెట్వర్క్ నుండి ధృవీకరించండి: ఒక అధికృత క్లయింట్ను ధృవీకరించి, ఒక పేరును పరిష్కరించి, ఒక ఉద్దేశిత అప్లికేషన్ను చేరుకోండి. ఇంటర్ఫేస్ పైన ఉందని చెప్పే స్థానిక స్థితి వరుస ఇంటర్ఫేస్ గురించిన ప్రకటన, రూటింగ్, కీలు లేదా సహచరుడిని అనుమతించే విధానం గురించి కాదు.
తర్వాత పునఃకనెక్షన్ మార్గాన్ని ఉద్దేశపూర్వకంగా పరీక్షించండి. సేవను ఒకసారి పునఃప్రారంభించి, చేతి జోక్యం లేకుండా టన్నెల్ తిరిగి వస్తుందని నిర్ధారించండి, ఎందుకంటే బూట్లో మాత్రమే సరిగ్గా ప్రారంభమయ్యే సేవ మీకు అత్యంత దుర్భర క్షణంలో ఆశ్చర్యం కలిగిస్తుంది.
అది విఫలమైతే, పరీక్షించిన మార్గాన్ని ఉపయోగించండి
పునరుద్ధరణ క్రమం భవ్యంగా ఉండదు మరియు అది పనిచేస్తుంది: స్వతంత్ర మార్గం ద్వారా హోస్ట్ను చేరుకోండి, సేవ యొక్క స్వంత లాగ్లను చదవండి, మరియు వైఫల్యానికి సరిపోయే నిర్దిష్ట చెక్పాయింట్ను పునరుద్ధరించండి. ప్రతి ప్రయత్నంలో ఒక విషయం మార్చండి, అప్పుడు తదుపరి లాగ్ పఠనం అర్థవంతంగా ఉంటుంది.
కనెక్టివిటీని తిరిగి పొందడానికి అనేక నమోదు చేయని మార్పులు చేయాలనే కోరికను ఎదిరించండి. ఒకేసారి ఐదు సవరణలతో బాగుచేసిన యంత్రాన్ని తర్వాత వివరించలేము, మరియు తదుపరి అప్డేట్ నిజంగా భారం మోసిన మార్పును మళ్లీ తెస్తుంది.
తర్వాత సాక్ష్యాలతో శాశ్వత విధానాన్ని నిర్ణయించండి. అప్డేట్ ఎవరూ నమోదు చేయని ఆధారపడటాన్ని బయటపెట్టిందంటే, పరిష్కారం డాక్యుమెంటేషన్ మరియు ఒక పరీక్ష, అప్డేట్లను ఆపడం కాదు. శుభ్రంగా పునఃప్రారంభించలేని సేవను బయటపెట్టిందంటే, పరిష్కారం యూనిట్లో ఉంది, షెడ్యూల్లో కాదు.
షరతుకు పేరు రాగానే పోలిక శుభ్రంగా పరిష్కారమవుతుంది. స్వతంత్ర మార్గం పర్యవేక్షణ లేని అప్డేట్లను నిర్వహించగల ప్రమాదంగా మారుస్తుంది. దాని లేమి అదే విధానాన్ని తెలియని పునరుద్ధరణ సమయంతో కూడిన ప్రణాళికాబద్ధ అంతరాయంగా మారుస్తుంది, మరియు ఏ ఆటోమేషన్ ఆ గణితాన్ని మార్చదు.