హోస్ట్ బయటకు వెళ్లే VPN నడుపుతున్నప్పుడు స్థానిక SSH ఉంచుకోండి

ఒక చిన్న Linux సర్వర్ తాను హోస్ట్ చేసే అప్లికేషన్ కోసం బయటకు వెళ్లే VPN నడుపుతుంది, మరియు నిర్వాహకుడు ఇప్పటికీ పక్కనున్న బల్ల నుండి SSH ద్వారా దాన్ని చేరుకోవాలనుకుంటున్నాడు. ఇది సహేతుకమైన అవసరం, సాధారణంగా దీనికి పోర్ట్ ఫార్వార్డింగ్, ప్రొవైడర్ చిరునామా లేదా సొరంగంలో రంధ్రం అవసరం లేదు. అవసరమైనది ఉద్దేశపూర్వకంగా రూపొందించిన నిర్వహణ మార్గం, VPN క్లయింట్ రౌటింగ్ పట్టికతో చేసిన దాని నుండి వారసత్వంగా వచ్చినది కాదు.

క్రింది దశలు నిర్వాహకుడు అదే LAN లో ఉన్నాడని భావిస్తాయి.రిమోట్ నిర్వహణ వేరే సమాధానం ఉన్న వేరే సమస్య.

నిర్వాహకులు ఉపయోగించే చిరునామాకు SSH ను బంధించండి

లిజనర్ నుండి ప్రారంభించండి.ss -ltnp | grep :22 sshd ఏదానికి కట్టబడిందో చూపిస్తుంది, మరియు 0.0.0.0 పై లిజనర్ సొరంగంతో సహా ప్రతి ఇంటర్ఫేస్ నుండి కనెక్షన్లను అంగీకరిస్తుంది. LAN చిరునామాకు బంధించడం సన్నగా ఉంటుంది మరియు ఉద్దేశాన్ని కనిపించేలా చేస్తుంది:ListenAddress 192.168.10.20 లోsshd_config, తర్వాత కాన్ఫిగరేషన్ పరీక్ష మరియు రీలోడ్. ఆ చిరునామాలో టైపో వైల్డ్కార్డ్ కంటే ఎక్కువ కనిపిస్తుంది, ఎందుకంటే చిరునామా లేనప్పుడు sshd ప్రారంభం కావడానికి నిరాకరిస్తుంది.

హోస్ట్-కీ తనిఖీ మరియు ప్రతి-వినియోగదారు ప్రామాణీకరణను ఉన్నట్టుగానే ఉంచండి. “ఇది స్థానిక నెట్వర్క్ మాత్రమే” అనేది ప్రామాణీకరణ పద్ధతి కాదు, మార్గం చిన్నదని కీ తనిఖీని దాటవేసే నిర్వహణ ఛానెల్ దుర్వినియోగం కోసం ఎదురుచూస్తున్న ఛానెల్. DHCP రిజర్వేషన్ లేదా స్థిర చిరునామా లక్ష్యాన్ని అంచనా వేయగలిగేలా చేస్తుంది, దాన్ని సర్వర్ యొక్క పబ్లిక్ గుర్తింపుగా మార్చకుండా.

LAN మార్గాన్ని సొరంగం వెలుపల ఉంచండి

192.168.10.0/24 లో చిరునామా ఉన్న హోస్ట్కు ఆ ప్రిఫిక్స్ కోసం కనెక్ట్ అయిన మార్గం ఉంటుంది, అదే పట్టికలో మరింత నిర్దిష్టమైన మార్గం VPN యొక్క డిఫాల్ట్ను ఓడిస్తుంది. అందుకే సొరంగం పైకి వచ్చినప్పుడు స్థానిక SSH తరచుగా తనంతట తానే పని చేస్తూనే ఉంటుంది. ఊహించకుండా దాన్ని ధృవీకరించండి:ip route get 192.168.10.50 కెర్నల్ ఉపయోగించే ఇంటర్ఫేస్ మరియు మూల చిరునామాను పేర్కొంటుంది, మరియు సమాధానం సొరంగం కాదు, LAN పరికరం ఉండాలి. నిర్వాహకుడి మెషీన్ నుండి కూడా తనిఖీని పునరావృతం చేయండి, ఎందుకంటే ప్యాకెట్లు చేరుతాయో లేదో దాని స్వంత పట్టిక నిర్ణయిస్తుంది. ఒకే తీగపై ఉన్న రెండు హోస్ట్లు ఏ దిశ చేరుకోగలదనే దానిపై ఏకీభవించకపోవచ్చు.

ఊహ రెండు చోట్ల విరిగిపోతుంది. విధాన-ఆధారిత రౌటింగ్ నియమం ప్రధాన పట్టికను చూసే ముందు డిఫాల్ట్ సొరంగం వైపు చూపే పట్టికలోకి ట్రాఫిక్ను పంపవచ్చు. లాక్డౌన్ లేదా kill switch లక్షణం ఉన్న VPN క్లయింట్ సొరంగంలోకి ప్రవేశించని ట్రాఫిక్ను కూడా నిరోధించవచ్చు, రౌటింగ్ పట్టిక ఏం చెప్పినా.

