SoftEther SecureNAT: DHCP మరియు NAT రెండు వేర్వేరు నిర్ణయాలు

SecureNAT రెండు సేవలను ఆన్ చేసే ఒకే చెక్బాక్స్, మరియు దాని గురించి చాలా గందరగోళం ఇక్కడి నుంచే వస్తుంది. వర్చువల్ DHCP సర్వర్ క్లయింట్కు చిరునామా, మాస్క్, గేట్వే మరియు తరచుగా రిజాల్వర్ను ఇస్తుంది. వర్చువల్ NAT సర్వర్ హోస్ట్ సొంత నెట్వర్క్ స్టాక్ను ఉపయోగించి ఆ గేట్వే దాటి ప్యాకెట్లను పంపుతుంది. రెండూ కాన్ఫిగరేషన్లో పక్కపక్కనే ఉంటాయి మరియు స్వతంత్రంగా విఫలమవుతాయి: క్లయింట్కు పరిపూర్ణ లీజ్ ఉండి పనిచేసే మార్గం లేకపోవచ్చు, లేదా పనిచేసే మార్గం ఉండి సెట్టింగ్లు తప్పు రిజాల్వర్ వైపు చూపవచ్చు. వీటిని రెండు నిర్ణయాలుగా తనిఖీ చేయండి, నిర్ధారణ చిన్నదవుతుంది.

ఒక చెక్బాక్స్ వెనుక రెండు సేవలు

వర్చువల్ DHCP వైపు ఒక కాన్ఫిగరేషన్ ప్రశ్నకు సమాధానం ఇస్తుంది: ఈ వర్చువల్ హబ్ లోపల ఈ క్లయింట్ ఏ సెట్టింగ్లను పొందుతుంది. వర్చువల్ NAT వైపు ఒక ఫార్వార్డింగ్ ప్రశ్నకు సమాధానం ఇస్తుంది: క్లయింట్ హబ్ వెలుపలి చిరునామాకు ప్యాకెట్ పంపినప్పుడు సర్వర్ దాన్ని అనువదించి పంపుతుందా. మొదటిది హబ్కు స్థానికం, పై నెట్వర్క్ అవసరం లేదు. రెండవది పూర్తిగా హోస్ట్పై ఆధారపడి ఉంటుంది.

వర్చువల్ హోస్ట్ ఇంటర్ఫేస్ మొదటి నిర్ణయానికి చెందుతుంది, రెండవదానికి కాదు. దాని చిరునామా, తరచుగా డిఫాల్ట్గా 192.168.30.1 లాంటిది, DHCP సేవ అందించే గేట్వే. ఇది సర్వర్ యొక్క పబ్లిక్ వినడం చిరునామా కాదు, రెండింటినీ కలపడం ఆ నెట్వర్క్లో లేని మెషీన్ వైపు గురిపెట్టిన ఫైర్వాల్ నియమాలను మరియు క్లయింట్ సెట్టింగ్లను సృష్టిస్తుంది.

నిర్ణయం 1: చిరునామా ఎవరు ఇస్తారు

వర్చువల్ DHCP ఆన్లో ఉంటే, క్లయింట్లు మీరు కాన్ఫిగర్ చేసిన పూల్లో లీజ్ పొందాలి, గేట్వేగా వర్చువల్ హోస్ట్ ఇంటర్ఫేస్ మరియు రిజాల్వర్గా మీరు ఇచ్చినది. క్లయింట్ స్టేటస్ టెక్స్ట్ కాదు, లీజ్ను తనిఖీ చేయండి, ఎందుకంటే «కనెక్ట్ అయింది» టన్నెల్ను వివరిస్తుంది, చిరునామా కేటాయింపును కాదు:

vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route

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

అతివ్యాప్తి చెందే పూల్స్ కూడా ఇక్కడికి చెందుతాయి. వర్చువల్ DHCP పూల్ హోస్ట్ LAN సబ్నెట్ లేదా మరో హబ్ పూల్తో అతివ్యాప్తి చెందితే, క్లయింట్కు అస్పష్టంగా రూట్ అయ్యే చిరునామా లభిస్తుంది, తర్వాతి ప్రతి పరీక్ష నిర్ణయాత్మకం కాదు.

