VPN ಪೋರ್ಟ್ ತೆರೆಯುವುದರಿಂದ ಕ್ಲೈಂಟ್‌ಗಳು LAN ತಲುಪುವುದಿಲ್ಲ

ಟನೆಲ್ ಮೇಲೇರುತ್ತದೆ, ಕ್ಲೈಂಟ್ ದೃಢೀಕರಣಗೊಳ್ಳುತ್ತದೆ, ಆದರೆ ಗೇಟ್‌ವೇ ಹಿಂದಿನ LAN ಕಾಣದೇ ಉಳಿಯುತ್ತದೆ. ಇದನ್ನು ಸರಿಪಡಿಸಬೇಕಿದ್ದ ನಿಯಮವು VPN ಪೋರ್ಟ್‌ಗೆ ಅನುಮತಿ ನೀಡುತ್ತದೆ ಮತ್ತು ಬರೆದಂತೆಯೇ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಏಕೆಂದರೆ ಆ ನಿಯಮವು ಗೇಟ್‌ವೇಗೆ ತಾನೇ ವಿಳಾಸ ಮಾಡಿದ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ. ಗೇಟ್‌ವೇ ಹಿಂದಿನ ಹೋಸ್ಟ್‌ಗೆ ಹೋಗುವ ಕ್ಲೈಂಟ್ ಸಂಚಾರಕ್ಕೆ ಬೇರೆ ಗಮ್ಯ ಮತ್ತು ಬೇರೆ ಸರಪಳಿ ಇದೆ. ಯಶಸ್ವಿ ಲಾಗಿನ್ ಕರ್ನೆಲ್ ಯಾವ ಸರಪಳಿಯನ್ನು ನೋಡುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ.

ಎರಡು ಸರಪಳಿಗಳು, ಎರಡು ಬೇರೆ ಗಮ್ಯಗಳು

ಪ್ಯಾಕೆಟ್‌ನ ಗತಿ ಅದು ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂಬುದರಿಂದ ನಿರ್ಧಾರವಾಗುತ್ತದೆ, ಅದು ಹೇಗೆ ಬಂತು ಎಂಬುದರಿಂದ ಅಲ್ಲ. ಗೇಟ್‌ವೇಯಲ್ಲಿನ ವಿಳಾಸಕ್ಕೆ ಹೋಗುವ ಸಂಚಾರವು ಸ್ಥಳೀಯವಾಗಿ ತಲುಪಿಸಲ್ಪಟ್ಟು ಇನ್‌ಪುಟ್ ನಿಯಮಗಳಿಂದ ಮೌಲ್ಯಮಾಪನಗೊಳ್ಳುತ್ತದೆ. ಗೇಟ್‌ವೇ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಸಂಚಾರವು ಫಾರ್ವರ್ಡ್ ನಿಯಮಗಳಿಂದ ಮೌಲ್ಯಮಾಪನಗೊಳ್ಳುತ್ತದೆ. ಒಂದೇ ಟನೆಲ್ ಇಂಟರ್‌ಫೇಸ್ ಎರಡೂ ಬಗೆಯ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಉತ್ಪಾದಿಸಬಹುದು, ಆದ್ದರಿಂದ ಒಂದು ನಿಯಮ ಎರಡೂ ಕೆಲಸಗಳನ್ನು ಆವರಿಸಲಾರದು.

ಇಡೀ ಪುರಾಣ ಒಂದು ವಾಕ್ಯದಲ್ಲಿ: ಕೇಳುಗನಿಗೆ ಅನುಮತಿ ನೀಡುವುದು ಅವನ ಹಿಂದಿನ ಜಾಲಕ್ಕೆ ಅನುಮತಿ ನೀಡುವ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಇವು ಬೇರೆ ಬೇರೆ ಸಾಕ್ಷ್ಯಗಳಿರುವ ಎರಡು ಪ್ರತ್ಯೇಕ ನಿರ್ಧಾರಗಳು, ಮತ್ತು ಎರಡರ ಮೇಲೂ ಇಂಟರ್‌ಫೇಸ್ ಹೆಸರಿದ್ದರೂ ಅವು ಒಂದಾಗುವುದಿಲ್ಲ.

ಕೇಳುಗ ನಿಯಮವು ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ಅನುಮತಿಸುತ್ತದೆ

ಕೇಳುಗನ ಪ್ಯಾಕೆಟ್‌ಗಳು VPN ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತವೆ, ಮತ್ತು ಅದೇ ಟನೆಲ್ ಸ್ಥಾಪನೆಗೆ ಅವಕಾಶ ನೀಡುತ್ತದೆ. ಗೇಟ್‌ವೇಯ ನಿರ್ವಹಣಾ ಪುಟ ಮತ್ತು ಸ್ಥಳೀಯ ರೋಗನಿರ್ಣಯದ ಉತ್ತರವೂ ಹೋಸ್ಟ್‌ನದೇ ಇನ್‌ಪುಟ್ ಮಾರ್ಗವನ್ನು ಬಳಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಗೇಟ್‌ವೇಗೆ ಪರೀಕ್ಷೆ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ, ಅದರ ಹಿಂದಿನ ಎಲ್ಲವೂ ವಿಫಲವಾಗುತ್ತದೆ. ಎರಡೂ ಫಲಿತಾಂಶಗಳು ಸರಿ ಮತ್ತು ಯಾವುದೂ LAN ಬಗ್ಗೆ ಅಲ್ಲ.