రౌట్ చేయబడిన నిర్వహణ VLAN లు మరో సందర్భం. నిర్వాహకుడు స్థానిక రౌటర్ వెనుక 192.168.50.0/24 లో కూర్చుంటే, సర్వర్కు ఆ ప్రిఫిక్స్ కోసం 192.168.10.1 ద్వారా స్పష్టమైన మార్గం అవసరం, ఆ మార్గం మళ్లీ కనెక్ట్ అవ్వడాన్ని తట్టుకోవాలి. మినహాయింపును నిర్వహణ ప్రిఫిక్స్కే పరిమితం చేయండి; ప్రైవేట్ పరిధులకు విస్తృత మినహాయింపు సొరంగం యొక్క ఉద్దేశాన్ని నాశనం చేస్తుంది.

ఫైర్వాల్ మినహాయింపును నియమమంత సన్నగా చేయండి

హోస్ట్ ఫైర్వాల్ నడుపుతుంటే, SSH ను నిర్వహణ మూలం నుండి మాత్రమే మరియు LAN ఇంటర్ఫేస్లో మాత్రమే అనుమతించండి. 22 పోర్టును ఎక్కడి నుండైనా అనుమతించే నియమం అవసరం కంటే విస్తృతం, సమీక్షలో సమర్థించడం కష్టం. nftables హోస్ట్లో నియమం ఇంటర్ఫేస్ మరియు మూలం సరిపోలిన ఇన్పుట్ చైన్లో ఉంటుంది; iptables హోస్ట్లో సమానమైనది-i మరియు-s పై రెండు సరిపోలికల జత. నియమంపై అది సేవ చేసే నిర్వాహక బృందాన్ని వ్యాఖ్యానించండి, తద్వారా తదుపరి ఆడిట్ 22 పోర్ట్ ఎందుకు తెరిచి ఉందో ఊహించాల్సిన అవసరం లేదు.

VPN క్లయింట్ యొక్క స్వంత ఫిల్టర్ను కూడా తనిఖీ చేయండి. కొన్ని క్లయింట్లు రూపకల్పన ప్రకారం స్థానిక ట్రాఫిక్ను వదిలివేసే నియమాలను ఇన్స్టాల్ చేస్తాయి, క్లయింట్ స్థాయి డ్రాప్పై సరైన ఫైర్వాల్ నియమం ఏమీ మార్చదు. హోస్ట్ ఫైర్వాల్ను సవరించే ముందు క్లయింట్ కాన్ఫిగరేషన్ను చదవండి, ఎందుకంటే వరుసగా రెండు ఫిల్టర్లు ఏదైనా పోలి ఉండని వైఫల్యాన్ని ఉత్పత్తి చేస్తాయి.

రెండు స్థితులను పరీక్షించండి

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

తర్వాత SSH సెషన్ తెరిచి ఉన్నప్పుడు సొరంగాన్ని మళ్లీ ప్రారంభించండి. నిలిచిన సెషన్ రౌటింగ్ స్థిరంగా ఉందని నిరూపిస్తుంది; పడిపోయే సెషన్ క్లయింట్ మళ్లీ కనెక్ట్ అయ్యేటప్పుడు మార్గాలు లేదా ఫిల్టర్లను తిరిగి రాస్తోందని చెబుతుంది, దాన్ని సంఘటన తర్వాత కాదు, ముందే తెలుసుకోవడం మంచిది.

మీరు పరీక్షించిన మూల చిరునామాను నమోదు చేయండి, ఎందుకంటే 192.168.10.50 కోసం రాసిన నియమం నిర్వాహకుడి ల్యాప్టాప్ మరో సబ్నెట్కు మారినప్పుడు నిశ్శబ్దంగా విఫలమవుతుంది.

పునరుద్ధరణ మార్గాన్ని runbook లో రాయండి

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

పత్రంలో రెండు పాత్రలను వేరుగా ఉంచండి: దగ్గరలో ఉన్న నిర్వాహకుడికి స్థానిక SSH, మరియు అప్లికేషన్ ట్రాఫిక్ కోసం బయటకు వెళ్లే సొరంగం. ఆ పాత్రలు రాయబడిన తర్వాత, వాటిలో ఏదైనా భవిష్యత్ మార్పును తనిఖీ చేయడానికి స్పష్టమైన స్థలం ఉంటుంది, తదుపరి వ్యక్తి VPN ఉన్న సర్వర్ ఇప్పటికీ తన LAN చిరునామాలో ఎందుకు స్పందిస్తుందో మళ్లీ కనుగొనాల్సిన అవసరం లేదు.