OpenVPN ಕ್ಲೈಂಟ್‌ಗಳು ಒಂದನ್ನೊಂದು ನೋಡುವುದಿಲ್ಲ: subnet ಅಥವಾ net30?
ಕ್ಲೈಂಟ್‌ಗಳು ಸರ್ವರ್‌ಗೆ ತಲುಪುತ್ತವೆ ಆದರೆ ಒಂದಕ್ಕೊಂದು ಅಲ್ಲ. ಒಂದು ping ನಿಂದ ದೋಷವನ್ನು ಬೇರ್ಪಡಿಸಿ, ನಂತರ subnet ಟೋಪೋಲಜಿ, client-to-client ಅಥವಾ ಬ್ರಿಡ್ಜ್ ಮಾಡಿದ TAP ವಿಭಾಗವನ್ನು ಆಯ್ಕೆಮಾಡಿ.
ಸಂಬಂಧವಿಲ್ಲದ ಎರಡು ದೋಷಗಳು ಒಂದೇ ದೂರನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ. ಮೊದಲನೆಯದರಲ್ಲಿ ಒಂದು ಕ್ಲೈಂಟ್ ಇನ್ನೊಂದಕ್ಕೆ ಟನೆಲ್ ವಿಳಾಸದಿಂದಲೂ ತಲುಪುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ವಿಳಾಸಗಳು ಒಂದೇ subnet ನಲ್ಲಿಲ್ಲ ಅಥವಾ ಸರ್ವರ್ ಸಹವರ್ತಿ ಸಂಚಾರವನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವುದಿಲ್ಲ. ಎರಡನೆಯದರಲ್ಲಿ ping ಕೆಲಸ ಮಾಡುತ್ತದೆ ಆದರೆ ಅಪ್ಲಿಕೇಶನ್‌ನ ಸಾಧನ ಪಟ್ಟಿ ಖಾಲಿಯಾಗಿರುತ್ತದೆ, ಏಕೆಂದರೆ ಪತ್ತೆ ಪದರ 3 ರ ಟನೆಲ್ ಸಾಗಿಸಲಾಗದ broadcast ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ. ಒಂದು ping ಅವೆರಡನ್ನು ಬೇರ್ಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿಯೊಂದರ ಪರಿಹಾರ ಇನ್ನೊಂದರ ಪರಿಹಾರಕ್ಕೆ ಸ್ವಲ್ಪವೂ ಹೋಲುವುದಿಲ್ಲ.
ಒಂದು ping ಸಮಸ್ಯೆಯನ್ನು ಎರಡಾಗಿ ಸೀಳುತ್ತದೆ
ಒಂದು ಕ್ಲೈಂಟ್‌ನಿಂದ ಇನ್ನೊಂದು ಕ್ಲೈಂಟ್‌ನ ಟನೆಲ್ ವಿಳಾಸಕ್ಕೆ 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 ನಲ್ಲಿ ಸರ್ವರ್ ಪ್ರತಿ ಕ್ಲೈಂಟ್‌ಗೆ ಸಣ್ಣ ಬ್ಲಾಕ್ ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಸರ್ವರ್ ಅದನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸದ ಹೊರತು ಇನ್ನೊಂದು ಕ್ಲೈಂಟ್‌ನ ಟನೆಲ್ ವಿಳಾಸಕ್ಕೆ ಮಾರ್ಗವಿಲ್ಲ. subnet ನಲ್ಲಿ ಇಡೀ ಪೂಲ್ ಒಂದೇ ಜಾಲ, ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಪ್ರತಿಯೊಂದಕ್ಕೂ ಸಂಬೋಧಿಸಬಹುದು, ಮತ್ತು ಸರ್ವರ್ ಅವುಗಳ ನಡುವೆ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ ಒಂದು ಸರ್ವರ್ ಸಂರಚನೆ ಆರೋಗ್ಯಕರವಾಗಿ ಕಾಣಬಹುದು ಆದರೆ ಸಹವರ್ತಿಗಳ ನಡುವಿನ ping ವಿಫಲವಾಗುತ್ತದೆ: ಏನೂ ಮುರಿದಿಲ್ಲ, ಕ್ಲೈಂಟ್‌ಗಳು ಒಂದೇ ಜಾಲದಲ್ಲಿಲ್ಲ ಅಷ್ಟೇ. ಕ್ಲೈಂಟ್ ಕೆಲಸ ಮಾಡುವ ಕೊಂಡಿ ಮತ್ತು ಉತ್ತರಿಸದ ಸಹವರ್ತಿ ವಿಳಾಸವನ್ನು ಕಾಣುತ್ತದೆ, ಅದು firewall ನಂತೆ ಓದುತ್ತದೆ ಆದರೆ ವಿಳಾಸೀಕರಣ ವಿನ್ಯಾಸವಾಗಿದೆ.
ನಿರ್ದೇಶನವನ್ನು ಬದಲಿಸುವುದು ಸರ್ವರ್ ಕಡೆಯ ಸಂಪಾದನೆ ಮತ್ತು ಮರುಪ್ರಾರಂಭ, ಮತ್ತು ಇದು ಈಗಾಗಲೇ ತೆರೆದ ಅಧಿವೇಶನಗಳಿಗಲ್ಲ ಬದಲಾಗಿ ಮುಂದಿನ ಸಂಪರ್ಕಕ್ಕೆ ಅನ್ವಯಿಸುತ್ತದೆ. ಬದಲಾವಣೆಯನ್ನು ನಿರ್ಣಯಿಸುವ ಮೊದಲು ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ. ಸಾಧನವು ವೆಬ್ ಇಂಟರ್‌ಫೇಸ್‌ನಿಂದ ಸಂರಚನೆಯನ್ನು ಮರುಸೃಷ್ಟಿಸಿದರೆ, ನಿರ್ದೇಶನ, ಕಡತ ಮತ್ತು ದಿನಾಂಕವನ್ನು ದಾಖಲಿಸಿ, ಮತ್ತು ಇಂಟರ್‌ಫೇಸ್ ಇದ್ದಾಗ ಅದರ ಮೂಲಕವೇ ಸಂಪಾದಿಸಿ, ಏಕೆಂದರೆ ಮರುನಿರ್ಮಾಣವು ಮುಂದಿನ ಉಳಿಸುವಿಕೆಯಲ್ಲಿ ಕೈಯಿಂದ ಮಾಡಿದ ಸಂಪಾದನೆಯನ್ನು ಅಳಿಸುತ್ತದೆ.
client-to-client ಪ್ರತ್ಯೇಕ ದ್ವಾರ
ಒಂದೇ subnet ಒಳಗೆಯೂ ಸರ್ವರ್ ಒಂದು ಕ್ಲೈಂಟ್‌ನಿಂದ ಬಂದು ಇನ್ನೊಂದಕ್ಕೆ ಸಂಬೋಧಿತವಾದ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು client-to-client ಸಿದ್ಧವಾಗಿಲ್ಲದಿದ್ದರೆ ಬಿಸಾಡುತ್ತದೆ. ಆ ಕೀಲಿಪದವು ಸರ್ವರ್ ಅನ್ನು ಕೇವಲ ಸ್ವೀಕರಿಸುವ ಅಂತ್ಯಬಿಂದುವಾಗಿ ಬದಲಾಗಿ ಸಹವರ್ತಿ ಸಂಚಾರದ ಮುಂದುಗಡೆ ಕಳುಹಿಸುವವನಾಗಿ ಮಾಡುತ್ತದೆ. ಟೋಪೋಲಜಿ ಸರಿಪಡಿಸಿದ ನಂತರ ಜನರು ಕಳೆದುಕೊಳ್ಳುವ ಎರಡನೇ ಷರತ್ತು ಇದೇ.
ಇದು broadcast ಗೆ ವಿಸ್ತರಿಸುವುದಿಲ್ಲ. ಈ ಸಿದ್ಧತೆ ಕ್ಲೈಂಟ್‌ಗಳ ನಡುವೆ unicast ಅನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ; ಅದು ಟನೆಲ್ ಅನ್ನು ಹಂಚಿದ ವಿಭಾಗವಾಗಿ ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಅದರ ಯಾವುದೇ ಪ್ರಮಾಣವೂ 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 ಶ್ರೇಣಿಯಿಂದ ವಿಳಾಸ ನೀಡುವುದು ಕ್ಲೈಂಟ್ ಅನ್ನು ಕೇಬಲ್‌ನಲ್ಲಿ ಇರಿಸುವುದಿಲ್ಲ. ಸರ್ವರ್ ಟನೆಲ್ ಮತ್ತು ಎಥರ್ನೆಟ್ ನಡುವೆ ಮಾರ್ಗ ನಿರ್ಧರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಆ ವಿಳಾಸದ ARP ಸರ್ವರ್‌ನ ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ನಿಲ್ಲುತ್ತದೆ ಮತ್ತು ಉಳಿದ LAN ಅದು ಎಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ ಎಂದು ಎಂದಿಗೂ ತಿಳಿಯುವುದಿಲ್ಲ.
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP ಆ ಕೊರತೆಯನ್ನು ಮುಚ್ಚುತ್ತದೆ, ಸರ್ವರ್ ಕ್ಲೈಂಟ್ ಪರವಾಗಿ ಉತ್ತರಿಸುತ್ತದೆ. ಶ್ರೇಣಿಗೆ parpd ನಮೂದುಗಳನ್ನು ಕ್ಲೈಂಟ್‌ಗಳು ಬಂದು ಹೋಗುವಾಗ ನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ sysctl net.ipv4.conf.eth0.proxy_arp=1 ಬೇರೆಡೆಗೆ ಮಾರ್ಗವಾಗುವ ಎಲ್ಲದಕ್ಕೂ ಉತ್ತರಿಸುತ್ತದೆ, ಅದು ಕಾರ್ಯನಿರತ ವಿಭಾಗದಲ್ಲಿ ತನ್ನದೇ ಆಶ್ಚರ್ಯಗಳನ್ನು ಸೃಷ್ಟಿಸಲು ಸಾಕಷ್ಟು ವಿಶಾಲವಾಗಿದೆ.
ನೀವು ಯಾವ ಮಾರ್ಗವನ್ನು ಆರಿಸಿದರೂ, ಟನೆಲ್ ಮತ್ತು ಕೇಬಲ್ ನಡುವಿನ NAT ಅನ್ನು ತೆಗೆಯಿರಿ. MASQUERADE ನಿಯಮ ನೀವು ಉತ್ತರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ವಿಳಾಸೀಕರಣ ಪ್ರಶ್ನೆಯನ್ನೇ ಮುಚ್ಚುತ್ತದೆ. ಅದು ಮುಂದಿನ ವ್ಯಕ್ತಿಗೆ ಕ್ಲೈಂಟ್ ಕಡೆಯಿಂದ ಯೋಚಿಸಲಾಗದ ಟೋಪೋಲಜಿಯನ್ನೂ ಬಿಡುತ್ತದೆ.
ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು, ಸರ್ವರ್‌ನಲ್ಲಿ tcpdump -ni tun0 ನಿಂದ ಒಂದು ಪ್ರಯತ್ನವನ್ನು ಹಿಡಿಯಿರಿ ಮತ್ತು ಸಹವರ್ತಿ ಪ್ಯಾಕೆಟ್ ಬರುತ್ತದೆಯೇ ಎಂದು ದೃಢೀಕರಿಸಿ. ಬಂದು ಬಿಸಾಡಲ್ಪಟ್ಟರೆ ಅದು client-to-client ಕಡೆಗೆ ಸೂಚಿಸುತ್ತದೆ; ಎಂದಿಗೂ ಬಾರದಿದ್ದರೆ ಟೋಪೋಲಜಿ ಅಥವಾ ಮಾರ್ಗನಿರ್ಧರಣೆಗೆ. OpenVPN 2.6 ಕೈಪಿಡಿ ಎರಡೂ ಕೀಲಿಪದಗಳನ್ನು ಮತ್ತು ಪೂರ್ವನಿಯೋಜಿತ ಟೋಪೋಲಜಿಯನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಮತ್ತು ಫೋರಂ ಪೋಸ್ಟ್‌ನಿಂದ ಸಾಲನ್ನು ನಕಲಿಸುವ ಮೊದಲು ನಿಮ್ಮ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಹೋಲಿಸುವುದು ಯೋಗ್ಯ.
- tun ಇಂಟರ್‌ಫೇಸ್ /30 ಸಹವರ್ತಿ ಜೋಡಿಯ ಬದಲು ಪೂಲ್ ಮಾಸ್ಕ್ ತೋರಿಸುತ್ತದೆ.
- ಪತ್ತೆಯನ್ನು ಪರೀಕ್ಷಿಸುವ ಮೊದಲು ಇನ್ನೊಂದು ಟನೆಲ್ ವಿಳಾಸಕ್ಕೆ ನೇರ ping ಯಶಸ್ವಿಯಾಗುತ್ತದೆ.
- ಸಹವರ್ತಿಗಳು ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ವಿನಿಮಯ ಮಾಡಬೇಕಾದಾಗ ಸರ್ವರ್ ಸಂರಚನೆಯಲ್ಲಿ
client-to-clientಇರುತ್ತದೆ. - ಅಪ್ಲಿಕೇಶನ್ ವಿಫಲವಾಗುತ್ತದೆ ಎಂದು ಹೇಳುವ ಬದಲು ನೀವು ಪರೀಕ್ಷಿಸುತ್ತಿರುವ ಪತ್ತೆ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಹೆಸರಿಸಿ.
- ಗುಂಪಿನ ಪ್ರತಿ ಕ್ಲೈಂಟ್ ವೇದಿಕೆಯೂ ಬೆಂಬಲಿಸಿದರೆ ಮಾತ್ರ TAP ಬಳಸಿ.
- ಒಂದೇ subnet ಒಳಗಿನ ತಲುಪುವಿಕೆ ಮುಖ್ಯವಾದಾಗ NAT ಅನ್ನು ಟನೆಲ್ ಮತ್ತು LAN ನಡುವಿನ ಮಾರ್ಗದಿಂದ ಹೊರಗಿಡಿ.