ಪ್ರಕ್ರಿಯೆಯು ಬೇರೆ ಗಮ್ಯಕ್ಕಾಗಿ ಕ್ಲೈಂಟ್ ಸಂಚಾರವನ್ನು ಡೀಕ್ಯಾಪ್ಸುಲೇಟ್ ಮಾಡಿದಾಗ, ಪ್ಯಾಕೆಟ್ ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾರ್ಗಕ್ಕೆ ಪ್ರವೇಶಿಸಿ ಅಲ್ಲಿ ಅನುಮತಿ ಬೇಕಾಗುತ್ತದೆ. ಯಶಸ್ವಿ ದೃಢೀಕರಣವು ಕ್ಲೈಂಟ್ ಯಾರು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ; ಎಲ್ಲಿಗೆ ಹೋಗಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವುದಿಲ್ಲ. ಎರಡೂ ಪ್ರಶ್ನೆಗಳಿಗೆ ಬೇರೆ ಮಾಲೀಕರು, ಬೇರೆ ಲಾಗ್‌ಗಳು ಮತ್ತು ಬೇರೆ ದೋಷ ಸಂದೇಶಗಳಿವೆ.

ಕ್ಲೈಂಟ್‌ನಿಂದ ಪರೀಕ್ಷಿಸಿ, ಗೇಟ್‌ವೇಯಿಂದ ಎಂದಿಗೂ ಅಲ್ಲ

ಗೇಟ್‌ವೇಯಲ್ಲಿ ರಚಿಸಿದ ಪರೀಕ್ಷೆಯು ಹೋಸ್ಟ್‌ನದೇ ಔಟ್‌ಪುಟ್ ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸುತ್ತದೆ ಮತ್ತು ಫಾರ್ವರ್ಡ್ ಮಾರ್ಗ ಮುಚ್ಚಿದ್ದರೂ ಯಶಸ್ವಿಯಾಗಬಹುದು. ಪರೀಕ್ಷೆಯನ್ನು ಕ್ಲೈಂಟ್‌ನಿಂದ ಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಹರಿವಿನ ಎರಡೂ ತುದಿಗಳನ್ನು ನೋಡಿ.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

ವಿನಂತಿ tun0 ಮೇಲೆ ಕಾಣಿಸಿಕೊಂಡು ಗಮ್ಯಕ್ಕೆ ಏನೂ ತಲುಪದಿದ್ದರೆ, ಪ್ಯಾಕೆಟ್ ಬಂದ ನಂತರ ಬಿಸಾಡಲ್ಪಡುತ್ತದೆ, ಇದು ಫಾರ್ವರ್ಡ್ ನಿಯಮಗಳು ಅಥವಾ ಗಮ್ಯದ ಸ್ವಂತ ಫಿಲ್ಟರಿಂಗ್‌ಗೆ ಸೂಚಿಸುತ್ತದೆ. tun0 ಮೇಲೆ ಏನೂ ಕಾಣದಿದ್ದರೆ, ಕ್ಲೈಂಟ್ ಅದನ್ನು ಟನೆಲ್‌ಗೂ ಕಳುಹಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಸಮಸ್ಯೆ ಗೇಟ್‌ವೇಯ ನೀತಿಯಲ್ಲ, ಕ್ಲೈಂಟ್‌ನ ರೂಟಿಂಗ್‌ನಲ್ಲಿದೆ. ಸರಿಯಾಗಿ ಹೊರಟು ಏನನ್ನೂ ಹಿಂತಿರುಗಿಸದ ವಿನಂತಿಯೊಂದಿಗೆ ಇದನ್ನು ಹೋಲಿಸಿ, ಅದೇ ಹಿಂತಿರುಗುವ ಮಾರ್ಗದ ಸಂದರ್ಭ.

ಫಾರ್ವರ್ಡಿಂಗ್‌ಗೆ ಒಂದಲ್ಲ, ಮೂರು ವಸ್ತುಗಳು ಬೇಕು

