ಬ್ರಿಜ್ ಮಾಡಿದ VPN ಹಾಟ್‌ಸ್ಪಾಟ್: ಫೋನ್ ಯಾವ ಡೀಫಾಲ್ಟ್ ರೂಟ್ ಬಳಸುತ್ತದೆ?
Pi ನ ಡೀಫಾಲ್ಟ್ ರೂಟ್ ಫೋನ್‌ನ ಗೇಟ್‌ವೇ ಅಲ್ಲ. ಎರಡು ನಿರ್ಧಾರಗಳನ್ನು ಬೇರ್ಪಡಿಸಿ, ಅಪ್‌ಲಿಂಕ್ ಅನ್ನು ಬ್ರಿಜ್‌ನ ಹೊರಗೆ ಇರಿಸಿ, ಮತ್ತು ಟನೆಲ್‌ಗೆ ಮೊದಲು ಲೀಜ್ ಪರೀಕ್ಷಿಸಿ.
ನಿಮ್ಮ ಬ್ರಿಜ್ ಮಾಡಿದ ಹಾಟ್‌ಸ್ಪಾಟ್‌ನ ಫೋನ್ ತನ್ನ ವಿಳಾಸ ಮತ್ತು ಗೇಟ್‌ವೇ ಅನ್ನು ಎಲ್ಲಿಂದಲೋ ಪಡೆಯುತ್ತದೆ, ಮತ್ತು ಅದು Pi ನ ಡೀಫಾಲ್ಟ್ ರೂಟ್ ಅಲ್ಲ. Pi ನ ಡೀಫಾಲ್ಟ್ ಬದಲಿಸಿದರೆ Pi ತನ್ನ ಸ್ವಂತ ಟ್ರಾಫಿಕ್ ಎಲ್ಲಿಗೆ ಕಳುಹಿಸುತ್ತದೆ ಎಂಬುದು ಬದಲಾಗುತ್ತದೆ. ಫೋನ್ ತನಗೆ ಹೇಳಿದ ಗೇಟ್‌ವೇ ಬಳಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ, ಮತ್ತು ಆ ಗೇಟ್‌ವೇ ದೂರದ LAN ನಲ್ಲಿದ್ದಾಗ ಅದರ ಫ್ರೇಮ್‌ಗಳು ಸುಮ್ಮನೆ ಬ್ರಿಜ್ ದಾಟುತ್ತವೆ. ಎರಡು ಗ್ರಾಹಕರು, ಎರಡು ನಿರ್ಧಾರಗಳು. ಅವನ್ನು ಬೇರ್ಪಡಿಸುವುದು Pi ಸ್ವತಃ ಸರಿಯಾಗಿದ್ದರೂ ಇಂಟರ್ನೆಟ್ ಇಲ್ಲದ ಹಾಟ್‌ಸ್ಪಾಟ್‌ನ ಬಗ್ಗೆ ಬರುವ ಬಹುಪಾಲು ವರದಿಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ.
ಎರಡು ಸಾಧನಗಳು, ಎರಡು ವಿಭಿನ್ನ ಗೇಟ್‌ವೇ ನಿರ್ಧಾರಗಳು
Pi ಗೆ ತನ್ನದೇ IP ಸ್ಟಾಕ್ ಮತ್ತು ತನ್ನದೇ ಡೀಫಾಲ್ಟ್ ರೂಟ್ ಇದೆ. ಫೋನ್‌ಗೆ ತನ್ನದೇ IP ಸ್ಟಾಕ್ ಮತ್ತು ತನ್ನದೇ ಡೀಫಾಲ್ಟ್ ರೂಟ್ ಇದೆ.
| Consumer | Who chooses its gateway | What carries the traffic |
|---|---|---|
| Phone on the bridged AP | The remote LAN router, delivered in its client configuration | An Ethernet frame toward that router crosses the AP and TAP bridge |
| Pi's encrypted connection | The travel uplink's route toward the VPN peer | The Pi sends its own outer transport packets over the underlay |
ಆ ಕೋಷ್ಟಕವೇ ಇಡೀ ಮಾದರಿ. ಫೋನ್‌ನ ಗೇಟ್‌ವೇ ದೂರದ LAN ನಲ್ಲಿನ ವಿಳಾಸ, ಮತ್ತು ಅದರ ಫ್ರೇಮ್‌ಗಳು ಲೇಯರ್ 2 ನಲ್ಲಿ ಆ ರೌಟರ್ ಕಡೆಗೆ ಫಾರ್ವರ್ಡ್ ಆಗುತ್ತವೆ. Pi ನ ಡೀಫಾಲ್ಟ್ ರೂಟ್ Pi ಯ ಸ್ವಂತ ಹೊರ ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್‌ಗೆ ಸಂಬಂಧಿಸಿದ್ದು, ಅದು ಪ್ರಯಾಣ ಅಪ್‌ಲಿಂಕ್ ಮೂಲಕ VPN ಪೀರ್ ತಲುಪಬೇಕು.
ಬ್ರಿಜ್ ಫ್ರೇಮ್‌ಗಳನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ, ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ರೂಟ್ ಮಾಡುವುದಿಲ್ಲ
Linux ಬ್ರಿಜ್ ಗಮ್ಯ MAC ಪ್ರಕಾರ Ethernet ಫ್ರೇಮ್‌ಗಳನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ, ಮತ್ತು ತನ್ನ ಪೋರ್ಟ್‌ಗಳ ನಡುವೆ ಅಷ್ಟೇ ಮಾಡುತ್ತದೆ. ದೂರದ ರೌಟರ್‌ನ MAC ಗೆ ಉದ್ದೇಶಿಸಿದ ಫೋನ್‌ನ ಫ್ರೇಮ್ TAP ಪೋರ್ಟ್‌ಗೆ ಸ್ವಿಚ್ ಆಗಿ Pi ಯ ರೂಟಿಂಗ್ ಟೇಬಲ್ ಮುಟ್ಟದೆ ಟನೆಲ್ ದಾಟುತ್ತದೆ. ಆದ್ದರಿಂದ ಕೆಟ್ಟ Pi ಡೀಫಾಲ್ಟ್ ರೂಟ್ ಫೋನ್ ಕೆಲಸ ಮಾಡುವಂತೆ ಬಿಡಬಹುದು, ಮತ್ತು ಆದ್ದರಿಂದ ಸರಿಯಾದ ರೂಟ್ ತಪ್ಪು ಗೇಟ್‌ವೇ ಪಡೆದ ಫೋನ್ ಸರಿಪಡಿಸಲಾರದು.
TAP Ethernet ಫ್ರೇಮ್‌ಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ ಮತ್ತು ಬ್ರಿಜ್ ಪೋರ್ಟ್ ಆಗಬಹುದು. TUN IP ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ ಮತ್ತು ಆಗಲಾರದು. ನಿಮ್ಮ ವಿನ್ಯಾಸ ಒಂದನ್ನು ಇನ್ನೊಂದರಿಂದ ಬದಲಿಸಿದ್ದರೆ, ಬ್ರಿಜ್ ಬ್ರಿಜ್ ಅಲ್ಲ ಮತ್ತು ಇಲ್ಲಿನ ಉಳಿದದ್ದು ಅನ್ವಯಿಸುವುದಿಲ್ಲ.
ಫೋನ್‌ನ ಲೀಜ್ ಯಾರು ಹಂಚುತ್ತಾರೆ ಎಂದು ನಿರ್ಧರಿಸಿ
DHCP ಆಯ್ಕೆ 3 ರೌಟರ್ ಆಯ್ಕೆ, ಮತ್ತು ಅದು ಕ್ಲೈಂಟ್‌ಗೆ ತನ್ನ ಸಬ್‌ನೆಟ್‌ಗೆ ಯಾವ ಗೇಟ್‌ವೇ ಬಳಸಬೇಕೆಂದು ಹೇಳುತ್ತದೆ. ದೂರದ LAN ನ DHCP ಸರ್ವರ್ ಏಕೈಕ ಹಂಚಿಕೆದಾರನಾದಾಗ, ಫೋನ್ ದೂರದ ಗೇಟ್‌ವೇ ಪಡೆಯುತ್ತದೆ ಮತ್ತು ವಿನ್ಯಾಸ ಸುಸಂಗತವಾಗಿರುತ್ತದೆ. ಪ್ರಯಾಣದ ಬದಿಯಲ್ಲಿ ಬೇರೆ ಯಾವುದೋ ಮೊದಲು ಉತ್ತರಿಸಿದರೆ, ಫೋನ್ ಸ್ಥಳೀಯ ಗೇಟ್‌ವೇ ಪಡೆಯುತ್ತದೆ, ಅದರ ಇಂಟರ್ನೆಟ್ ಟ್ರಾಫಿಕ್ ಪ್ರಯಾಣ ಅಪ್‌ಲಿಂಕ್ ಮೂಲಕ ಹೊರಹೋಗುತ್ತದೆ, ಮತ್ತು ಅದರ ದೂರದ LAN ಟ್ರಾಫಿಕ್‌ಗೆ ಯಾವುದೇ ದಾರಿಯೇ ಇರುವುದಿಲ್ಲ.
ಆ ಬ್ರಾಡ್‌ಕಾಸ್ಟ್ ಡೊಮೇನ್‌ಗೆ ಒಂದೇ ಹಂಚಿಕೆದಾರ ಚಲಾಯಿಸಿ, ಮತ್ತು ಅದು ಏನು ಹಂಚುತ್ತದೆ ಎಂದು ದಾಖಲಿಸಿ.
Pi ಪ್ರತ್ಯೇಕ ಪ್ರಕರಣ, ಅದೇ ಲೀಜ್‌ನಿಂದ ವಿಳಾಸ ಪಡೆದರೂ. ಲೀಜ್ ನೀಡುವ ರೂಟ್‌ಗಳನ್ನು ಸ್ಥಾಪಿಸಬೇಕೇ ಎಂದು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿರ್ಧರಿಸಿ, ಏಕೆಂದರೆ ಆಮದು ಮಾಡಿದ ದೂರದ ಡೀಫಾಲ್ಟ್ Pi ಯ ಸ್ವಂತ VPN ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ಅನ್ನು ಅದು ಜೀವಂತವಾಗಿರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಟನೆಲ್‌ಗೆ ಎಳೆಯಬಹುದು. systemd-networkd ಜೊತೆ ಆ ನಿರ್ಧಾರ DHCP ವಿಭಾಗದಲ್ಲಿ UseRoutes=; dhclient ಜೊತೆ ಅದು ವಿನಂತಿ ಪಟ್ಟಿಯಲ್ಲಿ routers ಆಯ್ಕೆ.
ಅಪ್‌ಲಿಂಕ್ ಅನ್ನು ಬ್ರಿಜ್ ಮಾಡಿದ LAN ನ ಹೊರಗೆ ಇರಿಸಿ
Pi ಯ ಹೊರ VPN ಸಂಪರ್ಕವನ್ನು ಸಾಗಿಸುವ ಇಂಟರ್‌ಫೇಸ್ ಬ್ರಿಜ್ ಪೋರ್ಟ್ ಆಗಬಾರದು. ಆದರೆ, ಎನ್‌ಕ್ರಿಪ್ಟ್ ಆದ ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ವಿಸ್ತೃತ LAN ಗೆ ಸ್ವಿಚ್ ಆಗುತ್ತದೆ ಮತ್ತು ಟನೆಲ್ ಕೊನೆಗೆ ತನ್ನದೇ ಹೊರ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ, ಇದು ಲೂಪ್ ಬದಲು ಪ್ಯಾಕೆಟ್ ನಷ್ಟದಂತೆ ಕಾಣುವ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ. AP ಸಾಮರ್ಥ್ಯ ಮತ್ತು ಬ್ರಿಜ್ ಬೆಂಬಲವನ್ನೂ ಸ್ಪಷ್ಟವಾಗಿ ಇರಿಸಿ. station ಮೋಡ್‌ನಲ್ಲಿ ವೈರ್‌ಲೆಸ್ ಇಂಟರ್‌ಫೇಸ್ ಸಾಮಾನ್ಯವಾಗಿ ಬ್ರಿಜ್ ಪೋರ್ಟ್ ಆಗಲಾರದು, ಏಕೆಂದರೆ 802.11 ಹೆಡರ್‌ನಲ್ಲಿ ಬ್ರಿಜ್‌ಗೆ ಬೇಕಾದ ಎರಡನೇ MAC ವಿಳಾಸಕ್ಕೆ ಜಾಗವಿಲ್ಲ.
ವ್ಯಾಖ್ಯಾನಿಸಿ ವಿಸ್ತೃತ ಬ್ರಾಡ್‌ಕಾಸ್ಟ್ ಡೊಮೇನ್, ಒಂದು ವಿಳಾಸ ಯೋಜನೆ, ಮತ್ತು ನೀವು ನಿಜವಾಗಿ ಬಯಸುವ ಫ್ರೇಮ್ ಫಿಲ್ಟರಿಂಗ್. Pi ಯಲ್ಲಿ VPN ಶ್ರೋತೃಗೆ ಅನುಮತಿ ನೀಡಿದರೆ ಪ್ರತಿ ಬ್ರಿಜ್ ಮಾಡಿದ ಕ್ಲೈಂಟ್‌ಗೂ Pi ಯ ನಿರ್ವಹಣಾ ಸೇವೆಗಳಿಗೆ ಪ್ರವೇಶ ಸಿಗುವುದಿಲ್ಲ. ಅವು ಪ್ರತ್ಯೇಕ ನಿಯಮಗಳು, ಮತ್ತು ಅವನ್ನು ಒಂದೇ ಎಂದು ಪರಿಗಣಿಸುವುದು ಹಾಟ್‌ಸ್ಪಾಟ್ ಮೌನವಾಗಿ ತೆರೆದ ಬಾಗಿಲಾಗುವ ದಾರಿ.
ಮುರಿದಾಗ ನಾಲ್ಕನ್ನೂ ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ
ಫೋನ್ ದೂರದ LAN ತಲುಪದಿದ್ದಾಗ, ನಾಲ್ಕು ಅವಲೋಕನಗಳು ಕಾರಣಗಳನ್ನು ಬೇರ್ಪಡಿಸುತ್ತವೆ. ಅವನ್ನು ಈ ಕ್ರಮದಲ್ಲಿ ಚಲಾಯಿಸಿ ಮತ್ತು ಮೊದಲ ವಿಫಲತೆಯಲ್ಲಿ ನಿಲ್ಲಿಸಿ.
ip route show default
bridge link show
ip -4 neigh show dev br0
tcpdump -ni br0 arp or icmpಲೀಜ್‌ನಿಂದ ಪ್ರಾರಂಭಿಸಿ: ಫೋನ್ ದೂರದ ಸಬ್‌ನೆಟ್‌ನಲ್ಲಿ ವಿಳಾಸ ಮತ್ತು ಗೇಟ್‌ವೇ ಹೊಂದಿದೆಯೇ? ನಂತರ ಬ್ರಿಜ್ ನೋಡಿ, ಮತ್ತು AP ಪೋರ್ಟ್ ಮತ್ತು TAP ಪೋರ್ಟ್ ಎರಡೂ ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತಿವೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ನಂತರ ನೆರೆಹೊರೆಯ ಟೇಬಲ್ ಓದಿ, ಏಕೆಂದರೆ ದೂರದ ರೌಟರ್‌ಗೆ ಬಗೆಹರಿಸದ ನಮೂದು ಎಂದರೆ ಫ್ರೇಮ್‌ಗಳು ಹೊರಹೋಗುತ್ತವೆ ಮತ್ತು ಯಾವುದೂ ಉತ್ತರಿಸುವುದಿಲ್ಲ. ಕೊನೆಗೆ ಫೋನ್ ping ಮಾಡುವಾಗ ಬ್ರಿಜ್‌ನಲ್ಲಿ ಫ್ರೇಮ್‌ಗಳನ್ನು ಗಮನಿಸಿ, ಇದು ದೋಷ IP ಗಿಂತ ಕೆಳಗಿದೆಯೇ ಎಂದು ಹೇಳುತ್ತದೆ.
ಮುಗಿದ ನಂತರ ಯಾವ ಸಾಧನ ಯಾವ ಡೀಫಾಲ್ಟ್‌ನ ಮಾಲೀಕ ಎಂದು ದಾಖಲಿಸಿ. ಒಂದು ಸಾಲಿನ ದಾಖಲೆ ಸ್ಥಳೀಯ ಮತ್ತು ದೂರದ ಇಗ್ರೆಸ್ ಪ್ರಶ್ನೆಯನ್ನು ಉದ್ದೇಶಪೂರ್ವಕ ಕ್ಲೈಂಟ್ ನಿರ್ಧಾರವಾಗಿ ಬದಲಿಸುತ್ತದೆ, ಮತ್ತು ಬ್ರಿಜ್ ಉಲ್ಲೇಖವನ್ನು ಅದರ ಪಕ್ಕದಲ್ಲಿ ಇರಿಸುವುದು ಯೋಗ್ಯ.