VPN కోసం క్లౌడ్ భద్రతా సమూహం: వినేదాన్ని తెరవండి, అన్నీ కాదు

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

నియమం ముందు ప్రోటోకాల్ పేరు చెప్పండి

నియమం అంటే ప్రోటోకాల్, పోర్ట్ పరిధి మరియు మూలం. WireGuard UDP పై వింటుంది, సాధారణంగా 51820. OpenVPN కాన్ఫిగరేషన్ ప్రకారం సాధారణంగా UDP లేదా TCP 1194. IPsec కు UDP 500 మరియు 4500 పై IKE మార్పిడి మరియు ESP ప్రోటోకాల్ కూడా అవసరం, అది పోర్ట్ కాదు ప్రోటోకాల్ సంఖ్య. మిగతా నియమాలు TCP కాబట్టి TCP అని ఊహించడం సరిగ్గా కనిపించే కానీ ఏదీ సరిపోని నియమాన్ని ఇస్తుంది.

వినేదాన్ని నడుస్తున్న సేవ నుండి చదవండి, ట్యుటోరియల్ నుండి కాదు. ఒక చిరునామాకు బంధించబడిన డీమన్ మరో చిరునామాకు వచ్చే ట్రాఫిక్ అంగీకరించదు.

మూలాన్ని మొత్తం ఇంటర్నెట్‌కు బదులు డిజైన్ అనుమతించే క్లయింట్ పరిధికి పరిమితం చేయండి.

భద్రతా సమూహాలు స్టేట్‌ఫుల్; సబ్‌నెట్ ACL కాదు

భద్రతా సమూహాలు స్టేట్‌ఫుల్ మరియు అనుమతి మాత్రమే: అనుమతించిన ఇన్‌బౌండ్ ప్రవాహం దాని ప్రతిస్పందనలను స్వయంచాలకంగా పొందుతుంది, మరియు ఆలోచించవలసిన నిరాకరణ నియమం లేదు. సబ్‌నెట్ ACL స్టేట్‌లెస్ మరియు రెండు దిశలలో మూల్యాంకనం చేయబడతాయి, కాబట్టి సంబంధిత అవుట్‌బౌండ్ తాత్కాలిక పరిధి లేకుండా ఇన్‌బౌండ్ అనుమతి ఇప్పటికీ విఫలమవుతుంది. ఈ భేదమే కన్సోల్‌లో సరిగ్గా కనిపించే అనేక నియమాలను వివరిస్తుంది.

నడుస్తున్న ఎండ్‌పాయింట్‌కు ఏ విధానం జోడింపబడిందో కూడా నిర్ధారించండి, ఎందుకంటే ఒక ఇన్‌స్టాన్స్‌లో ఒకటి కంటే ఎక్కువ సమూహాలు ఉండవచ్చు మరియు జోడించని సమూహంలోని నియమం ఏమీ మార్చదు.

ప్రభావవంతమైన విధానం జోడించిన వాటి యూనియన్, మీరు సవరించిన ఫైల్ కాదు.

హోస్ట్ ఫైర్‌వాల్ వేరే హద్దు

క్లౌడ్ విధానం ట్రాఫిక్‌ను నెట్‌వర్క్ ఇంటర్‌ఫేస్ వరకు అనుమతిస్తుంది, తర్వాత ఆపరేటింగ్ సిస్టమ్ డీమన్ దానిని చూస్తుందో లేదో నిర్ణయిస్తుంది. డిఫాల్ట్ నిరాకరణ విధానంతో హోస్ట్ ఫైర్‌వాల్ భద్రతా సమూహం అనుమతించిన ప్యాకెట్‌ను పడేస్తుంది, మరియు క్లౌడ్ కన్సోల్ ఎటువంటి నిరాకరణను చూపదు ఎందుకంటే దానికి ఎప్పుడూ అభిప్రాయం లేదు. ప్యాకెట్ వాటిని ఎదుర్కొనే క్రమంలో రెండింటినీ తనిఖీ చేయండి.

హోస్ట్ పంపిణీ ఫైర్‌వాల్ ముందు భాగాన్ని ఉపయోగిస్తే, ప్రొఫైల్ పేరు కాదు, ప్రాథమిక నియమాలను నిర్ధారించండి, ఎందుకంటే ప్రొఫైల్ యాక్టివ్‌గా ఉన్నప్పుడు పోర్ట్ మూసి ఉండవచ్చు.

ఇంటర్‌ఫేస్‌లో క్యాప్చర్ ఏ హద్దు ప్యాకెట్‌ను పడేసిందో చెబుతుంది.

వినేదాన్ని అనుమతించడం క్లయింట్లను రూట్ చేయడం కాదు

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

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

రూటింగ్‌ను దాని స్వంత ధృవీకరణతో వేరే మార్పుగా సరిచేయండి, మరియు ఫార్వర్డ్ చేసే గేట్‌వేకు గమ్యాన్ని అనుమతించే ఎగ్రెస్ విధానం కూడా అవసరమని గుర్తించండి.

తిరిగి వెళ్లే మార్గం ఉంచండి, తర్వాత నియమాన్ని సన్నగా చేయండి

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

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

జోడింపును కూడా డాక్యుమెంట్ చేయండి, లేకపోతే ప్రత్యామ్నాయ ఇంటర్‌ఫేస్ విధానాన్ని నిశ్శబ్దంగా కోల్పోతుంది.