ಕರ್ನೆಲ್ ಫಾರ್ವರ್ಡಿಂಗ್ ಸಕ್ರಿಯವಾಗಿರಬೇಕು, ಫಿಲ್ಟರ್ ನಿಯಮವು ಹರಿವನ್ನು ಸ್ವೀಕರಿಸಬೇಕು, ಮತ್ತು ಗಮ್ಯವನ್ನು ತಲುಪಬಹುದಾಗಿರಬೇಕು ಹಾಗೂ ಉತ್ತರ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವಿರಬೇಕು. ಮೂರರಲ್ಲಿ ಒಂದು ಇಲ್ಲದಿದ್ದರೆ ಕ್ಲೈಂಟ್ ದೃಷ್ಟಿಯಿಂದ ಅದೇ ಮೌನ.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

ಮೂರೂ ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ಒಟ್ಟಿಗೆ ಓದಿ. ಮೊದಲನೆಯದರಲ್ಲಿ ಶೂನ್ಯವಿದ್ದರೆ ಉಳಿದೆರಡು ಅಪ್ರಸ್ತುತ. ಎರಡನೆಯದರಲ್ಲಿ ಡೀಫಾಲ್ಟ್-ಡ್ರಾಪ್ ನೀತಿ ಇದ್ದರೆ ಕ್ಲೈಂಟ್ ಪ್ಯಾಕೆಟ್‌ಗಳು ಬಿಸಾಡಲ್ಪಡುತ್ತವೆ, ಗೇಟ್‌ವೇಯದೇ ಸಂಚಾರ ಮುಂದುವರಿಯುತ್ತದೆ. ಮೂರನೆಯ ಔಟ್‌ಪುಟ್ ಕೇಳುಗ ನಿಯಮ ಎಂದಿಗೂ ಸಮಸ್ಯೆಯಾಗಿರಲಿಲ್ಲ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.

ದಸ್ತಾವೇಜಿನಲ್ಲಿ ಎರಡೂ ನಿಯಮ ಗುಂಪುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ

ಕೇಳುಗ ನಿಯಮ ಮತ್ತು ಫಾರ್ವರ್ಡ್ ಮಾಡಿದ ಸೇವೆಯ ನಿಯಮವನ್ನು ಪ್ರತ್ಯೇಕ ಸಾಲುಗಳಲ್ಲಿ, ಪ್ರತ್ಯೇಕ ಮಾಲೀಕರು ಮತ್ತು ಕಾರಣಗಳೊಂದಿಗೆ ಬರೆಯಿರಿ. VPN ಪೋರ್ಟ್ ಬದಲಾದಾಗ ಅಥವಾ ಹೊಸ ಸೇವೆ ಪ್ರಕಟವಾದಾಗ, ಆ ಪ್ರತ್ಯೇಕತೆ ಒಂದು ಬದಲಾವಣೆ ಇನ್ನೊಂದನ್ನು ಮೌನವಾಗಿ ವಿಸ್ತರಿಸದಂತೆ ತಡೆಯುತ್ತದೆ.

ಪ್ರತಿ ದೃಢೀಕೃತ ಸಹಭಾಗಿಯನ್ನು ವಿಶ್ವಾಸಾರ್ಹ LAN ಸದಸ್ಯ ಎಂದು ಪರಿಗಣಿಸುವ ಬದಲು, ಅಗತ್ಯವಿರುವ ಕ್ಲೈಂಟ್ ಶ್ರೇಣಿಗಳು ಮತ್ತು ಸೇವೆಗಳಿಗೆ ಸಂಕುಚಿತ ನಿಯಮಗಳನ್ನು ಬಳಸಿ. StrongSwanನ ಫಾರ್ವರ್ಡಿಂಗ್ ಟಿಪ್ಪಣಿಗಳು ಅದೇ ಗಡಿಯ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಮತ್ತು ಅನುವಾದದ ಬದಿಯನ್ನು ವಿವರಿಸುತ್ತವೆ, ಅದು ಮತ್ತೆ ಮೂರನೆಯ ನಿರ್ಧಾರ.

ಕೊನೆಯದಾಗಿ, ಬಳಕೆದಾರನನ್ನು ನಿರಾಕರಿಸಿದಾಗ ಪದರಗಳನ್ನು ನೇರವಾಗಿ ಇರಿಸಿ. ವಿನಂತಿ ಹೋಸ್ಟ್ ತಲುಪಿ ಅಪ್ಲಿಕೇಶನ್ ಖಾತೆಯನ್ನು ನಿರಾಕರಿಸಿದರೆ, ಆ ಪದರದಲ್ಲೇ ಅಪ್ಲಿಕೇಶನ್ ಅನುಮತಿಯನ್ನು ಸರಿಪಡಿಸಿ; ಫಾರ್ವರ್ಡಿಂಗ್ ವಿಸ್ತರಿಸುವುದರಿಂದ ಫೈಲ್ ಹಂಚಿಕೆಯ ರುಜುವಾತು ಸಿಗದು ಮತ್ತು ಯಶಸ್ವಿಯಾಗಿ ಸಂಪರ್ಕಿಸುವ ಎಲ್ಲರಿಗೂ ಪ್ರವೇಶ ವಿಸ್ತರಿಸುತ್ತದೆ.