ఒక మద్దతు థ్రెడ్ “సమరూప NAT, ఇక్కడ VPN పని చేయదు” అనే తీర్పుతో ముగుస్తుంది, ఆ తర్వాత క్లయింట్ కారణం లేకుండా మూడుసార్లు మళ్లీ ఇన్స్టాల్ చేయబడుతుంది. ఎవరూ అడగని ప్రశ్నకు సమాధానం ఇస్తుంది కాబట్టి లేబుల్ హాని చేస్తుంది. స్థిర సర్వర్కు బయటకు కనెక్ట్ అయ్యే క్లయింట్ మొదటి ప్యాకెట్ను పంపిన క్షణంలో మ్యాపింగ్ను సృష్టిస్తుంది, మరియు ప్రతిస్పందన దాదాపు ప్రతి నెట్వర్క్ అమలు చేసే నియమాల ప్రకారం తిరిగి రావడానికి అనుమతించబడుతుంది. ఎండ్పాయింట్ ఆధారిత మ్యాపింగ్ నిజంగా సంక్లిష్టం చేసేది ఇద్దరు పీర్లు ఒకే సమయంలో ఒకరినొకరు చేరుకోవడానికి ప్రయత్నించడం, మరియు అది వేరే పరీక్ష.

ఒక లేబుల్ వెనుక రెండు ప్రశ్నలు దాగి ఉన్నాయి

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

రెండవ ప్రశ్న ఏమిటంటే వేర్వేరు నెట్వర్క్ల వెనుక ఉన్న రెండు హోస్ట్లు మధ్యలో సర్వర్ లేకుండా ఉమ్మడి మార్గాన్ని కనుగొని ఒకరికొకరు పంపగలవా. అది ప్రతి నెట్వర్క్ ఆ బాహ్య పోర్ట్లను ఎలా కేటాయిస్తుందనే దానిపై ఆధారపడి ఉంటుంది, మ్యాపింగ్ ప్రవర్తనకు ప్రాముఖ్యత ఉన్నది అక్కడ మాత్రమే.

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

మ్యాపింగ్ మరియు ఫిల్టరింగ్ వేర్వేరు లక్షణాలు

RFC యొక్క పదజాలం విక్రేతలు ఉపయోగించే పేర్ల కంటే ఖచ్చితమైనది, మరియు అది వాదనలను తీర్చడం వల్ల టికెట్లో చేర్చడం విలువైనది. మ్యాపింగ్ అంటే బాహ్య పోర్ట్ ఎలా కేటాయించబడుతుంది. ఫిల్టరింగ్ అంటే ఏ ఇన్బౌండ్ ప్యాకెట్లు దాటడానికి అనుమతించబడతాయి. ఒక నెట్వర్క్ ఒకదానిలో కఠినంగా మరియు మరొకదానిలో ఉదారంగా ఉండవచ్చు, ఆ కలయికే పీర్-టు-పీర్ ప్రోటోకాల్ దాటాల్సిన విషయం.

BehaviourWhat it meansEffect on a direct peer path
Endpoint-independent mappingOne external port for every destinationDiscovery works if the port is advertised
Address-dependent mappingNew port per remote addressWorks only if both sides probe the same pair
Address-and-port-dependentNew port per remote address and portUsually needs a relay

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

ఫిల్టరింగ్కు దాని స్వంత మూడు సందర్భాలు మరియు ప్రతిదానికి దాని స్వంత పేరు ఉన్నాయి. “చిరునామా మరియు పోర్ట్ ఆధారిత ఫిల్టరింగ్” అని ఉద్దేశించినప్పుడు టికెట్లో “సమరూప NAT” అని రాయడం తదుపరి వ్యక్తిని మాన్యువల్ తప్పు అధ్యాయానికి పంపుతుంది. రెండూ పరీక్షలో వేరుగా ప్రవర్తిస్తాయి, కాబట్టి తప్పు కేవలం సైద్ధాంతికం కాదు.

పేరు పెట్టడం బదులు మ్యాపింగ్ను కొలవండి

మీరు నియంత్రించే ఏదైనా UDP సేవ యొక్క సర్వర్ వైపు నుండి కేటాయించిన పోర్ట్ను నేరుగా గమనించవచ్చు. పబ్లిక్ హోస్ట్పై క్యాప్చర్ ప్రారంభించండి, క్లయింట్ నుండి పంపండి, ప్యాకెట్ వచ్చిన మూల పోర్ట్ను చదవండి:

sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820

