OpenVPN క్లయింట్లు ఒకరినొకరు చూడలేరు: subnet లేదా net30?
క్లయింట్లు సర్వర్‌కు చేరుతాయి కానీ ఒకరికొకరు చేరవు. ఒక ping తో లోపాన్ని వేరు చేయండి, ఆపై subnet టోపాలజీ, client-to-client లేదా వంతెన వేసిన TAP విభాగాన్ని ఎంచుకోండి.
సంబంధం లేని రెండు లోపాలు ఒకే ఫిర్యాదును కలిగిస్తాయి. మొదటిదానిలో ఒక క్లయింట్ మరొకదానికి tunnel చిరునామా ద్వారా కూడా చేరదు, ఎందుకంటే చిరునామాలు ఒకే subnet లో లేవు లేదా సర్వర్ సహచర ట్రాఫిక్‌ను ఫార్వార్డ్ చేయదు. రెండవదానిలో ping పని చేస్తుంది కానీ యాప్ పరికరాల జాబితా ఖాళీగా ఉంటుంది, ఎందుకంటే కనుగొనడం 3 పొర tunnel తీసుకెళ్లలేని broadcast పై ఆధారపడి ఉంటుంది. ఒక ping రెండింటినీ వేరు చేస్తుంది, ప్రతి దాని పరిష్కారం మరొకదాని పరిష్కారంతో అస్సలు పోలి ఉండదు.
ఒక ping సమస్యను రెండుగా విభజిస్తుంది
ఒక క్లయింట్ నుండి మరొక క్లయింట్ యొక్క tunnel చిరునామాకు ping చేయండి, దాని పేరుకు కాదు మరియు దాని LAN చిరునామాకు కాదు. అది విఫలమైతే, ఫార్వార్డింగ్ లేదా చిరునామా కేటాయింపు సమస్య మరియు అది సరిగ్గా మారే వరకు కనుగొనడం అప్రస్తుతం. అది విజయవంతమైతే, ఫార్వార్డింగ్ ఇప్పటికే పని చేస్తోంది మరియు మిగిలిన ఖాళీ broadcast లేదా పేర్ల పరిష్కారం.
ip addr show tun0అన్నింటికీ ముందు క్లయింట్ ఇంటర్ఫేస్‌ను చదవండి, ఎందుకంటే నెట్‌మాస్క్ టోపాలజీని పేరు పెడుతుంది. /24 లేదా మరొక subnet మాస్క్ అంటే పంచుకున్న పూల్; సహచర చిరునామాతో /30 అంటే పాత పాయింట్-టు-పాయింట్ అమరిక, ఇక్కడ ప్రతి క్లయింట్‌కు సరిగ్గా ఒక పొరుగువాడు ఉంటాడు, సర్వర్.
net30 మరియు subnet, క్లయింట్ వైపు నుండి చదివినప్పుడు
| What you observe | net30 | subnet |
|---|---|---|
| Client netmask | /30 with a peer address | The pool's own mask |
| Peers a client can address directly | One, the server | Every client in the pool |
| Addressing | One /30 block per client, with the server as the only peer | One pool mask shared by all clients |
| Effect of client-to-client | Required for any peer traffic | Required for peer traffic, still no broadcast |
net30 లో సర్వర్ ప్రతి క్లయింట్‌కు చిన్న బ్లాక్ ఇస్తుంది, కాబట్టి సర్వర్ ఫార్వార్డ్ చేయకపోతే మరొక క్లయింట్ tunnel చిరునామాకు మార్గం లేదు. subnet లో మొత్తం పూల్ ఒకే నెట్‌వర్క్, ప్రతి క్లయింట్ ప్రతి ఒక్కరినీ సంబోధించగలదు, సర్వర్ వాటి మధ్య ఫార్వార్డ్ చేస్తుంది. అందుకే ఒక సర్వర్ కాన్ఫిగరేషన్ ఆరోగ్యంగా కనిపించినా సహచరుల మధ్య ping విఫలమవుతుంది: ఏదీ పాడవలేదు, క్లయింట్లు ఒకే నెట్‌వర్క్‌లో లేరు అంతే. క్లయింట్ పని చేస్తున్న లింక్‌ను మరియు సమాధానం ఇవ్వని సహచర చిరునామాను చూస్తుంది, ఇది firewall లాగా చదవబడుతుంది కానీ వాస్తవానికి చిరునామా కేటాయింపు అమరిక.
డైరెక్టివ్‌ను మార్చడం సర్వర్ వైపు సవరణ మరియు పునఃప్రారంభం, మరియు ఇది ఇప్పటికే తెరిచిన సెషన్లకు కాదు, తదుపరి కనెక్షన్‌కు వర్తిస్తుంది. మార్పును అంచనా వేసే ముందు క్లయింట్లను మళ్లీ కనెక్ట్ చేయండి. పరికరం వెబ్ ఇంటర్‌ఫేస్ నుండి కాన్ఫిగరేషన్‌ను మళ్లీ సృష్టిస్తే, డైరెక్టివ్, ఫైల్ మరియు తేదీని నమోదు చేయండి, మరియు ఇంటర్‌ఫేస్ ఉన్నప్పుడు దాని ద్వారానే సవరించండి, ఎందుకంటే పునర్నిర్మాణం తదుపరి సేవ్‌లో చేతితో చేసిన సవరణను తుడిచివేస్తుంది.
client-to-client వేరే ద్వారం
ఒకే subnet లోపల కూడా, client-to-client సెట్ చేయకపోతే, ఒక క్లయింట్ నుండి వచ్చి మరొకదానికి చిరునామా చేయబడిన ప్యాకెట్లను సర్వర్ విసిరేస్తుంది. ఆ కీవర్డ్ సర్వర్‌ను కేవలం స్వీకరించే ముగింపు బిందువు కాకుండా సహచర ట్రాఫిక్ ఫార్వార్డర్‌గా మారుస్తుంది. టోపాలజీని సరిచేసిన తర్వాత ప్రజలు మరచిపోయే రెండవ షరతు ఇదే.
ఇది broadcast వరకు విస్తరించదు. ఈ సెట్టింగ్ క్లయింట్ల మధ్య unicast ఫార్వార్డ్ చేస్తుంది; ఇది tunnel ను పంచుకున్న విభాగంగా మార్చదు, మరియు దాని ఎంత మొత్తమైనా multicast కనుగొనడం ప్రశ్నను ప్రతి సహచరుడికి చేరవేయదు.
TUN మరియు TAP, మరియు ప్రతిది ఏమి మోసుకెళ్లగలదు
| Property | TUN | TAP |
|---|---|---|
| Layer | Layer 3, IP packets | Layer 2, Ethernet frames |
| Broadcast and multicast | Not carried | Carried |
| Bridging to the LAN | Not applicable | Required for a shared segment |
| Client platform support | Everywhere | Missing on Android and iOS, limited on macOS |
tap పరికరాన్ని LAN లోకి వంతెన వేయడం దూరస్థ క్లయింట్లను కార్యాలయ broadcast డొమైన్‌లోకి తెస్తుంది, ఇది కనుగొనడాన్ని పూర్తిగా పరిష్కరిస్తుంది. ధర అంటే TAP అమలు చేయని ప్లాట్‌ఫారమ్‌లు, సర్వర్‌పై ఉండాల్సిన వంతెన, మరియు కార్యాలయ కేబుల్‌పై broadcast తుఫాను ప్రతి దూరస్థ ల్యాప్‌టాప్‌కు చేరే వైఫల్య డొమైన్.
పేర్ల పరిష్కారం అవసరమయ్యే రెండు లేదా మూడు వర్క్‌స్టేషన్లకు hosts నమోదు లేదా unicast చిరునామా వంతెన కంటే చాలా చవక. మీరు భర్తీ చేయలేని ప్రోటోకాల్ 2 పొర కనుగొనడంపై ఆధారపడి ఉన్నప్పుడే TAP వైపు వెళ్లండి, అంతకు ముందు కాదు.
వంతెన లేని ఒకే subnet క్లయింట్లు
LAN పరిధి నుండి చిరునామా ఇవ్వడం క్లయింట్‌ను కేబుల్‌పై ఉంచదు. సర్వర్ tunnel మరియు Ethernet మధ్య మార్గం ఏర్పాటు చేస్తుంది, కాబట్టి ఆ చిరునామాకు ARP సర్వర్ ఇంటర్‌ఫేస్ వద్ద ఆగిపోతుంది మరియు మిగిలిన LAN అది ఎక్కడ నివసిస్తుందో ఎప్పటికీ తెలుసుకోదు.
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP ఆ ఖాళీని మూస్తుంది, సర్వర్ క్లయింట్ తరఫున సమాధానం ఇస్తుంది. పరిధి కోసం parpd క్లయింట్లు వచ్చేటప్పుడు పోయేటప్పుడు నమోదులను నిర్వహిస్తుంది, అయితే sysctl net.ipv4.conf.eth0.proxy_arp=1 వేరే చోటికి మార్గం ఏర్పడే ప్రతిదానికీ సమాధానం ఇస్తుంది, ఇది రద్దీగా ఉన్న విభాగంలో దాని స్వంత ఆశ్చర్యాలను సృష్టించడానికి తగినంత విస్తృతం.
మీరు ఏ మార్గాన్ని ఎంచుకున్నా, tunnel మరియు కేబుల్ మధ్య NAT ను తీసివేయండి. MASQUERADE నియమం మీరు సమాధానం ఇవ్వాలనుకుంటున్న చిరునామా కేటాయింపు ప్రశ్నను సరిగ్గా దాచుతుంది. ఇది తదుపరి వ్యక్తికి క్లయింట్ వైపు నుండి ఆలోచించలేని టోపాలజీని కూడా మిగులుస్తుంది.
ఏదైనా మార్చే ముందు, సర్వర్‌పై tcpdump -ni tun0 తో ఒక ప్రయత్నాన్ని పట్టుకోండి మరియు సహచర ప్యాకెట్ వస్తుందో లేదో నిర్ధారించండి. వచ్చి విసిరేయబడటం client-to-client వైపు సూచిస్తుంది; ఎప్పుడూ రాకపోవడం టోపాలజీ లేదా మార్గనిర్దేశం వైపు. OpenVPN 2.6 మాన్యువల్ రెండు కీవర్డ్‌లను మరియు డిఫాల్ట్ టోపాలజీని నమోదు చేస్తుంది, ఫోరమ్ పోస్ట్ నుండి లైన్ కాపీ చేసే ముందు మీ వెర్షన్‌తో సరిపోల్చడం విలువైనది.
- tun ఇంటర్‌ఫేస్ /30 సహచర జంటకు బదులు పూల్ మాస్క్‌ను చూపుతుంది.
- కనుగొనడాన్ని పరీక్షించే ముందు మరొక tunnel చిరునామాకు నేరుగా ping విజయవంతమవుతుంది.
- సహచరులు ప్యాకెట్లు మార్పిడి చేసుకోవాల్సిన ప్రతిసారీ సర్వర్ కాన్ఫిగరేషన్‌లో
client-to-clientఉంటుంది. - యాప్ విఫలమవుతుందని చెప్పే బదులు మీరు పరీక్షిస్తున్న కనుగొనడం ప్రోటోకాల్‌ను పేరు పెట్టండి.
- సమూహంలోని ప్రతి క్లయింట్ ప్లాట్‌ఫారమ్ మద్దతు ఇస్తే మాత్రమే TAP ఉపయోగించండి.
- ఒకే subnet లో చేరిక ముఖ్యమైనప్పుడు NAT ను tunnel మరియు LAN మధ్య మార్గం నుండి బయట ఉంచండి.