ఒక క్లౌడ్ సేవ కోసం స్వంత TLS, SSH ఫార్వర్డ్ లేదా VPN

రెండు క్లౌడ్ మెషీన్ల మధ్య ఏదైనా ఎన్‌క్రిప్ట్ చేయాలా అనేది అరుదుగా ప్రశ్న; మీరు ఏ ఇంటర్‌ఫేస్‌ను ఎన్‌క్రిప్ట్ చేస్తున్నారు మరియు ఎవరు ఎవరి గుర్తింపును తనిఖీ చేస్తున్నారు అనేది ప్రశ్న. నేను ఈ సంభాషణలను నెట్‌వర్క్ రేఖాచిత్రం నుండి కాదు, సేవ నుండి ప్రారంభిస్తాను, ఎందుకంటే సేవకు ఏమి కావాలో ఇప్పటికే తెలుసు. మూడు సరిహద్దులు చాలా సందర్భాలను కవర్ చేస్తాయి: అప్లికేషన్ స్వంత TLS, SSH ద్వారా ఫార్వర్డ్ చేయబడిన ఒక TCP పోర్ట్, మరియు ప్రతి పాల్గొనేవారికి చిరునామా ఇచ్చే రూటెడ్ ఓవర్‌లే. అవి బలం ప్రకారం కాదు, సమస్యలో ఎంత భాగాన్ని కవర్ చేస్తాయో అనే ప్రకారం క్రమబద్ధీకరించబడతాయి.

నెట్‌వర్క్ నుండి కాదు, సేవ నుండి ప్రారంభించండి

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

8443 పోర్ట్‌లో ఇప్పటికే HTTPS అందించే చిన్న అంతర్గత API తీసుకోండి, api.internal.example కోసం సర్టిఫికేట్‌తో. హోస్ట్‌లో ss -ltnp అది ఏదానికి బంధించబడిందో చూపిస్తుంది, మరియు openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example సర్టిఫికేట్ క్లయింట్ నిజంగా ఉపయోగించే పేరుకు చెల్లుబాటు అవుతుందో లేదో చూపిస్తుంది. రెండూ ఆరోగ్యంగా ఉంటే, సేవ తన స్వంత ప్రవాహాన్ని రక్షించుకోగలదు మరియు చేరుకోగల సామర్థ్యం మాత్రమే మిగిలి ఉంటుంది. ఇది నెట్‌వర్క్ నిర్మించడం కంటే చాలా చిన్న సమస్య.

దశ 1: సేవ తనను తాను రక్షించుకుంటుందా?

ఇది సరిపోయినప్పుడు ఎంచుకోవాల్సిన ఎంపిక, మరియు బృందాలు ఊహించిన దానికంటే ఎక్కువసార్లు సరిపోతుంది. సేవ యొక్క ఎన్‌క్రిప్షన్ క్లయింట్ మరియు సర్వర్ మధ్య మొత్తం మార్గాన్ని, మధ్యలో ఉన్న ప్రతి హాప్‌తో సహా కవర్ చేస్తుంది, దాన్ని మధ్య చుట్టూ ఉన్న ఏ సొరంగం మెరుగుపరచదు. క్లయింట్ డిఫాల్ట్ స్టోర్‌లో యాదృచ్ఛికంగా ఉన్నదానిపై ఆధారపడకుండా ఆశించిన పేరు మరియు విశ్వాసాన్ని స్పష్టంగా సెట్ చేయండి.

ఎన్‌క్రిప్షన్ మరియు చేరుకోగల సామర్థ్యం వేర్వేరు నియంత్రణలుగా ఉంటాయి, మరియు వాటిని విలీనం చేయడమే ఈ ఎంపిక తప్పు అయ్యే ప్రదేశం. అపరిమిత పబ్లిక్ లిజనర్‌పై TLS సేవ ఇప్పటికీ ఎవరి నుండైనా కనెక్షన్ ప్రయత్నాలను అంగీకరిస్తుంది, కాబట్టి పేలోడ్ రక్షించబడిందనే వాస్తవం నుండి స్వతంత్రంగా లిజనర్ మరియు నెట్‌వర్క్ నియమాలను నిర్వచించాలి. తర్వాత డిపెండెన్సీలను తనిఖీ చేయండి, ఎందుకంటే TLS పైన API డిస్కవరీ ఎండ్‌పాయింట్, అడ్మిన్ పోర్ట్ లేదా పక్కన ఉన్న బల్క్ ట్రాన్స్‌ఫర్ ఛానెల్ గురించి ఏమీ చెప్పదు. వాటిలో ప్రతిదానికి దాని స్వంత సమాధానం అవసరం, మరియు ఒక అసురక్షిత సోదరుడు మొత్తం సరిహద్దును కల్పనగా మార్చడానికి సరిపోతుంది.

దశ 2: ఒక TCP పోర్టే మొత్తం అవసరమా?

అవసరం నిజంగా ఒక TCP పోర్ట్ అయితే, ఫార్వర్డ్ పనిచేసే అతి చిన్న విషయం. SSH స్థానిక ఫార్వర్డ్ ఆ పోర్ట్‌ను ఇప్పటికే ఉన్న ప్రామాణీకరించిన కనెక్షన్ ద్వారా తీసుకువెళుతుంది.

