ipsec.conf లేదా swanctl.conf? ఒక strongSwan ఫ్రంటెండ్ ఎంచుకోండి

పాత మార్గదర్శిని నుండి పనిచేసే IKEv1 ప్రొఫైల్ Ubuntu 24.04 కు వస్తుంది, డీమన్ ఆ ఫైల్ను ఎప్పుడూ చదవనందున మొదటి ప్రయత్నం విఫలమవుతుంది. సాధారణ ప్రతిస్పందన ప్రొఫైల్ను మళ్లీ సవరించడం. నిజమైన ప్రశ్న ఏ strongSwan ఫ్రంటెండ్ ఇన్స్టాల్ చేయబడింది మరియు నడుస్తున్న సేవ ఏది ఉపయోగిస్తుంది అనేది. దానికి సమాధానం వచ్చేవరకు, ప్రతి సవరణ ఉనికిలో లేకపోవచ్చు లోడర్ వైపే మళ్లుతుంది.

రెండు ఫైళ్లు, రెండు లోడర్లు, ఒక డీమన్

పాత starter అమరిక ipsec.conf ను చదివి, తన పాత నిర్వహణ ఇంటిగ్రేషన్ ద్వారా కనెక్షన్లను charon కు అప్పగిస్తుంది. దాని కార్యాచరణ ప్రవేశ బిందువు ipsec ఆదేశం.

swanctl అమరిక VICI ద్వారా నిర్వచనాలను లోడ్ చేస్తుంది, swanctl.conf చదువుతుంది, swanctl ఆదేశంతో నడుస్తుంది. systemd యొక్క స్థానిక charon డీమన్ ఈ విధానంతో సమన్వయమవుతుంది.

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

ఇన్స్టాల్ చేసిన ప్యాకేజీలు మరియు unit లను చదవండి

చదవడం-మాత్రమే స్థితిలో ప్రారంభించండి. Ubuntu 24.04 లో ప్యాకేజీ పేర్లు వేర్వేరు: strongswan-starter, strongswan-swanctl మరియు charon-systemd. లేని ప్యాకేజీ ఉపయోగకరమైన సమాచారం, దాన్ని ఇన్స్టాల్ చేయమని సూచన కాదు.

ఒకే దశలో ప్యాకేజీలు మరియు unit లను జాబితా చేయండి:

dpkg-query -W strongswan-starter strongswan-swanctl charon-systemd
systemctl list-unit-files '*strongswan*'

తర్వాత క్రియాశీల unit మరియు దాని ప్రారంభ ఆదేశాన్ని పరిశీలించండి. unit పేరు ఏ డీమన్ కాన్ఫిగరేషన్ యజమాని అని చెబుతుంది, ఆదేశ పంక్తి ఏ ఫైళ్లను చదవాలని చెప్పబడిందో నిర్ధారిస్తుంది. ప్రారంభించబడినా నిష్క్రియంగా ఉన్న unit ఇప్పుడు నడుస్తున్న దానికంటే వేరే కథ చెబుతుంది.

క్రియాశీల unit strongswan-starter అయితే, ముఖ్యమైన ఫైల్ ipsec.conf. అది swanctl తో charon-systemd అయితే, ipsec.conf కేవలం అలంకారం.

సరిపోయే నియంత్రణ మార్గాన్ని ఉపయోగించండి

ప్రతి ఫ్రంటెండ్కు కనెక్షన్లు మరియు అనుబంధాలపై తనదైన దృష్టి ఉంటుంది. swanctl --list-conns లోడ్ అయిన నిర్వచనాలను చూపుతుంది, swanctl --list-sas క్రియాశీల అనుబంధాలను చూపుతుంది. పాత మార్గం ipsec statusall ఉపయోగిస్తుంది.

రెండింటినీ కలపడం తప్పుదారి పట్టించే లోపాలను కలిగిస్తుంది. లేని VICI సాకెట్ లేదా తిరస్కరించబడిన నియంత్రణ అభ్యర్థన అనేది నిర్వహణ మార్గ సమస్య, ఎదుటి వైపు ధృవీకరణను తిరస్కరించిందనడానికి సాక్ష్యం కాదు.

నడుస్తున్న డీమన్కు చెందిన దృష్టిని చదవండి, తర్వాత ఫలితాన్ని విశ్లేషించండి. ఆ దృష్టిలో కనెక్షన్ లేకపోతే, సమస్య లోడింగ్లో ఉంది, చర్చల్లో కాదు.

ఫార్మాట్ IKE వెర్షన్ కాదు

పాత ప్రొఫైల్ keyexchange=ikev1 తో IKEv1 ఎంచుకుంటుంది. swanctl కనెక్షన్ వెర్షన్ సెట్టింగ్ ఉపయోగిస్తుంది, అక్కడ 1 IKEv1 ఎంచుకుంటుంది. ఇవి ఒకే ఆలోచనకు రెండు పదకోశాలు, మార్పిడి కాదు.

ఎదుటి వైపు చిరునామాలు, స్థానిక మరియు దూర గుర్తింపులు, ఆధారాల మూలాలు, ప్రతిపాదనలు మరియు child ఎంపికకారులు ఉద్దేశపూర్వకంగా మ్యాప్ చేయాలి. left/right బ్లాక్ను swanctl వాక్యనిర్మాణంలో అతికించడం వాటిలో ఏదీ చేయదు.

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

ప్రొఫైల్ను తాకే ముందు లోడర్ను తనిఖీ చేయండి

మొదట లోడర్ తనిఖీని అమలు చేయండి, తర్వాత ఉద్దేశించిన కనెక్షన్ను లోడ్ చేయండి, తర్వాత చర్చలను అంచనా వేయండి, చివరగా రక్షిత ట్రాఫిక్ మార్గం. ప్రతి దశకు వేరే వైఫల్య సంకేతం ఉంటుంది.

రెండు నియంత్రణ మార్గాలు లోడింగ్ ప్రశ్నకు నేరుగా సమాధానమిస్తాయి:

swanctl --list-conns
ipsec statusall

ఈ ఆదేశాలలో ఒకటి మాత్రమే మీ హోస్ట్కు చెందుతుంది. రెండింటినీ నడిపి అవుట్పుట్ను పోల్చడం ఏది మీతో అబద్ధం చెబుతోందో తెలుసుకోవడానికి మార్గం, రోగనిర్ధారణ పద్ధతి కాదు.

ప్యాకేజీ యాజమాన్యం, కాన్ఫిగరేషన్ లోడింగ్ మరియు ప్రోటోకాల్ అనుకూలతను మూడు వేర్వేరు ప్రశ్నలుగా పరిగణించండి. ఒక ఫ్రంటెండ్కు చెల్లుబాటు అయ్యే ఫైల్ మరో డీమన్ నడుస్తుండగా పదే పదే సవరించబడుతుంది.