Linux లో SNX: 32-బిట్ లైబ్రరీలు మరియు మళ్లీ రీసెట్ అయ్యే రిజాల్వర్
Linux లో SNX లోడర్, రూట్ పట్టిక లేదా రిజాల్వర్ వద్ద విఫలమవుతుంది, మరియు ప్రతి వైఫల్యం లాగిన్ సమస్యలా కనిపిస్తుంది. నాలుగు లక్షణాలను క్రమంగా నిర్వహించండి.
Check Point యొక్క SSL Network Extender Linux లో నాలుగు గుర్తించదగిన విధాలుగా విఫలమవుతుంది, వాటిలో మూడు లాగిన్ సమస్యగా తప్పుగా చదవబడతాయి. ఒకటి బైనరీ ప్రారంభం కాదు, లేదా ప్రారంభమై ఏ మార్గాన్ని వదలదు, లేదా కనెక్ట్ అయి పేరు పరిష్కారం చనిపోతుంది, లేదా బ్రౌజర్ పోర్టల్ పనిచేస్తుంది కానీ ఆదేశ పంక్తి పనిచేయదు. వాటిని అదే క్రమంలో నిర్వహించండి, ఎందుకంటే ప్రతి ఒక్కటి తదుపరి దానికి ప్రవేశ షరతు.
లక్షణం ఒకటి: లాగిన్ ముందు లోడర్ నిరాకరిస్తుంది
ఫైర్వాల్ నుండి తీసుకున్న ఇన్స్టాలర్ 32-బిట్, setuid-root బైనరీని /usr/bin/snx లో ఉంచుతుంది. 64-బిట్ పంపిణీలో i386 ఆర్కిటెక్చర్ ప్రారంభమయ్యే వరకు మరియు అది లింక్ చేసే లైబ్రరీలు ఉన్నంత వరకు అది నడవదు.
sudo dpkg --add-architecture i386
sudo apt update
sudo apt install libstdc++5:i386 libstdc++6:i386 libx11-6:i386 libpam0g:i386
ldd /usr/bin/snx | grep "not found"ఖాళీ not found జాబితా తర్వాతి అన్నింటికి ద్వారం. ఖచ్చితమైన ప్యాకేజీ సెట్ విడుదలల మధ్య మారుతుంది: ఒక పనిచేసిన నివేదికకు libstdc++5:i386, libx11-6:i386 మరియు libpam0g:i386 అవసరమయ్యాయి, మరొకదానికి libstdc++6:i386 కూడా అవసరమైంది. వేరే పంపిణీ కోసం రాసిన ట్యుటోరియల్ నుండి ప్యాకేజీ జాబితాను కాపీ చేయడానికి బదులు ldd చదవండి.
snx అసలే కనబడకపోతే, ఇన్స్టాలర్ ఎప్పుడూ పూర్తికాలేదు లేదా మీ PATH వెలుపల ఎక్కడో ఇన్స్టాల్ అయింది. అది వేరే వైఫల్యం, మరియు సిస్టమ్కు ఆర్కిటెక్చర్లను జోడించే ముందు దాన్ని నిర్ధారించుకోవడం విలువైనది. command -v snx తో తనిఖీ చేసి ఇన్స్టాలర్ నివేదించిన డైరెక్టరీలో చూడండి. బైనరీనే లేని మెషీన్లో i386 ప్యాకేజీలను జోడించడం ఏమీ సరిచేయదు.
లక్షణం రెండు: లాగిన్ విజయవంతమవుతుంది, ఏదీ రూట్ కాదు
విజయవంతమైన లాగిన్ tunsnx ను సృష్టించి రూటింగ్ పట్టికను తానే సవరిస్తుంది, కాబట్టి మరేదైనా మార్చే ముందు నిజంగా ఏమి ఉందో తనిఖీ చేయండి.
ip -br addr show tunsnx
ip route | grep tunsnx
snx -dవిడదీయడానికి snx -d ఉపయోగించండి. ప్రక్రియను చంపడం ఇంటర్ఫేస్ మరియు దాని మార్గాలను వదిలివేస్తుంది, తదుపరి ప్రయత్నం అప్పుడు ఆధారాలతో ఎటువంటి సంబంధం లేని కారణంతో విఫలమవుతుంది. మొదటి లాగిన్ /etc/snx/ కింద సర్వర్ సంతకాన్ని కూడా నమోదు చేస్తుంది, అందుకే పర్యవేక్షణ లేని స్క్రిప్ట్ పూర్తిగా పనిచేయడానికి ముందు ఒక ఇంటరాక్టివ్ రన్ అవసరం కావచ్చు. ఆ స్థితిని సర్వర్ను మళ్లీ ఆమోదించాలని భావించినప్పుడు మాత్రమే తొలగించండి.
లక్షణం మూడు: సొరంగం పైకి వచ్చే వరకు పేర్లు పరిష్కరించబడతాయి
ఇదే నిశ్శబ్దంగా విరిగిపోతుంది. snx నెట్టబడిన DNS సర్వర్లను నేరుగా /etc/resolv.conf లో రాస్తుంది. ఆ మార్గం /run/systemd/resolve/ లోకి సింబాలిక్ లింక్ అయినప్పుడు, తదుపరి రిజాల్వర్ సంఘటనలో సవరణ పోవచ్చు, మరియు కనెక్షన్ తెగిన తర్వాత నెట్టబడిన ఎంట్రీలు కూడా అలాగే ఉండవచ్చు.
రెండు ఏర్పాట్లు పనిచేస్తాయి, ఎంపిక మొదటి శోధన ఫలితం సూచించినది కాకుండా ఉద్దేశపూర్వకంగా ఉండాలి:
- ఫైల్ను మీరే తీసుకోండి: సింబాలిక్ లింక్ స్థానంలో స్థిర ఫైల్ పెట్టి
libnss-resolveమరియు దాని i386 రూపాంతరాన్ని ఇన్స్టాల్ చేయండి, ఫైల్ కింది నుండి తిరిగి రాసినప్పుడు కూడా పేరు సేవకు ప్రత్యామ్నాయం ఉంటుంది. - systemd-resolved ను యజమానిగా ఉంచి సొరంగ లింక్ను నమోదు చేయండి:
resolvectl dns tunsnx 10.0.0.10, ఆ తర్వాతresolvectl domain tunsnx corp.example, మరియుresolvectl statusతో నిర్ధారించండి.
కనెక్ట్ చేయడానికి ముందు VPN-కి ముందు ఉన్న నేమ్సర్వర్లను నమోదు చేయండి. మీరు ఫైల్ను చేతితో సవరిస్తే, తర్వాత నెట్టబడిన ఎంట్రీలను తొలగించడం ప్రక్రియలో భాగం, ఐచ్ఛిక శుభ్రత కాదు, ఎందుకంటే కనెక్షన్ తెగిన తర్వాత కార్పొరేట్ DNS ను ఉంచుకునే ల్యాప్టాప్ మరేదీ పరిష్కరించలేదు.
లక్షణం నాలుగు: పోర్టల్ పనిచేస్తుంది, CLI పనిచేయదు
ఇటీవలి ఫైర్వాల్ విడుదలలు మిడిల్వేర్ను బ్రౌజర్ నుండి స్థానిక Java డీమన్కు తరలించాయి, కాబట్టి పోర్టల్ పోర్ట్ 14186 వద్ద స్థానిక ఏజెంట్తో మాట్లాడుతుంది. ఆ చిరునామాకు బ్రౌజర్ సర్టిఫికెట్ మినహాయింపు మరియు నడుస్తున్న ప్రక్రియ అవసరం.
ps ax | grep cshell
/usr/bin/cshell/launcherఆదేశ పంక్తి వేరే మార్గం: snx -s vpn.example.com -u user, ఇందులో ~/.snxrc సర్వర్, వినియోగదారు పేరు మరియు పునః ప్రామాణీకరణ ప్రాధాన్యతను ఉంచుతుంది. పనిచేసే పోర్టల్ సెషన్ CLI సరిగ్గా ఇన్స్టాల్ అయిందా అనే దాని గురించి ఏమీ చెప్పదు, మరియు సాదా క్లయింట్ ఒకసారి ఉపయోగించే కోడ్లను నిర్వహించదు.
ఆదా చేయడం కంటే ఎక్కువ ఖర్చు చేసే కంటైనర్ పొట్టి మార్గం
snx tun మాడ్యూల్ను తనిఖీ చేసి, లేనప్పుడు లోడ్ చేసి, సొరంగ ఇంటర్ఫేస్ను సృష్టించి, మార్గాలను తిరిగి రాసి, ట్రాఫిక్ను దాని గుండా పంపుతుంది. దీన్ని కంటైనర్ లోపల పునరుత్పత్తి చేయడం అంటే /dev మరియు /lib/modules మౌంట్ చేయడం మరియు విస్తృత సామర్థ్యాలను ఇవ్వడం, ఇది హోస్ట్ నెట్వర్క్ నిర్వహణలో ఎక్కువ భాగాన్ని కంటైనర్కు ఇస్తుంది.
నిజంగా ఇసుకపెట్టె అవసరమైనప్పుడు, వర్చువల్ మెషీన్ మరింత శుభ్రమైన సరిహద్దు: క్లయింట్ తాను మార్చగల కెర్నల్ను పొందుతుంది, హోస్ట్ తన రూట్ పట్టికను ఉంచుకుంటుంది. ఇచ్చినందుకు పశ్చాత్తాపపడే సామర్థ్యాలపై మధ్యాహ్నం గడపడానికి ముందు దాన్ని ఎంచుకోండి.