ఆకారం ssh -N -L 8443:127.0.0.1:8443 [email protected], మరియు ముఖ్యమైన వివరం లక్ష్య చిరునామా: 127.0.0.1 దూరపు వైపు పరిష్కరించబడుతుంది, కాబట్టి సేవకు కనెక్షన్ మీ ల్యాప్‌టాప్ నుండి కాదు, బాస్టియన్ నుండి తెరవబడుతుంది. స్థానిక లిజనర్‌ను -L 127.0.0.1:8443:... గా సన్నగా బంధించండి, ప్రమాదవశాత్తు సేవను మీ స్వంత స్థానిక నెట్‌వర్క్‌కు ప్రచురించకుండా. సర్వర్ వైపు, క్లయింట్ మంచి ప్రవర్తనపై నమ్మకం పెట్టుకోవడం బదులు ఖాతా ఏమి ఫార్వర్డ్ చేయగలదో పరిమితం చేయండి. PermitOpen, AllowTcpForwarding local మరియు GatewayPorts no డిఫాల్ట్ — సాధారణ రిలేను నిర్దిష్ట ఛానెల్‌గా మార్చే మూడు సెట్టింగ్‌లు.

ఒప్పందం రెండు దిశలలో సన్నగా ఉంటుంది. SSH తన స్వంత ఛానెల్‌ను రక్షిస్తుంది, మరియు బాస్టియన్ నుండి మరొక అప్లికేషన్‌కు తదుపరి హాప్‌కు దాని స్వంత రక్షణ అవసరం. బాస్టియన్ loopback పై మాత్రమే వినే సేవ యొక్క ఎక్స్‌పోజర్ మరొక నెట్‌వర్క్ ద్వారా చేరుకునే దాని నుండి పూర్తిగా భిన్నం, మరియు ఫార్వర్డ్ దాన్ని మార్చదు. సొరంగాన్ని వాటి ప్రత్యామ్నాయంగా పరిగణించకుండా అప్లికేషన్ ప్రామాణీకరణ మరియు TLS తనిఖీలను ఉంచండి.

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

దశ 3: రూటింగ్ నిజమైన అవసరమా?

ఆ జాబితా అతి చిన్న ఎంపిక యొక్క నిజాయితీ ఖర్చు, అందుకే బృందాలు చివరికి మరచిపోయిన కొన్ని నేపథ్య ఆదేశాలను నిర్వహించబడే దానితో భర్తీ చేస్తాయి. భర్తీ స్వయంచాలకంగా VPN కాదు. అవసరం ఇప్పటికీ ఒక TCP పోర్ట్ అయితే, డాక్యుమెంట్ చేయబడిన యజమానితో పర్యవేక్షణ ఫార్వర్డ్ ఓవర్‌లే కంటే చవకగా నడుస్తుంది మరియు మీరు చూడగల మార్గాల్లో విఫలమవుతుంది. చక్కదనాన్ని కొలవడానికి ముందు కార్యాచరణ యాజమాన్యాన్ని కొలవండి.

రూటింగ్ అవసరమైనప్పుడు రూటింగ్ సరైన సమాధానం అవుతుంది. సాధారణ IP కనెక్టివిటీ అవసరమైన అనేక అప్లికేషన్‌లు, TCP ఫార్వర్డ్ తీసుకువెళ్లలేని ప్రోటోకాల్‌లు, లేదా హోస్ట్‌ల మధ్య కదిలే సేవలు — అన్నీ ఒకే దిశను చూపిస్తాయి.

ఓవర్‌లే పాల్గొనేవారికి చిరునామా మరియు మార్గాన్ని ఇస్తుంది, తర్వాత నిజమైన పని ప్రారంభమవుతుంది: అతివ్యాప్తి చెందని పరిధులు, మార్గ యాజమాన్యం, DNS, నమోదు, రద్దు మరియు సహచరుడు అదృశ్యమైనప్పుడు ఏమి జరుగుతుంది. వాటిలో ఏదీ చిరునామాతో రాదు. ఓవర్‌లేలోకి అంగీకరించబడిన సహచరుడు కూడా గమ్యస్థానంలోని ప్రతి కార్యకలాపానికి స్వయంచాలకంగా అధికారం పొందలేదు, కాబట్టి సేవా-స్థాయి ప్రామాణీకరణ కొనసాగుతుంది.

తర్వాత మీకు ఉన్నది

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

ఈ ప్రయాణం ప్రారంభమైన చోటే, సేవ వద్ద ముగుస్తుంది. నిజమైన ట్రాఫిక్‌ను కవర్ చేసి, మీరు ధృవీకరించాలనుకున్న సహచరులను ధృవీకరించే సరిహద్దును ఎంచుకోండి, తర్వాత యాక్సెస్ ఎలా నవీకరించబడుతుంది, పర్యవేక్షించబడుతుంది మరియు తొలగించబడుతుంది అని రాయండి. OpenSSH సూచన సన్నని ఒప్పందాన్ని వాగ్దానం చేయడానికి ముందు ఫార్వర్డింగ్ ఎంపికలను నిర్ధారించే స్థలం. తొలగింపు దశను ఒక వాక్యంలో వివరించలేకపోతే, సరిహద్దు సమస్య కంటే పెద్దది.