L2TP NO_PROPOSAL_CHOSEN: వాస్తవానికి ఏ దశ విఫలమైంది?
ఒక ప్రతిపాదన తిరస్కరించబడిందని నోటిఫికేషన్ చెబుతుంది, ఏది అని కాదు. దశ కోసం బ్యాకెండ్ లాగ్ చదవండి, తర్వాత గేట్‌వే నిర్వహించే వారితో సూట్‌లను పోల్చండి.
ఏ PPP వినియోగదారు పేరు పరిశీలించబడక ముందే NO_PROPOSAL_CHOSEN వస్తుంది, ఇది ఉపయోగకరమైన వాస్తవం మరియు సందేశం ఎందుకు తప్పుదారి పట్టిస్తుంది అనే కారణం కూడా. ఒక వైపు ప్రతిపాదనను తిరస్కరించిందని అది నివేదిస్తుంది; ఏ పరామితి మేళవించలేదో నివేదించదు, మరియు తిరస్కరణ IKE అనుబంధం నిర్మించే సమయంలో జరిగిందా లేక తర్వాత ట్రాఫిక్ రక్షణపై చర్చల సమయంలో జరిగిందా అనే దాని గురించి కూడా ఏమీ చెప్పదు. ఈ రెండు అవకాశాల వెనుక రెండు వేర్వేరు సవరణలు ఉన్నాయి, మరియు వాటిలో ఒకటి మాత్రమే ప్రజలు మొదట చేయి వేసే PFS చెక్‌బాక్స్‌కు సంబంధించినది.
ఒక సందేశం, రెండు ప్రతిపాదన సమితులు
IKEv1 L2TP/IPsec ఏర్పాటులో రెండు చర్చలు వరుసగా జరుగుతాయి. దశ 1 ఎన్‌క్రిప్షన్ అల్గారిథమ్, సమగ్రత అల్గారిథమ్ మరియు Diffie-Hellman సమూహం నుండి IKE భద్రతా అనుబంధాన్ని నిర్మిస్తుంది. తర్వాత దశ 2 ట్రాఫిక్ ఎలా రక్షించబడుతుందో చర్చిస్తుంది, మరియు PFS అవసరం ఆ రెండవ సంభాషణకు చెందుతుంది.
| Phase | What is agreed | What a rejection here means |
|---|---|---|
| Phase 1 | Encryption, integrity, DH group for the IKE SA | No management tunnel exists, so nothing later can run |
| Phase 2 | ESP transforms plus the PFS group policy | The IKE SA negotiates, then child negotiation fails |
దశలు వరుసగా ఉన్నందున, వైఫల్య స్థానం ఏ జాబితాను పోల్చాలో చెబుతుంది. సందేశం యొక్క మొత్తం నిర్ధారణ విలువ అందులోనే ఉంది, మరియు ఏదైనా సెట్టింగ్‌ను తాకే ముందు దాన్ని బయటకు తీయడం విలువైనది.
PFS చెక్‌బాక్స్ దశ 1 ను ఎందుకు సరిచేయలేదు
PFS ను నిలిపివేయడం దశ 2 యొక్క ఒక లక్షణాన్ని మారుస్తుంది. పక్షాలు దశ 1 పై ఎప్పుడూ అంగీకరించకపోతే, ESP సంభాషణ ఎప్పటికీ జరగదు, కాబట్టి చెక్‌బాక్స్ తిరస్కరణపై ఎటువంటి ప్రభావం చూపదు, అందుకే దాన్ని మార్చడం అదే లోపాన్ని వేరే సమయ ముద్రతో ఇస్తుంది.
వ్యతిరేక లోపం కూడా అంతే సాధారణం. విజయవంతమైన IKE అనుబంధం ESP ప్రతిపాదన ఆమోదయోగ్యమని నిరూపించదు, మరియు దశ 2 సమూహం సరిపోతుందని ఎట్టిపరిస్థితుల్లో నిరూపించదు. స్థాపించిన నిర్వహణ సొరంగాన్ని దశ 1 గురించి మాత్రమే సాక్ష్యంగా పరిగణించండి. ప్రజలు ఆకుపచ్చ రేఖను «సొరంగం నడుస్తోంది» అని చదివి, రెండవ చర్చ ప్రారంభం కాలేదని ఎవరూ చెప్పకపోవడంతో తప్పు దశపై ఒక గంట వృథా చేస్తారు.
అల్గారిథమ్‌లను ఎంచుకునే ముందు లాగ్ చదవండి
తిరస్కరణకు ముందు వచ్చిన సందేశాలను కనెక్షన్‌ను నిజంగా నిర్వహించే బ్యాకెండ్ నుండి సేకరించి, వాటిని అదే ప్రయత్నంతో అనుసంధానించండి. ఆ అనుసంధానం లేకుండా మీరు మరొక కనెక్షన్ చరిత్రను చదువుతున్నారు మరియు దాని నుండి నిర్ణయాలకు వస్తున్నారు.
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # Libreswanఆ పంక్తుల నుండి రెండు ప్రశ్నలకు సమాధానం ఇవ్వండి: దశ 1 అనుబంధం స్థాపించబడిందా, మరియు ఏ మార్పిడి విఫలమైంది. ఆ రెండు సమాధానాలు వెతుకుడును ఒకే లక్షణ జాబితాకు సంకోచిస్తాయి. చుట్టుపక్కల సందర్భం లేని నగ్న నోటిఫికేషన్ అది చేయలేదు, ఫోరమ్ థ్రెడ్ నుండి ప్రతిపాదనను ప్రయత్నించడం ఎంత ఆకర్షణీయంగా ఉన్నా. వేరే బ్యాకెండ్ ఉన్న యంత్రం నుండి పనిచేసే స్ట్రింగ్‌ను కాపీ చేయడం సాధారణంగా ఒక తిరస్కరణను మరొక దానితో భర్తీ చేస్తుంది, కొంచెం ఆలస్యంగా.
బ్యాకెండ్ వాక్యనిర్మాణం ప్రయాణించదు
ఏదైనా పోల్చే ముందు NetworkManager-l2tp సంస్కరణను మరియు IPsec బ్యాకెండ్ సంస్కరణను నమోదు చేయండి. Libreswan మరియు strongSwan ప్రతిపాదన వాక్యనిర్మాణాన్ని లేదా ఒకే అల్గారిథమ్ సమితులను పంచుకోవు, కాబట్టి ఒకదానిలో పనిచేసే స్ట్రింగ్ మరొకదానిలో వాక్యనిర్మాణ లోపం. ఇన్‌స్టాల్ చేసిన బ్యాకెండ్ విధానం ప్రకారం IKEv1 ను కూడా తిరస్కరించవచ్చు, అప్పుడు ఏ ప్రతిపాదనా ఎప్పటికీ ఆమోదించబడదు.
ప్రాజెక్ట్ README ఆ బ్యాకెండ్ భేదాలను నమోదు చేస్తుంది మరియు దశ 1 మరియు దశ 2 క్షేత్రాలను వేరుగా ఉంచుతుంది. దాన్ని నిర్మాణపు పత్రంగా చదవండి, ప్రతి చారిత్రక సైఫర్ మరియు బలహీన సమూహాన్ని ఆన్ చేయమని పిలుపుగా కాదు, ఎందుకంటే అలా చేయడం వల్లనే విజయవంతమయ్యే కనెక్షన్ మీరు నిర్మించమని అడిగిన కనెక్షన్ కాదు.
సూట్‌పై అంగీకరించండి, తర్వాత దశలను ధృవీకరించండి
ఏ IKE మరియు ESP సూట్‌లు మద్దతు పొంది ఆమోదించబడ్డాయో గేట్‌వే ఆపరేటర్‌ను అడగండి, తర్వాత ఆ సమాధానాన్ని క్లయింట్ కాన్ఫిగరేషన్ ఫైల్‌తో కాకుండా దాని వాస్తవ ప్రతిపాదనలతో పోల్చండి. భేదం ప్రత్యేకంగా దశ 2 PFS గురించి అయితే, మద్దతు ఉన్న సమూహం లేదా స్పష్టంగా ఆమోదించబడిన PFS లేని విధానంపై నిర్ణయించండి. లోపం పేరు నుండి విధానాన్ని ఊహించవద్దు.
ఏకైక అతివ్యాప్తికి సంస్థ ఇకపై ఆమోదించని క్రిప్టోగ్రఫీ అవసరమైతే, నిర్ణయం గేట్‌వేది లేదా ప్రోటోకాల్ మార్పిడిది. ఏదో చర్చ జరిగే వరకు క్లయింట్ స్ట్రింగ్‌ను విస్తరించడం తెలిసిన బలహీనతను పక్కన ఆకుపచ్చ టిక్‌తో పంపే మార్గం.
నిజమైన అసంగతిని సరిచేసిన తర్వాత, L2TP మరియు PPP ను పరిశోధించే ముందు IPsec స్థాపనను నిర్ధారించండి, మరియు తర్వాత వచ్చే ఏ ప్రమాణీకరణ తిరస్కరణనైనా తదుపరి దశకు చెందినదిగా పరిగణించండి. తర్వాత ఆమోదించిన పరీక్ష ప్రక్రియలో పునరుద్ధరణను పరీక్షించండి, ఎందుకంటే మొదటి అనుబంధ స్థాపన దాని మిగిలిన ఆయుష్షు గురించి ఏమీ చెప్పదు.