OpenConnect లాగిన్ కుకీని టన్నెల్గా ఎలా మారుస్తుంది?

OpenConnect రెండు వేర్వేరు మార్పిడులను ఒకే స్వల్పకాలిక విలువతో కలుపుతుంది: వెబ్ లాగిన్ మరియు VPN టన్నెల్. మొదటి మార్పిడి సాధారణ HTTPS: ఆధారాలు, ఒక SAML ప్రయాణం లేదా టోకెన్ గేట్వేకు వెళతాయి, ప్రతిస్పందన ప్రామాణీకరణ కుకీని తెస్తుంది. రెండో మార్పిడి ఆ కుకీని అదే గేట్వేకు వెబ్ దశ ఇప్పటికే జరిగిందని రుజువుగా సమర్పిస్తుంది, అప్పుడే టన్నెల్ పైకి వస్తుంది.

లాగిన్ సమయంలో టన్నెల్ గురించి ఏదీ చర్చించబడదు. ఇదే అర్థం చేసుకోవలసిన భాగం, ఎందుకంటే చాలా స్క్రిప్ట్ తప్పులు కుకీని నిల్వ చేయాల్సిన పాస్వర్డ్ లేదా ట్రాఫిక్ను రక్షించే కీ అని భావిస్తాయి, కానీ నిజానికి అది ఒక నిర్దిష్ట గేట్వే సెషన్ కోసం వాహక టికెట్.

క్లయింట్ మరియు గేట్వే వరుసగా ఏమి మార్పిడి చేసుకుంటాయి

ప్రామాణీకరణ దశ సాధారణ రక్షిత వెబ్సైట్లా కనిపిస్తుంది. OpenConnect వినియోగదారు ఆధారాలను పంపుతుంది, లేదా గేట్వే రీడైరెక్ట్ను అనుసరించి గుర్తింపు ప్రదాత వద్దకు వెళుతుంది, గేట్వే ప్రామాణీకరణ కుకీని పొందుపరిచిన పత్రంతో సమాధానం ఇస్తుంది. AnyConnect ప్రోటోకాల్లో ఆ విలువ తదుపరి అభ్యర్థనల్లో కుకీ హెడర్లో ప్రయాణిస్తుంది, సాధారణంగా webvpn వంటి పేరుతో, మరియు మాన్యువల్ దానిని సెషన్ను ముందుకు తీసుకెళ్లే ఆధారంగా పరిగణిస్తుంది.

రెండో దశ ఆ కుకీని జోడించి గేట్వే యొక్క VPN ముగింపు బిందువుకు పంపే CONNECT అభ్యర్థన. గేట్వే దానిని తనిఖీ చేసి చిరునామా కేటాయిస్తుంది, క్లయింట్ TLS పైన CSTP ప్రారంభిస్తుంది, సెషన్ ఉన్నప్పుడు DTLS ఐచ్ఛిక వేగవంతమైన డేటా మార్గం అవుతుంది. ఈ సమయంలోనే టన్నెల్ పరామితులు, మార్గాలు, DNS సెట్టింగ్లు మరియు సెషన్ యొక్క ట్రాఫిక్ కీలు స్థాపించబడతాయి. కుకీ క్లయింట్ను తలుపు గుండా పంపింది; అది ఏదీ గుప్తీకరించలేదు.

ఈ క్రమమే openconnect --authenticate ఎందుకు ఉందో వివరిస్తుంది. దాన్ని అమలు చేయండి, అది వెబ్ దశను చేస్తుంది, COOKIE, HOST, CONNECT_URL మరియు FINGERPRINT వంటి షెల్ చరాల చిన్న బ్లాక్ను ముద్రిస్తుంది, ఆపై ఏ టన్నెల్ నిర్మించబడకముందే నిష్క్రమిస్తుంది. తర్వాత ర్యాపర్ స్క్రిప్ట్ ఆ విలువలతో నిజమైన కనెక్షన్ను ప్రారంభించగలదు, మరియు హెడ్లెస్ లేదా రెండు కంటైనర్ అమరికకు సరిగ్గా ఈ విభజన అవసరం.

కుకీ సెషన్ యొక్క వాహకం, కీ కాదు

వెబ్ అప్లికేషన్లో సెషన్ ఐడీతో వ్యవహరించినట్టే ఈ విలువతో వ్యవహరించండి. దాని ఆయుష్షులో దాన్ని కలిగి ఉన్న ఎవరైనా ఆ సెషన్కు హక్కున్న టన్నెల్ను గేట్వే నుండి అడగగలరు, కాబట్టి దాని రహస్యత ముఖ్యం. కానీ నకలు చేయడం ట్రాఫిక్ను బయటపెట్టదు, ఎందుకంటే టన్నెల్ గోప్యత TLS హ్యాండ్షేక్ మరియు దాని నుండి ఉత్పన్నమైన కీల నుండి వస్తుంది, కుకీ స్ట్రింగ్ నుండి కాదు.

ఇది శాశ్వత అనుమతి కూడా కాదు. సెషన్ ఎంతకాలం జీవిస్తుందో గేట్వే మరియు గుర్తింపు ప్రదాత నిర్ణయిస్తారు, ఇంకా లాగిన్ అయిన పేజీని చూపుతున్న బ్రౌజర్ టన్నెల్ సెషన్ ఇంకా చెల్లుబాటులో ఉందా అనే దాని గురించి ఏమీ చెప్పదు. గడువు ముగిసిన తర్వాత తిరిగి కనెక్ట్ అవ్వడం అంటే వెబ్ దశను పునరావృతం చేసి కొత్త కుకీని సృష్టించడం, మరియు పునఃప్రామాణీకరణ ఉద్దేశ్యం అదే, ఇంజినీరింగ్తో తప్పించుకోవలసిన ఇబ్బంది కాదు.

