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

ఏ సైట్‌కూ డయల్ చేయలేరు, కాబట్టి రెండూ బయటకు డయల్ చేయాలి

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

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

మీ ముందున్న సైట్ చిరునామా ప్రశ్నకు రెండు ఆదేశాలు సమాధానం ఇస్తాయి. వాటిని సైట్ రూటర్‌లో నడపండి, దాని వెనుక ఉన్న ల్యాప్‌టాప్‌లో కాదు:

ip -4 addr show scope global
ip -6 addr show scope global

ఎవరు పీర్లను పరిచయం చేస్తారు, ఎవరు ప్యాకెట్లను మోస్తారు

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

ట్రావర్సల్‌కు దాని సొంత పదకోశం ఉంది, పదాలు పాత్రలను వివరిస్తాయి, హామీలను కాదు. ICE స్పెసిఫికేషన్ అభ్యర్థులు మరియు కనెక్టివిటీ తనిఖీలను వివరిస్తుంది, STUN చిరునామా అనువాదం గురించి తెలుసుకోవడానికి ఒక మార్గాన్ని వివరిస్తుంది, TURN దాన్ని అమలు చేసే అనువర్తనాలకు రిలే రవాణాను వివరిస్తుంది. ఈ విధానాల్లో ఏదీ సాధారణ గేట్‌వేలో కనిపించదు, ఎందుకంటే మీరు దాన్ని కనుగొనే చిరునామా వైపు మళ్లించారు. ట్రావర్సల్‌ను ఉత్పత్తి సామర్థ్యంగా ధృవీకరించండి, పరీక్ష వ్యతిరేకం చూపించే వరకు రిలే ఉందని భావించండి.

ప్రతి సైట్‌కు ఒక మార్గం, పీర్ యాజమాన్యంలో

హబ్‌కు ప్రతి సైట్‌కు ఒక సొరంగం, ప్రతి దాని వెనుక వేరే LAN ప్రిఫిక్స్, మరియు ప్రతి ప్రిఫిక్స్‌కు దాని యజమానిని పేర్కొనే మార్గం అవసరం. ఉదాహరణలో హబ్ 10.61.0.1, సైట్ A అంటే LAN 10.60.10.0/24 ఉన్న 10.61.0.11, సైట్ B అంటే LAN 10.60.20.0/24 ఉన్న 10.61.0.12 అవుతుంది. క్రింది ప్రతి మార్గం సొరంగ ఇంటర్‌ఫేస్ వైపు కాదు, ప్రిఫిక్స్ ఉన్న పీర్ వైపు చూపుతుంది:

ip route add 10.60.10.0/24 via 10.61.0.11 dev wg0
ip route add 10.60.20.0/24 via 10.61.0.12 dev wg0
sysctl net.ipv4.ip_forward
ip route get 10.60.20.55 from 10.60.10.77

ఫార్వర్డింగ్ ప్రారంభించబడి ఉండాలి, లేకపోతే ప్యాకెట్లు హబ్ వద్ద ఆగిపోతాయి, కారణాన్ని చూపించే లోపం ఉండదు. చివరి ఆదేశం నిజమైన ప్రశ్నకు సమాధానం ఇస్తుంది, ఎందుకంటే మూలాన్ని శోధనలో చేర్చి సైట్ A LAN నుండి సైట్ B LAN వరకు ప్యాకెట్ ఏ మార్గం తీసుకుంటుందో అడుగుతుంది. సొరంగ ఇంటర్‌ఫేస్‌ను పేర్కొనే శోధనను రుజువుగా, డిఫాల్ట్ మార్గానికి పడేదాన్ని చిక్కుగా కాదు, తప్పిపోయిన మార్గంగా పరిగణించండి. తర్వాత రవాణాన్ని ఉద్దేశపూర్వకంగా పరిమితం చేయండి, ఎందుకంటే ప్రతి పీర్ మధ్య ఫార్వర్డ్ చేసే హబ్ రెండు సైట్లను చదునైన నెట్‌వర్క్‌గా మారుస్తుంది మరియు మీరు ఉందనుకున్న ప్రాప్యత విధానం వర్తించదు.

ఎన్‌క్రిప్షన్ ఎక్కడ ముగుస్తుందో కూడా నిర్ణయించండి. హబ్ సొరంగం రెండు చివరలను కలిగి ఉన్నప్పుడు, ఆ యంత్రం నిర్వాహకుడు మరియు దాని పనిభారం నమ్మకం మరియు లభ్యత నమూనాలో చేరతాయి, దాని బ్యాండ్‌విడ్త్ మార్గంలో భాగమవుతుంది.

ప్రతి మ్యాపింగ్‌ను ఆపరేటర్ ద్వారా సజీవంగా ఉంచండి

ప్రతి సైట్ తన సొంత సొరంగాన్ని ప్రారంభిస్తుంది, ప్రతి ఒక్కటి అనువాద మ్యాపింగ్‌ను సజీవంగా ఉంచాలి, లేకపోతే ఆపరేటర్ దాన్ని మర్చిపోతాడు. ప్రారంభించే వైపు సజీవత సందేశం ఆ మ్యాపింగ్‌ను చేతులు కలపడాల మధ్య కాపాడుతుంది. అనుమతించిన ప్రిఫిక్స్‌లను హబ్ చిరునామా మరియు దూర LAN కు పరిమితం చేయండి, తద్వారా రాజీపడిన పీర్ తనకు లేని ప్రిఫిక్స్‌ను దావా చేయలేడు:

[Peer]
PublicKey = <hub public key>
Endpoint = 192.0.2.10:51820
AllowedIPs = 10.61.0.1/32, 10.60.20.0/24
PersistentKeepalive = 25

మరో సైట్‌లో దాని సొంత దూర ప్రిఫిక్స్‌తో బ్లాక్‌ను ప్రతిబింబించండి, మొత్తం సొరంగ పరిధిని అనుమతించాలనే కోరికను ఎదిరించండి. ఆగి కొత్త మూల పోర్టు నుండి తిరిగి ప్రారంభమయ్యే చేతులు కలపటం గడువు ముగిసిన మ్యాపింగ్ సంతకం, చేతులు కలపడం సమయ ముద్రలు అది జరిగిన రుజువు. ఆపరేటర్ కాల పరిమితి కంటే చిన్న విరామం గడువు ముగియకుండా నిరోధిస్తుంది, తర్వాత దాన్ని బాగు చేయదు. ఆపరేటర్ తన అనువాద ప్రవర్తనను మార్చితే, ఆ సమయాలు కూడా అతనితో మారుతాయని ఆశించండి.

రెండు దిశలను నిరూపించండి, తర్వాత పునరుద్ధరణను నిరూపించండి

ధృవీకరణ దిశాత్మకం, కాబట్టి A నుండి B కి ping నిర్మాణంలో సగం నిరూపిస్తుంది, తిరిగి వచ్చే మార్గం గురించి ఏమీ లేదు. హబ్‌లో అదే మూల-అవగాహన శోధనతో ప్రతిస్పందన మార్గాన్ని తనిఖీ చేయండి, తర్వాత మరో వైపు నుండి పరీక్షను పునరావృతం చేయండి. కొత్త చేతులు కలపడాలు కూడా రుజువులో భాగం, ఎందుకంటే గంటపాటు నిష్క్రియంగా ఉన్న సొరంగం పాత మ్యాపింగ్‌ను పరీక్షిస్తూ ఉండవచ్చు:

wg show wg0 latest-handshakes
ping -c 3 10.60.20.55
traceroute -n 10.60.20.55

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

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