నిర్ణయం 2: వర్చువల్ గేట్వే దాటి ఎవరు పంపుతారు

వర్చువల్ NAT ఆన్లో ఉన్నప్పుడు, హబ్ నుంచి బయటకు వెళ్లే ట్రాఫిక్ను సర్వర్ అనువదించి హోస్ట్ రూటింగ్ పట్టిక ద్వారా పంపుతుంది. అంటే ఫార్వార్డింగ్ గొలుసు ఇది: క్లయింట్ నుంచి వర్చువల్ గేట్వేకు, వర్చువల్ NAT నుంచి హోస్ట్ స్టాక్కు, హోస్ట్ స్టాక్ నుంచి దాని డిఫాల్ట్ మార్గానికి. ప్రతి లింక్ మిగతావాటిని తాకకుండా విఫలమవుతుంది, వైఫల్య సంకేతాలు భిన్నంగా ఉంటాయి.

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

vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10

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

SecureNAT ఫార్వార్డింగ్ను సర్వర్ ప్రాసెస్ అమలు చేస్తుంది, మీరు బ్రిడ్జ్తో ఉపయోగించే కెర్నల్ ఫార్వార్డింగ్ మార్గం కాదు. ఇది సౌకర్యవంతం మరియు బ్రిడ్జింగ్ కంటే నెమ్మది, మరియు హోస్ట్ సొంత ఫైర్వాల్ నియమాలు మరియు రూటింగ్ నిర్ణయాలు అనువదించిన ట్రాఫిక్పై ఇంకా వర్తిస్తాయని కూడా అర్థం. వర్చువల్ NAT హోస్ట్ విధానాన్ని దాటవేయదు; దాన్ని ఉపయోగిస్తుంది.

హోస్ట్ సొంత మార్గం మూడవ విషయం

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

SecureNAT సర్వర్కు అనుసంధానించిన ప్రతి నెట్వర్క్ను చేరుకునే అధికారం కూడా కాదు. అది తనను చేరుకునే ట్రాఫిక్ను అనువదించి ఫార్వార్డ్ చేస్తుంది; హోస్ట్ ఏమి చేరుకోవచ్చో నిర్ణయించడం ఇంకా హోస్ట్ ఫైర్వాల్ మరియు రూటింగ్ పని, మరియు యాక్సెస్ ఇవ్వడానికి టన్నెల్పై ఆధారపడే డిజైన్ ఎక్కువ ఇవ్వడానికి ఒక చెడు నియమం దూరంలో ఉంది.

చిరునామా కుటుంబాలు తమ సొంత తనిఖీకి అర్హమైనవి. పనిచేసే IPv4 DHCP ఉదాహరణ మీ బిల్డ్లో ప్రతి IPv6 సామర్థ్యం ఉందని నిరూపించదు, కాబట్టి ద్వంద్వ స్టాక్ ప్రవర్తనకు హామీ ఇచ్చే ముందు మీరు నిజంగా నడిపే వెర్షన్ మాన్యువల్ చదవండి. మాన్యువల్లోని SecureNAT విభాగం ప్రస్తుత విడుదలకు వర్చువల్ NAT మరియు DHCP విధులను కవర్ చేస్తుంది.

ప్రతి నిర్ణయాన్ని దాని సొంత పరీక్షతో ధృవీకరించండి

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

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

ఇంకో నిర్ణయం రికార్డులో ఉండాలి, ఈరోజు తీసుకోకపోయినా: SecureNAT మరియు స్థానిక బ్రిడ్జ్ ఒకే హబ్కు వేర్వేరు డిజైన్లు, మరియు రెండూ అవసరమైన హబ్కు వేరే ప్రణాళిక అవసరం. చేతనంగా ఎంచుకోండి, ఎందుకో రాయండి, అప్పుడు తదుపరి వ్యక్తి నడుస్తున్న కాన్ఫిగరేషన్ నుంచి దాన్ని తిరగబడి ఇంజనీరింగ్ చేయాల్సిన అవసరం ఉండదు.