కుకీని ఇతర ఆధారాలకు సార్వత్రిక ప్రత్యామ్నాయంగా భావించవద్దు. SAML ప్రకటన, బ్రౌజర్ పాస్వర్డ్ మరియు మరో సేవ జారీ చేసిన కుకీ వేర్వేరు ప్రేక్షకులతో వేర్వేరు వస్తువులు, ఒకదాన్ని మరొకదాని ఫీల్డ్లో అతికించడం సాధారణంగా గేట్వే వద్ద విఫలమవుతుంది లేదా అంతకంటే దారుణంగా, తప్పు విశ్వాస సరిహద్దుకు వ్యతిరేకంగా విజయవంతమవుతుంది.

నకళ్లు వదలకుండా కుకీని అప్పగించడం

Linux లో అత్యంత సురక్షితమైన యాంత్రిక అప్పగింపు ప్రామాణిక ఇన్పుట్. --cookie-on-stdin విలువను stdin నుండి చదువుతుంది, కాబట్టి కుకీ ప్రక్రియ ఆర్గ్యుమెంట్ జాబితాలో ఎప్పుడూ కనిపించదు, అక్కడ ఏ స్థానిక వినియోగదారు అయినా దాన్ని ps తో చదవగలరు. ఒక ప్రక్రియలో ప్రామాణీకరించి మరొకదానిలో టన్నెల్కు ఆహారం ఇచ్చే పైప్లైన్ విలువను ఫైల్ లేదా పర్యావరణ చరంలో కాకుండా పైపులో ఉంచుతుంది.

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

ప్రత్యేక హక్కుల సరిహద్దును కూడా ఉద్దేశపూర్వకంగా ఉంచండి. గుర్తింపు ప్రదాతతో మాట్లాడే మరియు బహుశా బ్రౌజర్ తెరిచే ప్రక్రియ ఆ లాగిన్ యజమాని అయిన వినియోగదారుగా నడవాలి. మార్గాలు, DNS మరియు టన్నెల్ పరికరాన్ని కాన్ఫిగర్ చేసే ప్రక్రియకు ఎక్కువ ప్రత్యేక హక్కులు అవసరం కావచ్చు. root స్వంతమైన టన్నెల్కు కుకీ అందుబాటులో ఉండాలని మొత్తం బ్రౌజర్ను root గా నడపడం తప్పు మార్పిడి, మరియు ఆధునిక OpenConnect అమరికలు ఆ సరిహద్దు దాటి విలువను స్పష్టంగా అప్పగించగలవు.

లాగింగ్ కూడా అదే అనుమానానికి అర్హం. వివరమైన క్లయింట్ అవుట్పుట్, సహాయక స్క్రిప్ట్లు మరియు గేట్వే నిర్ధారణ అన్నీ అభ్యర్థన సామగ్రిని పునరావృతం చేయగలవు, మరియు ప్రతి లాగ్ స్థాయి కుకీని దాచదు. మీకు అవసరమైన అతి చిన్న లోప రికార్డును పట్టుకోండి, దాన్ని పంచుకున్న ఛానెల్ల వెలుపల ఉంచండి, మరియు టికెట్కు జోడించే ముందు దాచిన నమూనాను తనిఖీ చేయండి.

రెండో దశలో ధృవీకరణ మరియు గడువు ముగియడం

రెండో దశ ఇంకా సర్వర్ను ధృవీకరించాలి. --authenticate ముద్రించే FINGERPRINT pin-sha256: రూపంలోని ధృవపత్ర పిన్, మరియు దాన్ని --servercert తో టన్నెల్ పిలుపుకు అప్పగించడం ధృవీకరణను మీరు ప్రామాణీకరించిన గేట్వేకు లంగరు వేసి ఉంచుతుంది. స్క్రిప్ట్ను సరళీకరించడానికి ధృవపత్ర తనిఖీని ఆపివేయడం కుకీ ఉద్దేశించిన హోస్ట్కు అప్పగించబడుతోందని చెప్పే ఏకైక రుజువును తొలగిస్తుంది.

గేట్వే కుకీని తిరస్కరించినప్పుడు పరిష్కారం కొత్త ప్రామాణీకరణ రౌండ్, పొడవైన కాష్ కాదు. కుకీని కనెక్షన్ ఆయుష్షు వరకు మాత్రమే నిల్వ చేయండి, నిష్క్రమించేటప్పుడు తాత్కాలిక ఫైళ్లను తొలగించండి, మరియు సెషన్ బహిర్గతమైనప్పుడు లేదా పరికరం పోయినప్పుడు గుర్తింపు ప్రదాత లేదా గేట్వే యొక్క సెషన్ తొలగింపు ప్రక్రియను ఉపయోగించండి. కాష్ చేసిన కుకీ MFA నుండి మినహాయింపు కాదు.

దీన్ని ఆటోమేట్ చేయడానికి ముందు నాలుగు విషయాలను ధృవీకరించండి: టన్నెల్ సరైన ఖాతాలో నడుస్తోంది, కుకీ stdin ద్వారా వస్తోంది, ధృవపత్రం యొక్క వేలిముద్ర పిన్ చేయబడింది, మరియు టన్నెల్ మూసివేసినప్పుడు సెషన్ పారవేయబడుతుంది. వీటిలో ఏదైనా లేకుంటే, ఆటోమేషన్ చేతితో చేసే ప్రవాహాన్ని పునరుత్పత్తి చేయడం బదులు కుకీపై నమ్మకాన్ని విస్తరించింది.