L2TP: ప్రాణాంతక సిగ్నల్ 15, NO_PROPOSAL_CHOSEN మరియు కనుమరుగైన modp1024
NO_PROPOSAL_CHOSEN తో కలిసి వచ్చే ప్రాణాంతక సిగ్నల్ 15 అంటే దశ 2 లో అసమతుల్యత: డీమన్ ఇక modp1024 ఇవ్వడం లేదు, లేదా దశ 1 విలువ దశ 2 ఫీల్డ్లో ఉంది.
మీ కనెక్షన్ నిలిచిపోతుంది, క్లయింట్ నిష్క్రమిస్తుంది, స్క్రీన్పై చివరి లైన్ death_handler: Fatal signal 15 received. ఆ లైన్ అంతరాయాన్ని నివేదిస్తుంది, కారణాన్ని కాదు. IPsec లాగ్లో ఒక లైన్ పైన దాదాపు ఎప్పుడూ NO_PROPOSAL_CHOSEN ఉంటుంది, ఈ జంట మార్పిడి దశ 2 వైపు సూచిస్తుంది, అక్కడ రెండు వైపులా ఎన్క్రిప్షన్ మరియు హాష్ ఎంపికలను పోల్చి ఉమ్మడిగా ఏమీ లేకపోతే ఆగిపోతాయి. ఆ దశలో ఆధారాలు ఇంకా పంపబడలేదు, కాబట్టి పాస్వర్డ్ మళ్లీ టైప్ చేయడం ఫలితాన్ని మార్చదు.
Linux క్లయింట్లో సాధారణంగా రెండు విషయాలు ఆ ఖండనను ఖాళీ చేస్తాయి. ప్రొఫైల్ అడిగే Diffie-Hellman సమూహాన్ని స్థానిక డీమన్ ఇక అమలు చేయకపోవచ్చు, లేదా ప్రొఫైల్ దశ 1 ప్రతిపాదనను దశ 2 ఫీల్డ్లో కలిగి ఉండవచ్చు. రెండూ లాగ్లో ఆనవాలు వదిలిపోతాయి, ఏదీ ఖాతా సమస్య కాదు.
ఆ రెండు సందేశాలు నిజంగా ఏం చెబుతున్నాయి
IKE దశలుగా చర్చలు జరుపుతుంది. దశ 1 రక్షిత ఛానెల్ను నిర్మించి తన స్వంత అల్గారిథమ్లను ఎంచుకుంటుంది; దశ 2, అంటే బిడ్డ SA, వేరే సెట్ కింద ట్రాఫిక్ను మోసుకెళ్తుంది. NO_PROPOSAL_CHOSEN అంటే అందించిన కలయికలలో ఏదీ ఆమోదయోగ్యం కానప్పుడు ప్రతిస్పందించేది తిరిగి పంపే నోటిఫికేషన్, అది INFORMATIONAL మార్పిడి లోపల [ HASH N(NO_PROP) ] రూపంలో కనిపిస్తుంది.
సిగ్నల్ 15 వేరే సంఘటన: ఏదో స్థానిక ప్రక్రియను ఆగమని చెప్పింది, హ్యాండ్లర్ దాన్ని నమోదు చేసింది. రెండు లైన్లు కలిసి కనిపించినప్పుడు క్రమం కారణాత్మకం, మొదట తిరస్కరణ తర్వాత ఆఫ్ చేయడం.
ఆధారాలను తాకే ముందు చర్చలను చదవండి
డీమన్ రాసే చోట లాగ్ స్థాయిని పెంచి, ఆ తర్వాత అవుట్పుట్ను గమనిస్తూ మళ్లీ కనెక్ట్ అవ్వండి. NetworkManager హోస్ట్లో L2TP ప్లగిన్ ఆ స్థాయిని బ్యాకెండ్కు అందిస్తుంది, సందేశాలు పంపిణీని బట్టి journal లేదా సాంప్రదాయ syslog ఫైల్లో చేరతాయి. వీటిలో ఏదైనా మార్పిడిని చూపుతుంది: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' లేదా tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.
pluto పేరున్న లైన్ libreswan నుండి వస్తుంది, charon strongSwan నుండి, రెండూ ఒకే స్థితిని వేరే పదాల్లో వివరిస్తాయి. వెతకదగిన రూపం కనుమరుగైన సమూహాన్ని పేర్కొనేది, ఉదాహరణకు algorithm 'modp1024' is not supported, ఎందుకంటే అది అస్పష్టమైన వైఫల్యాన్ని స్పష్టమైనదిగా మారుస్తుంది.
modp1024 ఎక్కడికి పోయింది
Diffie-Hellman సమూహం 2 చాలా బలహీనం కాబట్టి అనేక పంపిణీలు 3.30 నుండి దాన్ని libreswan లో కంపైల్ చేయడం ఆపేశాయి. అప్పుడు సంవత్సరాల క్రితం రాసిన లేదా aes128-sha1-modp1024 మాత్రమే జాబితా చేసే గేట్వే మార్గదర్శకం నుండి తీసుకున్న ప్రొఫైల్ స్థానిక డీమన్ను అది అసలు చేయలేని పనిని అడుగుతుంది. కొత్త NetworkManager-l2tp బిల్డ్లు ఆ ఫలితాన్ని మరింత సంభావ్యం చేస్తాయి: 1.2.16 నుండి అవి సెట్ను Windows 10 మరియు iOS శైలి ప్రతిపాదనలతో భర్తీ చేసి, libreswan గుర్తించబడగానే modp1024 ను వదిలేస్తాయి. ఎదుటి వైపు తరచుగా నిర్దోషి, ఇప్పటికీ మీరు కాన్ఫిగర్ చేసిన సమూహాన్నే అందిస్తుంది.
ఈ అసమానతే వైఫల్యాన్ని యాదృచ్ఛికంగా అనిపించేలా చేస్తుంది. పాత క్లయింట్ కనెక్ట్ అవుతుంది, నవీకరించిన ల్యాప్టాప్లో అదే ప్రొఫైల్ కనెక్ట్ కాదు, సర్వర్ కాన్ఫిగరేషన్ ఎప్పుడూ కదలలేదు. నష్టాన్ని వెర్షన్ జారుడు చేస్తుంది.
వేర్వేరు ప్రభావాలతో రెండు మరమ్మతులు
చవకైన మరమ్మతు అల్గారిథమ్లను చేతితో గట్టిగా పెట్టడం ఆపడం. ఎడిటర్లో రెండు ప్రతిపాదన ఫీల్డ్లను ఖాళీ చేసి, దూరపు వైపు అంగీకరించే సెట్ను ప్లగిన్ ఎంచుకోనివ్వండి; గేట్వే ఆధునిక సమూహాలను మద్దతిస్తే చర్చలు అదనపు పని లేకుండా పూర్తవుతాయి.
రెండవ మరమ్మతు strongSwan ఇన్స్టాల్ చేయడం ద్వారా పాత గేట్వేను చేరుకోగలిగేలా ఉంచుతుంది, దాని ప్యాకేజీలు చాలా పంపిణీలలో ఇప్పటికీ సమూహం 2 ను అమలు చేస్తాయి. అది డీమన్ మార్పిడి, కాబట్టి ధర ఉంది: తొలగించే ముందు హోస్ట్లోని ఇతర సొరంగాలు libreswan కాన్ఫిగరేషన్పై ఆధారపడి ఉన్నాయా అని నిర్ధారించండి, Fedora లో NetworkManager మరియు strongSwan ప్లగిన్ మధ్య SELinux తిరస్కరణలను ఆశించండి. ఆ తిరస్కరణలు IKE ట్రేస్లో కాదు, ఆడిట్ లాగ్లో కనిపిస్తాయి, అందుకే విజయవంతమైన ఇన్స్టాల్ తర్వాత వెంటనే సొరంగం విరిగినట్టు అనిపించవచ్చు. పనిచేసే క్రమం మొదట dnf install strongswan, తర్వాత rpm -e libreswan.
సరిపోలే ప్రతిపాదన స్ట్రింగ్లు, మరియు వాటి చుట్టూ ఉన్న ఉచ్చులు
ఫీల్డ్లను చేతితో నింపాల్సి వచ్చినప్పుడు దశ 1 మరియు దశ 2 వేరే విలువలు తీసుకుంటాయి. Meraki శైలి ఎదుటి వైపు ఎదురుగా పనిచేస్తుందని తెలిసిన జంట దశ 1 లో aes128-sha1-modp1024 ను దాని వెనుక 3des-sha1-modp1024 తో అందిస్తుంది, రెండూ సెట్ను కఠినం చేసే ఆశ్చర్యార్థక చిహ్నంతో మూసివేయబడతాయి, కాబట్టి ఆ ప్రతిపాదనలే పంపబడతాయి.
తర్వాత దశ 2 అదే కఠిన గుర్తుతో, Diffie-Hellman ప్రత్యయం లేకుండా aes128-sha1 మరియు 3des-sha1 కు సన్నగిల్లుతుంది. -modp1024 మోసే దశ 2 లైన్ తప్పు ఫీల్డ్లోని దశ 1 విలువ, ప్రతిస్పందించేది ప్రతి పునఃప్రయత్నంలో దాన్ని తిరస్కరిస్తుంది. ఆ లైన్ను రెండవ ప్రొఫైల్కు కాపీ చేయండి, రెండవ ప్రొఫైల్ కూడా అదే విధంగా విఫలమవుతుంది, ఇలా ఒక టైపింగ్ పొరపాటు మొత్తం నౌకాదళానికి సంఘటన అవుతుంది.
ఇతర లోపాలు ప్రతిపాదన అసమతుల్యత కాకుండానే అదే పాపప్ను ధరిస్తాయి. KDE లో ప్లగిన్ ఇన్స్టాల్ అయి ఉన్నా L2TP రకం జాబితాలో ఉండవచ్చు, కానీ ప్రతి కనెక్షన్ వెంటనే చనిపోతుంది, ఎందుకంటే కనెక్షన్ ఎడిటర్ మరియు రన్టైమ్ సహాయకులు వేర్వేరు ప్యాకేజీలుగా వస్తాయి. స్క్రీన్ లేని హోస్ట్లు పనిచేసే డెస్క్టాప్ నుండి ప్రొఫైల్ను తిరిగి ఉపయోగించవచ్చు: దాన్ని /etc/NetworkManager/system-connections/ నుండి కాపీ చేసి, మోడ్ను 600 కు సెట్ చేసి, తర్వాత nmcli con reload అమలు చేయండి. దాన్ని nmcli con up id work-l2tp తో పైకి తీసుకురండి, ఎందుకంటే నగ్న రూపానికి UUID కావాలి, మరియు పాత ifname ఎంట్రీని తీసివేయండి, లేకపోతే మిగతావన్నీ సరిగ్గా ఉన్నా నిర్వాహకుడు Could not find source connection అని సమాధానం ఇస్తాడు.
ముందుగా పంచుకున్న కీని స్పష్టమైన వచనంగా లేదా 0s తర్వాత base64 గా నిల్వ చేయవచ్చు; రెండు రూపాలూ పనిచేస్తాయి, కానీ విలువ గేట్వేతో బైట్ బైట్ సరిపోలాలి, దానితో పాటు కాపీ చేసిన చివరి ఖాళీలతో సహా.