పోర్ట్ ఫార్వర్డింగ్ లేకుండా NAT వెనుక పని స్థానాన్ని చేరుకోవడం
ఇన్బౌండ్ పోర్ట్ లేని పని స్థానం కూడా హబ్, రిలే లేదా యాప్ బ్రోకర్ ద్వారా చేరుకోగలము. ఒకటి ఎంచుకునే ముందు ప్రతి డిజైన్ ఏమి హామీ ఇస్తుందో పోల్చండి.
క్యారియర్ NAT మరియు లాక్ చేయబడిన కార్యాలయ రౌటర్ వెనుక ఉన్న రెండు ముగింపు పాయింట్లు ఫార్వర్డ్ చేయడానికి ఏ ఇన్బౌండ్ పోర్టును వదలవు, మరియు ప్రతిస్పందన ఏమైనా ఒకటి అడగడమే. మంచి ప్రశ్న ఏమిటంటే ఏ వైపు బయటకు డయల్ చేయగలదు మరియు ఏ చేరుకోగల సేవకు ట్రాఫిక్ మోయడానికి అనుమతి ఉంది. నాలుగు డిజైన్లు ఈ ప్రశ్నకు వేర్వేరుగా సమాధానం ఇస్తాయి, మార్గం నిరోధించబడినప్పుడు వేర్వేరు విధాలుగా విఫలమవుతాయి. వాటి మధ్య ఎంపిక ప్రోటోకాల్ పేర్ల పోలిక కాదు, హామీల పోలిక.
నాలుగు డిజైన్లు, నాలుగు వేర్వేరు వాగ్దానాలు
క్రింది పట్టిక చిన్న వెర్షన్. మధ్య నిలువు వరుసను మీరు పరీక్షించగల వాగ్దానంగా, కుడి నిలువు వరుసను ఎవరూ ఇవ్వని వాగ్దానంగా చదవండి.
| Design | Who initiates | Promise you get | Promise you do not get |
|---|---|---|---|
| Routed VPN hub | Both ends, outbound to the hub | A routed path to permitted prefixes | Access to services no policy allows |
| Peer traversal with ICE | Both peers to a rendezvous service | A path tested between the two peers | A direct path through every NAT |
| TURN relay | Client outbound to a relay | Transport that survives symmetric NAT | Peer discovery or a usable directory |
| Application broker | Workstation outbound to a broker | One audited application session | Subnet-wide reachability |
ఏ వరుస వర్తిస్తుంది అనేది ఇష్టంపై కాదు, పనిపై ఆధారపడి ఉంటుంది. ఒక రిమోట్ డెస్క్టాప్ సెషన్, ఒక పరిపాలనా షెల్ మరియు మొత్తం ప్రైవేట్ సబ్నెట్కు యాక్సెస్ — ఇవి ఒకే ప్రవేశ బిందువు అవసరం లేని మూడు అవసరాలు, అవి యాదృచ్ఛికంగా ఒకే మెషీన్కు సంబంధించినా.
హబ్ ఎవరు బయటకు డయల్ చేస్తారో మారుస్తుంది, ఏమి అనుమతించబడిందో కాదు
రూట్ చేసిన హబ్ డిజైన్లో రిమోట్ ల్యాప్టాప్ మరియు పని స్థానం, లేదా దాని ముందు ఉన్న సైట్ గేట్వే, రెండూ చేరుకోగల సేవకు బయటకు వెళ్లే సొరంగాన్ని తెరుస్తాయి. పని స్థానం రౌటర్లో ఏదీ అడగని కనెక్షన్ను అంగీకరించదు, అందుకే ఈ డిజైన్ NAT నుండి తప్పించుకుంటుంది మరియు సైట్కు స్థిర చిరునామా లేకపోయినా పనిచేస్తుంది. తర్వాత హబ్ తన స్వంత విధానం ప్రకారం రెండు లోపలి చిరునామాల మధ్య ట్రాఫిక్ను రూట్ చేస్తుంది.
ధర ఏమిటంటే హబ్ ఉండాలి, రెండు వైపుల నుండి చేరుకోగలిగి ఉండాలి మరియు ఎవరైనా నిర్వహించాలి. బయటకు వెళ్లే ఫిల్టరింగ్ రవాణాను అనుమతించాలి, దాన్ని నిరోధించే నెట్వర్క్ పోర్ట్ ఫార్వర్డింగ్ అవసరం లేకపోయినా డిజైన్ను ఓడిస్తుంది.
సూక్ష్మ భాగం ఏమిటంటే చేరుకోగల సామర్థ్యం మరియు అధికారం వేర్వేరు ప్రదేశాలలో తీసుకునే వేర్వేరు నిర్ణయాలు. ప్రిఫిక్స్కు వెళ్లే మార్గం పని స్థానంలో ఏ సేవను గుర్తింపు ఉపయోగించవచ్చో ఏమీ చెప్పదు, సొరంగాన్ని అనుమతించే ఫైర్వాల్ నియమం ఖాతా లాగిన్ అవ్వగలదా అని ఏమీ చెప్పదు. రెండింటినీ కాన్ఫిగర్ చేయండి, రెండింటినీ పరీక్షించండి, మరియు అధికార నిర్ణయాన్ని రూటింగ్ పట్టిక దగ్గర కాదు, వనరును కలిగి ఉన్న వ్యవస్థ దగ్గర ఉంచండి.
రెండు స్టాక్లు దాన్ని అమలు చేసినప్పుడే ట్రావర్సల్ పనిచేస్తుంది
సమాన ముగింపుల మధ్య ట్రావర్సల్ ఒక నిర్దిష్ట వ్యవస్థ సామర్థ్యం, VPNను మెరుగుపరిచే సెట్టింగ్ కాదు. Interactive Connectivity Establishment అనేక అభ్యర్థి చిరునామాలను సేకరించి ఒకటి పనిచేసే వరకు జంటలను పరీక్షిస్తుంది: స్థానిక ఇంటర్ఫేస్లలో హోస్ట్ అభ్యర్థులు, NAT బహిర్గతం చేసే దాని నుండి నిర్మించిన సర్వర్-ప్రతిబింబ అభ్యర్థులు, మరియు రిలేపై కేటాయించిన రిలే అభ్యర్థులు. కేవలం ప్రైవేట్ చిరునామా మార్గం కాదు, ఎందుకంటే రెండో వైపు అక్కడికి రూట్ చేయలేదు.
రిలే కేసును తిరస్కరించే ముందు అర్థం చేసుకోవడం విలువైనది. RFC 8656 TURNను, క్లయింట్ సర్వర్ను రిలే చేసిన రవాణా చిరునామా కోసం అడిగే మరియు సర్వర్ ఆ క్లయింట్ మరియు దాని సమాన ముగింపుల మధ్య ట్రాఫిక్ను పంపే ప్రోటోకాల్గా వివరిస్తుంది. కాబట్టి డేటాను రిలే మోస్తుంది, ఇది ముగింపులు కలవడానికి మాత్రమే సహాయపడే డైరెక్టరీ నుండి ప్రాథమికంగా భిన్నం. రిలే చిరునామాను రెండో వైపుతో మార్పిడి చేయడం యాప్ చేయవలసిన సమన్వయ దశ.
మీరు వాగ్దానం చేయలేనిది నేరుగా మార్గం. సమరూప NAT మరియు కొన్ని ఎంటర్ప్రైజ్ ఫైర్వాల్లు రంధ్రం తవ్వడాన్ని ఓడిస్తాయి, అలా జరిగినప్పుడు వ్యవస్థ రిలేకు తిరిగి వెళ్తుంది లేదా విఫలమవుతుంది. అనువదించిన రెండు ముగింపులు ఎప్పటికీ మాట్లాడలేవని కూడా మీరు నిర్ధారించలేరు; రిలే బ్యాకప్ ఉన్న మద్దతు స్టాక్ ఉనికిలో ఉండటానికి కారణం అవి తరచుగా మాట్లాడగలవు. లభ్యత ముఖ్యమా నేరుగా ఉండటం ముఖ్యమా అని నిర్ణయించుకోండి, తర్వాత అనుకూల పరిస్థితిని ఊహించడం బదులు మోహరింపు నిజంగా ఏ మార్గాన్ని ఎంచుకుందో ధృవీకరించండి.
బ్రోకర్ నెట్వర్క్ కంటే సన్నగా ఉంటుంది
అవసరం ఒక యాప్ అయినప్పుడు, యాప్ బ్రోకర్ లేదా పని స్థానం ప్రారంభించిన రివర్స్ కనెక్షన్ అతి చిన్న సమాధానం కావచ్చు. పని స్థానం బయటకు బ్రోకర్కు డయల్ చేస్తుంది, బ్రోకర్ రిమోట్ వినియోగదారుని ప్రామాణీకరిస్తుంది, ఆ యాప్ సెషన్ మాత్రమే మోయబడుతుంది. పని స్థానం సబ్నెట్కు ఎలాంటి మార్గం సృష్టించబడదు, కాబట్టి రిమోట్ సెషన్ రాజీ పక్కన ఉన్న ప్రతి పరికరానికి మార్గాన్ని వారసత్వంగా పొందదు.
ఈ సన్నదనానికి ధర ఉంది: ప్రతి అదనపు యాప్కు దాని స్వంత ఇంటిగ్రేషన్ అవసరం, మరియు యాప్ స్థానిక నెట్వర్క్ గురించి ఊహించే ఏదైనా, ఉదాహరణకు సమీప సర్వర్లో తెరిచే ఫైల్ షేరింగ్, చేరుకోలేకపోవచ్చు. బ్రోకర్లు విధానాన్ని మరియు లాగింగ్ను ఒకే చోట కేంద్రీకరిస్తాయి, అది ఆ ప్రదేశం అంతరాయం అయ్యే వరకు ఉపయోగకరం.
నమ్మకపు సరిహద్దులను పోల్చండి, తర్వాత మార్గాన్ని పరీక్షించండి
సొరంగాలను ముగించే హబ్ తాను రూట్ చేసే ట్రాఫిక్ను చదవగలదు. యాప్ చివర నుండి చివర వరకు గుప్తీకరిస్తున్నప్పుడు రిలే స్వతంత్రంగా రక్షించబడిన మార్పిడిని మోయగలదు, బ్రోకర్ సాధారణంగా తాను ప్రదర్శించే సెషన్ను ముగిస్తుంది. రెండూ గుప్తీకరించబడినందున రెండు డిజైన్లు సమానం అని నిర్ణయించే ముందు రక్షణ నిజంగా ఎక్కడ ముగుస్తుందో నిర్ధారించండి.
తర్వాత పని స్థానం బయటకు నిజంగా ఎక్కడికి చేరుతుందో తనిఖీ చేయండి, ఎందుకంటే పైన ఉన్న ప్రతి డిజైన్ దానిపై ఆధారపడి ఉంది. దీన్ని పని స్థానంలో అమలు చేయండి, మీరు ఉపయోగించాలనుకునే హోస్ట్నామ్ను భర్తీ చేయండి.
ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.comఅనుమతించిన గుర్తింపు కింద ఉద్దేశించిన రిమోట్ ఆపరేషన్ విజయవంతమైన తర్వాత, అనుమతి లేని గుర్తింపు తిరస్కరించబడిన తర్వాత, మరియు నేరుగా లేదా రిలే మార్గం అందుబాటులో లేనప్పుడు ప్రవర్తన తెలిసి నమోదు చేయబడిన తర్వాత మాత్రమే డిజైన్ను అంగీకరించండి. తిరిగి కనెక్ట్ అవ్వడం మరియు పని స్థానం యొక్క సాధారణ ప్రారంభ సందర్భాన్ని చేర్చండి, ఎందుకంటే కార్యాలయంలో LAN ద్వారా ప్రారంభమైన సెషన్ రిమోట్ యాక్సెస్ ఆధారపడే ఏదీ పరీక్షించదు.