NAT వెనుక SoftEther: నేరుగా ట్రావర్సల్ లేదా VPN Azure రిలే?

మీ SoftEther సర్వర్ మీరు మార్చలేని ప్రొవైడర్ రౌటర్ వెనుక ఉంది, మరియు క్లయింట్లు ఇంకా కనెక్ట్ అవుతున్నాయి, కాబట్టి రిలే అన్నింటినీ మోస్తుందని మీరు ఊహిస్తారు. అది నిజమా అనేది ఏ యంత్రాంగం పని చేసిందనే దానిపై ఆధారపడి ఉంటుంది: DNS పేరు, సమన్వయ UDP మార్గం లేదా రిలేకు బయటకు వెళ్లే సొరంగం. మూడూ కనెక్ట్ అయిన క్లయింట్ను ఇవ్వగలవు, మరియు అవి వేర్వేరు పరిస్థితుల్లో విఫలమవుతాయి. వినియోగదారులు లేదా హబ్లను తాకే ముందు మీరు ఏ మార్గాన్ని కొంటున్నారో నిర్ణయించుకోండి.

మూడు యంత్రాంగాలు, మూడు వేర్వేరు వాగ్దానాలు

డైనమిక్ DNS అంటే నామకరణం. మారుతున్న చిరునామా వైపు హోస్ట్ పేరును ఉంచడం ద్వారా ప్రజలు సంఖ్యను వెంబడించడం ఆపేస్తారు, మరియు అది వేరే ఏమీ చేయదు. స్థానిక NAT ట్రావర్సల్ అంటే సమన్వయం: రెండు SoftEther ముగింపు బిందువులు సమాచారాన్ని మార్పిడి చేసుకుని, వాటి మధ్య ఉన్న అనువాద పరికరాల ద్వారా ఉపయోగించదగిన UDP మార్గాన్ని తెరవడానికి ప్రయత్నిస్తాయి. VPN Azure ఒక రిలే: సర్వర్ సేవకు బయటకు డయల్ చేస్తుంది, మరియు క్లయింట్లు రిలే మౌలిక సదుపాయంలోని హోస్ట్ పేరు ద్వారా వస్తారు.

మూడూ ఒకదానికొకటి పూరకాలు, ఒకే లక్షణం యొక్క సంస్కరణలు కావు. ఒక అమరిక నామకరణాన్ని ఉపయోగించవచ్చు, కానీ దాని కనెక్షన్ నిజానికి ట్రావర్సల్ లేదా రిలేపై ఆధారపడి ఉంటుంది.

క్లయింట్ మరియు నెట్వర్క్ నుండి నిర్ణయించుకోండి

ఎంపిక క్లయింట్ నుండి ప్రారంభమవుతుంది, ఎందుకంటే ట్రావర్సల్ స్థానిక SoftEther కనెక్షన్ యంత్రాంగంలో మాత్రమే ఉంటుంది. అదే సర్వర్పై OpenVPN, L2TP/IPsec మరియు SSTP శ్రోతలు దానిని వారసత్వంగా పొందవు, ఒక హోస్ట్ను పంచుకున్నా. వినియోగదారు ఏమి నడుపుతారు, తర్వాత నెట్వర్క్ ఏమి అనుమతిస్తుందో చూడండి. TCP 443 మాత్రమే అనుమతించే కార్పొరేట్ నెట్వర్క్ ఆ పోర్టులోని రిలే వైపు మీను నెట్టివేస్తుంది, అయితే ట్రావర్సల్కు అవసరమైన UDP పోర్టులను దాటనిచ్చే నెట్వర్క్ నేరుగా మార్గాన్ని ప్రయత్నించగలదు; రెండింటినీ వాస్తవ ఎగ్రెస్ విధానానికి వ్యతిరేకంగా నిర్ధారించండి.

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

సెషన్ ఏ రవాణాను ఎంచుకుందో నిర్ధారించండి

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

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

SessionList ఏ సెషన్లు కనెక్ట్ అయ్యాయో చూపిస్తుంది, మరియు వాటిలో ఒకదానిపై SessionGet కనెక్షన్ రకాన్ని నివేదిస్తుంది, సెషన్ రిలే ద్వారా వచ్చిందా అనేది కూడా. రిలే మౌలిక సదుపాయానికి పరిష్కరించబడే రికార్డు సెషన్ మూడవ పక్షం గుండా వెళుతుందని చెబుతుంది, దాన్ని పరీక్షలో ఆ మార్గాన్ని నిరోధించడం ద్వారా నిర్ధారించవచ్చు. స్థానిక క్లయింట్తో, UDP త్వరణం డేటా మార్గాన్ని నియంత్రణ మార్గం నుండి దూరం చేయగలదు, కాబట్టి ఒక పరిశీలన మొత్తం సెషన్ను వివరించదు. చిరునామా మారిన తర్వాత పాతబడిన డైనమిక్ DNS పేరు, మరియు బ్యాకెండ్ మార్గం లేకున్నా సమాధానం ఇచ్చే రిలే, విడివిడిగా పరీక్షించదగిన రెండు వైఫల్య పద్ధతులు. డిజైన్ ఉద్దేశించినది కాదు, మీరు కొలిచినది రాయండి.

ఎంచుకున్న మార్గం దేనిపై ఆధారపడి ఉందో ప్రణాళిక వేయండి

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

హోస్ట్ పేరు, ప్రోటోకాల్, లక్షణ సెట్టింగ్లు మరియు గమనించిన రవాణాను రాయండి. ఆ నాలుగు భాగాల రికార్డే తదుపరి వ్యక్తి పనిచేసే కనెక్షన్ను పునఃసృష్టించడానికి అనుమతిస్తుంది.