ఎండ్పాయింట్ వరుస మూడింటిలో అత్యంత ఉపయోగకరం, ఎందుకంటే WireGuard ప్రతి పీర్ నుండి స్వీకరించిన చివరి చిరునామా మరియు పోర్ట్ను నమోదు చేస్తుంది. ఆ పోర్ట్ను క్లయింట్ ఉపయోగిస్తున్నట్టు భావించే పోర్ట్తో పోల్చండి. ఏదైనా అనువాదం జరిగినప్పుడల్లా అవి భిన్నంగా ఉంటాయి, మరియు ముఖ్యమైన ప్రశ్న విలువ స్థిరంగా ఉంటుందా అనేది.

రెండవ గమ్యస్థాన పోర్ట్ లేదా రెండవ సర్వర్ మీద పరిశీలనను పునరావృతం చేసి మళ్లీ పోల్చండి. బాహ్య పోర్ట్ గమ్యం ప్రకారం మారితే, మ్యాపింగ్ చిరునామా మరియు పోర్ట్ ఆధారితం. అది అలాగే ఉంటే, నెట్వర్క్ ఒకే మ్యాపింగ్ను ఇస్తుంది మరియు ఆవిష్కరణకు అవకాశం ఉంది.

STUN ఆధారిత సాధనాలు అదే వర్గీకరణను ఒకే దశలో నివేదిస్తాయి, నెట్వర్క్ పబ్లిక్ STUN సర్వర్కు వెలుపలికి వెళ్లే UDPని అనుమతించినప్పుడు వాటిని ఉపయోగించవచ్చు. అనుమతించనప్పుడు, పైన చెప్పిన క్యాప్చర్ పద్ధతి ఇంకా పని చేస్తుంది, మీరు ఇప్పటికే నియంత్రిస్తున్న హోస్ట్ తప్ప మరేమీ అవసరం లేదు.

వైఫల్యానికి సరిపోయే పరిష్కారాన్ని ఎంచుకోండి

విఫలమయ్యే లక్షణం పీర్-టు-పీర్ అయితే, మద్దతు ఉన్న సమాధానాలు రిలే, రెండు పీర్లు చేరుకోగలిగే కలయిక సేవ, లేదా వేరే టోపాలజీ. TURN సరిగ్గా దీని కోసమే ఉంది, తన సొంత రిలేను తెచ్చే ఉత్పత్తి కొన్ని నెట్వర్క్లు శత్రుత్వంగా ఉంటాయని ఆశిస్తున్నట్టు మీకు చెబుతుంది.

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

పని చేయనిది ఏదో కనెక్ట్ అయ్యే వరకు స్థానిక పోర్ట్ మార్పులను చెల్లాచెదరు చేయడం. క్లయింట్ మూల పోర్ట్ను మార్చడం నెట్వర్క్ మ్యాపింగ్లను ఎలా కేటాయిస్తుందనే దాన్ని మార్చదు. ఐదవ ప్రయత్నంలో యాదృచ్ఛిక విజయం అనేది తప్పుడు పాజిటివ్, నెలల పాటు అది పరిష్కారంగా ఉదహరించబడుతుంది.

తీర్పు కాదు, నిర్మాణాన్ని నమోదు చేయండి

ఉపయోగకరమైన గమనిక ఏ ప్రోటోకాల్, సెషన్ ఏ దిశలో ప్రారంభమవుతుంది, మార్గంలో రిలే ఉందా, తీగపై ఏమి గమనించబడింది అని చెబుతుంది. “సమరూప NAT, పని చేయదు” ఉపయోగించలేనిది, ఎందుకంటే అది ఒకే సమయంలో టన్నెల్ గురించి తప్పు మరియు పీర్ మార్గం గురించి సమాచారం ఇవ్వదు.

మీరు పరీక్షించి ఉంటే కొలిచిన పోర్ట్ స్థిరత్వాన్ని మరియు ఫిల్టరింగ్ ప్రవర్తనను చేర్చండి. ఈ రెండు వాస్తవాలు మొత్తం విచారణను పునరావృతం చేయకుండా కొత్త లక్షణం ఆ నెట్వర్క్లో పని చేస్తుందా అని మరొకరు ఊహించడానికి అనుమతిస్తాయి. ప్రతి సహాయ పేజీలో కొద్దిగా భిన్నమైన అర్థం ఉన్న విక్రేత వర్గం కంటే అవి బాగా పాతబడతాయి.

చివరగా, ఇది రాసేటప్పుడు RFC 4787 పదజాలాన్ని చేతిలో ఉంచుకోండి. ఖచ్చితమైన పదాలను ఉపయోగించడం ఒక వాక్యం ఖర్చు, అది తదుపరి పాఠకుడు అదే తప్పు నిర్ధారణను పునరావృతం చేయకుండా నిరోధిస్తుంది, గమనిక రాయడం యొక్క మొత్తం ఉద్దేశ్యం అదే.

సంబంధిత వ్యాసాలు