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 இடையிலான வழியிலிருந்து வெளியே வைக்கவும்.