ರೂಟರ್ VPN ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದರೆ LAN ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಇಂಟರ್ನೆಟ್ ಇಲ್ಲ
ರೂಟರ್ ತನ್ನ ಸುರಂಗದ ಮೂಲಕ ಇಂಟರ್ನೆಟ್ ತಲುಪುತ್ತದೆ, ಅದರ ಹಿಂದಿನ ಸಾಧನಗಳು ತಲುಪುವುದಿಲ್ಲ. ಫಾರ್ವರ್ಡಿಂಗ್, ಅನುವಾದ ಮತ್ತು ಹಿಂತಿರುಗು ಮಾರ್ಗಗಳು ಪ್ರತ್ಯೇಕ ಅನುಮತಿಗಳು.
ಸುರಂಗ ಸಕ್ರಿಯವಾಗಿದೆ ಎಂದು ಸ್ಥಿತಿ ಹೇಳುತ್ತದೆ, ರೂಟರ್ನಲ್ಲಿಯೇ ಇರುವ ಬ್ರೌಸರ್ ಪುಟಗಳನ್ನು ಲೋಡ್ ಮಾಡುತ್ತದೆ, ಆದರೆ ಅದರ ಹಿಂದಿನ ಪ್ರತಿ ಸಾಧನವೂ ಇನ್ನೂ ಸಮಯ ಮೀರುತ್ತದೆ. ಆ ಸಂಯೋಜನೆ ಸಮಸ್ಯೆಯನ್ನು ಬಹುತೇಕ VPN ಮಾರ್ಗದರ್ಶಿಗಳು ಎಂದೂ ಉಲ್ಲೇಖಿಸದ ಪದರಕ್ಕೆ ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ: ಸುರಂಗದ ಮೂಲಕ ಹಾದುಹೋಗಬೇಕಾದ ಪ್ಯಾಕೆಟ್ಗಳಿರುವ ಏಕೈಕ ಹೋಸ್ಟ್ ರೂಟರ್ ಅಲ್ಲ. ಸ್ಥಳೀಯವಾಗಿ ರಚಿಸಲಾದ ಸಂಚಾರ ಮತ್ತು ಫಾರ್ವರ್ಡ್ ಆಗುವ ಸಂಚಾರ ಒಂದೇ ಪೆಟ್ಟಿಗೆಯಲ್ಲಿ ಬೇರೆ ಬೇರೆ ಮಾರ್ಗಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತವೆ. ಕ್ಲೈಂಟ್ನಿಂದ ಪರೀಕ್ಷಿಸಿ, ವ್ಯತ್ಯಾಸವು ಸೈದ್ಧಾಂತಿಕವಾಗಿರುವುದಿಲ್ಲ.
LAN ಹೋಸ್ಟ್ನಿಂದ ವೈಫಲ್ಯವನ್ನು ಓದಿ
ವಿಫಲವಾಗುವ ಸಾಧನದಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಏಕೆಂದರೆ ರೂಟರ್ನಲ್ಲಿ ನಡೆಸುವ ರೋಗನಿರ್ಣಯ ಬೇರೆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ನ ಡೀಫಾಲ್ಟ್ ಗೇಟ್ವೇ ಈ ರೂಟರ್ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಅದರ ಮೂಲ ವಿಳಾಸ ಮತ್ತು ಉಪಜಾಲವನ್ನು ಗಮನಿಸಿ, ನಂತರ ರೂಟರ್ನ ಸುರಂಗ ಇಂಟರ್ಫೇಸ್ನಿಂದ ಏನು ಹೊರಬರುತ್ತದೆ ಎಂದು ನೋಡಿ.
ಕ್ಲೈಂಟ್ನ ವಿಳಾಸವನ್ನು ಅನುವಾದಿಸಿದರೆ, ದೂರದ ಬದಿ ಸುರಂಗದ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ ಮತ್ತು ಅಲ್ಲಿಂದ ಎಲ್ಲವೂ ಆರೋಗ್ಯಕರವಾಗಿ ಕಾಣುತ್ತದೆ, ಆದರೆ ಕ್ಲೈಂಟ್ ಇನ್ನೂ ವಿಫಲವಾಗುತ್ತದೆ. ಅನುವಾದಿಸದಿದ್ದರೆ, ದೂರದ ಬದಿಗೆ ಕ್ಲೈಂಟ್ನ ಉಪಜಾಲಕ್ಕೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ತಿಳಿದಿರಬೇಕು, ಮತ್ತು ಅನೇಕ ಗೇಟ್ವೇಗಳಿಗೆ ಡೀಫಾಲ್ಟ್ ಆಗಿ ಅಂತಹ ಮಾರ್ಗವಿಲ್ಲ. ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ರೂಟರ್ನ ಸ್ವಂತ ಯಶಸ್ಸು ಅಪ್ರಸ್ತುತ, ಏಕೆಂದರೆ ಅದರ ಪ್ಯಾಕೆಟ್ಗಳು ಸ್ಥಳೀಯವಾಗಿ ರಚಿಸಲ್ಪಟ್ಟವು ಮತ್ತು ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾರ್ಗವನ್ನು ಎಂದೂ ದಾಟಲಿಲ್ಲ.
ಸ್ಥಳೀಯ ಸಂಚಾರ ಮತ್ತು ಫಾರ್ವರ್ಡ್ ಸಂಚಾರ ಬೇರೆ ಬೇರೆ
Linux ಮತ್ತು ಬಹುತೇಕ ರೂಟರ್ ಫರ್ಮ್ವೇರ್ಗಳು ಪೆಟ್ಟಿಗೆಯೇ ರಚಿಸಿದ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಅದರ ಮೂಲಕ ಹಾದುಹೋಗುವ ಪ್ಯಾಕೆಟ್ಗಳಿಗಿಂತ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ನಡೆಸುತ್ತವೆ. ಔಟ್ಪುಟ್ ಸರಣಿಯು ಮೊದಲನೆಯದನ್ನು ನೋಡುತ್ತದೆ, ಫಾರ್ವರ್ಡ್ ಸರಣಿಯು ಎರಡನೆಯದನ್ನು ನೋಡುತ್ತದೆ, ಮತ್ತು ರೂಟರ್ನ ಸ್ವಂತ ಸಂಚಾರಕ್ಕೆ ಹೊಂದಿಸಿದ ನೀತಿಯು ಫಾರ್ವರ್ಡಿಂಗ್ ಅನ್ನು ಮುಟ್ಟದೆ ಬಿಡಬಹುದು.
sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'
ಫಾರ್ವರ್ಡಿಂಗ್ ಸಂಪೂರ್ಣವಾಗಿ ಸಕ್ರಿಯವಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ, ನಂತರ ಔಟ್ಪುಟ್ ಸರಣಿಯ ಬದಲು ಫಾರ್ವರ್ಡ್ ಸರಣಿಯನ್ನು ಓದಿ. ಎನ್ಕ್ರಿಪ್ಟ್ ಆದ ಹೊರ ಸಂಪರ್ಕಕ್ಕೆ ಅನುಮತಿ ನೀಡುವ ನಿಯಮವು ಡೀಕ್ರಿಪ್ಟ್ ಆದ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಲು ಅನುಮತಿ ನೀಡುವ ನಿಯಮವಲ್ಲ, ಮತ್ತು ಎರಡನ್ನೂ ಗೊಂದಲಿಸುವುದು ನಿಖರವಾಗಿ ಈ ಲಕ್ಷಣವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಸುರಂಗ ಸಕ್ರಿಯವಾಗಿರುವುದು ಮೊದಲನೆಯದನ್ನು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ.
ಹಿಂತಿರುಗು ಮಾರ್ಗವೂ ಇರಬೇಕು
ಮೂಲ ಅನುವಾದವು ಹಿಂತಿರುಗು ಮಾರ್ಗದ ಅಗತ್ಯವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಸುರಂಗ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಮಾಸ್ಕರೇಡಿಂಗ್ ಇದ್ದರೆ, ಪ್ರತ್ಯುತ್ತರಗಳು ಸುರಂಗದ ವಿಳಾಸಕ್ಕೆ ಹಿಂತಿರುಗುತ್ತವೆ ಮತ್ತು ರೂಟರ್ ಅವುಗಳನ್ನು ಮತ್ತೆ ಅನುವಾದಿಸುತ್ತದೆ. ಅದಿಲ್ಲದಿದ್ದರೆ, ದೂರದ ಗೇಟ್ವೇಗೆ ಕ್ಲೈಂಟ್ನ ಉಪಜಾಲಕ್ಕೆ ಸ್ಪಷ್ಟ ಮಾರ್ಗ ಬೇಕು, ಮತ್ತು ಅದರ ಸ್ವಂತ ನೀತಿಯೂ ಆ ದಿಕ್ಕಿಗೆ ಅನುಮತಿ ನೀಡಬೇಕು.
ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ನಿಯೋಜನೆ ಎರಡು ವಿನ್ಯಾಸಗಳಲ್ಲಿ ಯಾವುದನ್ನು ಬಳಸುತ್ತದೆ ಎಂದು ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಸರಿಪಡಿಸುವಿಕೆಗಳು ವಿರುದ್ಧ ದಿಕ್ಕುಗಳಿಗೆ ತೋರಿಸುತ್ತವೆ. ಅನುವಾದವನ್ನು ಸೇರಿಸುವುದು ಕಾಣೆಯಾದ ಹಿಂತಿರುಗು ಮಾರ್ಗವನ್ನು ಮುಚ್ಚುತ್ತದೆ ಮತ್ತು ಮೂಲ ಮೂಲ ವಿಳಾಸದ ಅಗತ್ಯವಿರುವ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ಮುರಿಯುತ್ತದೆ. ಅನುವಾದವಿಲ್ಲದೆ ಹಿಂತಿರುಗು ಮಾರ್ಗವನ್ನು ಸೇರಿಸುವುದು ದೂರದ ಫೈರ್ವಾಲ್ ಪರಿಚಯವಿಲ್ಲದ ಮೂಲವನ್ನು ಬಿಟ್ಟಾಗ ಸದ್ದಿಲ್ಲದೆ ವಿಫಲವಾಗುತ್ತದೆ. ಒಂದನ್ನು ಆರಿಸಿ, ದಾಖಲಿಸಿ ಮತ್ತು ಇನ್ನೊಂದು ಬದಿಯನ್ನು ಹೊಂದಿಸಿ.
ಕ್ಲೈಂಟ್ನ DNS ಅದೇ ಪರಿಶೀಲನೆಗೆ ಸೇರುತ್ತದೆ. ರೂಟರ್ನ ರಿಝಾಲ್ವರ್ ಉತ್ತರಿಸಬಹುದು, ಆದರೆ ಬೇರೆ ಸರ್ವರ್ನತ್ತ ತೋರಿಸಿದ ಕ್ಲೈಂಟ್ಗೆ ಏನೂ ಸಿಗುವುದಿಲ್ಲ.
ಒಂದು ಅನುಮತಿಸಿದ ಮತ್ತು ಒಂದು ನಿರಾಕರಿಸಿದ ಹರಿವನ್ನು ಪರಿಶೀಲಿಸಿ
ತಿದ್ದುಪಡಿಯ ನಂತರ, ರೂಟರ್ನ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸೆಷನ್ ಬದಲು ಕ್ಲೈಂಟ್ನಿಂದ ಹೊಸ ಸಂಪರ್ಕವನ್ನು ಪರೀಕ್ಷಿಸಿ. ನಂತರ ಸುರಂಗವನ್ನು ಬಳಸಬಾರದ ವಿಭಾಗವು ಇನ್ನೂ ಬಳಸುತ್ತಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿ.
curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net
ದೂರದ ತುದಿಯಲ್ಲಿ ಗಮನಿಸಿದ ಮೂಲ ವಿಳಾಸವನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಯಾವ ವಿನ್ಯಾಸ ನಿಜವಾಗಿ ಚಾಲನೆಯಲ್ಲಿದೆ ಎಂದು ಅದು ಹೇಳುತ್ತದೆ. ವಿಳಾಸದೊಂದಿಗೆ ಹೆಸರಿನ ಹುಡುಕಾಟವನ್ನೂ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ರಿಝಾಲ್ವರ್ನ ವರ್ತನೆ ಅದೇ ಪೆಟ್ಟಿಗೆಯ ಮೂಲಕ ಹೋಗುವ ಪ್ರತ್ಯೇಕ ಮಾರ್ಗ.
ಸುರಂಗ ಅಗತ್ಯವಿರುವ ಕ್ಲೈಂಟ್ ನೆಟ್ವರ್ಕ್ಗಳಿಗೆ ನಿಯಮಗಳನ್ನು ಸೀಮಿತಗೊಳಿಸಿ ಇರಿಸಿ, ಮತ್ತು ಒಂದು ಪರೀಕ್ಷೆ ಉತ್ತೀರ್ಣವಾಗಲು ಫಾರ್ವರ್ಡಿಂಗ್ ಫಿಲ್ಟರ್ ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದನ್ನು ವಿರೋಧಿಸಿ. ಆ ಬದಲಾವಣೆ ಪರೀಕ್ಷೆಯನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ ಮತ್ತು ಸುರಂಗ ಒದಗಿಸಬೇಕಿದ್ದ ಗಡಿಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ. ಮೂಲ ವಿಳಾಸ, ಅನುವಾದದ ನಿರ್ಧಾರ ಮತ್ತು ಹಿಂತಿರುಗು ಮಾರ್ಗವನ್ನು ದಿನಾಂಕದೊಂದಿಗೆ ಒಂದೇ ಟಿಪ್ಪಣಿಯಲ್ಲಿ ಬರೆಯಿರಿ.