VPN ಸಂಪರ್ಕಗೊಂಡಿದೆ ಆದರೆ ಫೈರ್‌ವಾಲ್ ಇನ್ನೂ ತಡೆಯುತ್ತಿದೆ: ಯಾವುದು ಎಂದು ಹೇಗೆ ತಿಳಿಯುವುದು
ಟನೆಲ್ ಚಾಲನೆಯಲ್ಲಿದೆ ಮತ್ತು ಒಂದು ಪೋರ್ಟ್ ಇನ್ನೂ ವಿಫಲವಾಗುತ್ತಿದೆ. ಮೊದಲು ಮಾರ್ಗವನ್ನು ಓದಿ, ನಂತರ ಪ್ರತಿ ಪದರದ ನೀತಿಯನ್ನು, ಮತ್ತು ಎರಡು ನಿಯಂತ್ರಣಗಳಲ್ಲಿ ಒಂದನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವ ಬದಲು ಅತ್ಯಂತ ಸಣ್ಣ ನಿಯಮವನ್ನು ಬದಲಿಸಿ.
ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಗೊಂಡಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಸಂಪನ್ಮೂಲ ಇನ್ನೂ ನಿರಾಕರಿಸುತ್ತದೆ, ಮತ್ತು ಸಾಮಾನ್ಯ ಮುಂದಿನ ಹೆಜ್ಜೆ ಏನನ್ನಾದರೂ ಆಫ್ ಮಾಡುವುದು. ಆ ವಾಕ್ಯದ ಎರಡು ನಿಯಂತ್ರಣಗಳು ಬೇರೆ ಬೇರೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ: VPN ಆವರಿಸಿದ ಸಂಚಾರಕ್ಕೆ ಮಾರ್ಗವನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ, ಮತ್ತು ಫೈರ್‌ವಾಲ್ ಪ್ರತಿ ಸಂಪರ್ಕಕ್ಕೂ ಸಂಚಾರವು ಹಾದುಹೋಗಬಹುದೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. ನಿರಾಕರಿಸುವ ನೀತಿಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಟನೆಲ್ ಬಳಕೆದಾರರ ಕುರ್ಚಿಯಿಂದ ಮುರಿದ ಟನೆಲ್‌ನಂತೆಯೇ ಕಾಣುತ್ತದೆ, ಆದ್ದರಿಂದ ಕೆಲಸ ಯಾವ ಪದರ ಉತ್ತರಿಸುತ್ತಿದೆ ಎಂದು ಕಂಡುಹಿಡಿಯುವುದು. ನಾನು ಅನುಸರಿಸುವ ಕ್ರಮ ಇಲ್ಲಿದೆ, ನಿಲ್ಲಿಸಲು ಹೇಳುವ ಓದುವಿಕೆಯೊಂದಿಗೆ.
ಮಾರ್ಗವನ್ನು ನೀತಿಯಿಂದ ಬೇರ್ಪಡಿಸಿ
ವೈಫಲ್ಯದ ಆಕಾರದಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಏಕೆಂದರೆ ಅದು ಉಚಿತ ಮಾಹಿತಿ. ಪ್ಯಾಕೆಟ್ ಬೀಳುವಿಕೆ ಸಮಯ ಮಿತಿಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ: ಕ್ಲೈಂಟ್ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುತ್ತದೆ, ಏನೂ ಹಿಂತಿರುಗುವುದಿಲ್ಲ, ಮತ್ತು ಆಜ್ಞೆ ಬಿಟ್ಟುಕೊಡುವವರೆಗೆ ನೇತಾಡುತ್ತದೆ. ನಿರಾಕರಣೆ ನಿರಾಕರಣೆ ಅಥವಾ ಮರುಹೊಂದಿಸುವಿಕೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ: ಏನೋ ಉತ್ತರಿಸಿ ಇಲ್ಲ ಎಂದಿತು. ಕೇಳದ ಸೇವೆ ಹೋಸ್ಟ್‌ನಲ್ಲಿಯೇ ನಿರಾಕರಿಸುತ್ತದೆ, ಯಾವುದೇ ಫೈರ್‌ವಾಲ್ ಇಲ್ಲದೆ.
ಆ ಮೂರು ಫಲಿತಾಂಶಗಳು ಬೇರೆ ಬೇರೆ ಪದರಗಳನ್ನು ಸೂಚಿಸುತ್ತವೆ. ಸಮಯ ಮಿತಿ ಎಂದರೆ ಎಲ್ಲೋ ಒಂದು ನೀತಿ ಸದ್ದಿಲ್ಲದೆ ಬಿಸಾಡುತ್ತಿದೆ, ಅಥವಾ ಮಾರ್ಗ ಎಂದಿಗೂ ಯಂತ್ರವನ್ನು ಬಿಡುವುದಿಲ್ಲ. ನಿರಾಕರಿಸಲಾಗಿದೆ ಎಂದರೆ ನೀವು ಹೋಸ್ಟ್ ತಲುಪಿದ್ದೀರಿ ಮತ್ತು ಅದರ ಸ್ಟಾಕ್ ಅಥವಾ ಅದರ ಸ್ಥಳೀಯ ಫೈರ್‌ವಾಲ್ ನಿರಾಕರಿಸಿತು. ಸಂಪೂರ್ಣ ಮೌನ, ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್ ಮೇಲಿದ್ದು ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಮಾರ್ಗವಿಲ್ಲದಿದ್ದರೆ, ಮಾರ್ಗ ತಪ್ಪಾಗಿದೆ ಮತ್ತು ಯಾವುದೇ ಫೈರ್‌ವಾಲ್ ನಿಯಮ ಅದನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ.
ಮಾರ್ಗವನ್ನು ಒಂದೇ ಹಾದಿಯಲ್ಲಿ ಓದಿ
ಒಂದು ನಿಯಮವನ್ನೂ ನೋಡುವ ಮೊದಲು ಟನೆಲ್ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಆವರಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಕಚೇರಿ ಉಪಜಾಲವನ್ನು ಮಾತ್ರ ಸಾಗಿಸುವ ವಿಭಜಿತ ಟನೆಲ್ ಬೇರೆ ಶ್ರೇಣಿಗೆ ವಿನಂತಿಯನ್ನು ತಿರುಗಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಆಗ ವೈಫಲ್ಯ ಫೈರ್‌ವಾಲ್ ತಡೆಯಂತೆ ಕಾಣುತ್ತದೆ, ಅದು ಹಾಗಲ್ಲ:
ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusallಮಾರ್ಗದ ಔಟ್‌ಪುಟ್ ಪ್ಯಾಕೆಟ್ ಯಾವ ಇಂಟರ್ಫೇಸ್‌ನಿಂದ ಹೊರಡುತ್ತದೆ ಮತ್ತು ಯಾವ ಮೂಲ ವಿಳಾಸವನ್ನು ಹೊರುತ್ತದೆ ಎಂದು ಹೇಳುತ್ತದೆ. ಆ ಇಂಟರ್ಫೇಸ್ ಟನೆಲ್ ಅಲ್ಲದೆ ನಿಮ್ಮ ಭೌತಿಕ ನೆಟ್‌ವರ್ಕ್ ಕಾರ್ಡ್ ಆಗಿದ್ದರೆ, ಸಮಸ್ಯೆ ಮಾರ್ಗನಿರ್ದೇಶನದಲ್ಲಿದೆ ಅಥವಾ ಟನೆಲ್‌ನ ಅನುಮತಿಸಿದ ಶ್ರೇಣಿಗಳಲ್ಲಿದೆ, ಮತ್ತು ಅದು ಫೈರ್‌ವಾಲ್‌ಗಲ್ಲ, VPN ಸಂರಚನೆಗೆ ಸೇರುತ್ತದೆ.
VPN-ಗೆ ವಿಶಿಷ್ಟವಾದ ಒಂದು ಬಲೆ ತನ್ನದೇ ಪರಿಶೀಲನೆಗೆ ಅರ್ಹವಾಗಿದೆ. WireGuard ನಲ್ಲಿ ಪೀರ್‌ನ AllowedIPs ಒಂದೇ ಸಮಯದಲ್ಲಿ ಮಾರ್ಗ ಮತ್ತು ಗುಪ್ತಲೇಖನ ಫಿಲ್ಟರ್ ಆಗಿದೆ: ಮೂಲ ವಿಳಾಸವು ಪೀರ್‌ನ ಅನುಮತಿಸಿದ ಗುಂಪಿಗೆ ಹೊಂದಿಕೆಯಾಗದ ಪ್ಯಾಕೆಟ್ ಯಾವುದೇ ಫೈರ್‌ವಾಲ್ ನಿಯಮವನ್ನು ನೋಡುವ ಮೊದಲೇ ಬಿಸಾಡಲ್ಪಡುತ್ತದೆ. ಆದ್ದರಿಂದ ಸಂಪೂರ್ಣ ಸರಿಯಾದ ಹೋಸ್ಟ್ ಫೈರ್‌ವಾಲ್ ನೀತಿಯಂತೆ ಕಾಣುವ ಮೌನ ಬಿಸಾಡುವಿಕೆಯ ಹಿಂದೆ ಇರಬಹುದು, ಮತ್ತು ಪರಿಹಾರ ನಿಯಮವಲ್ಲ, ಕೀ ಸಂರಚನೆಯ ಒಂದು ಸಾಲು.
ಉತ್ತರಿಸುವ ಪದರದಲ್ಲಿ ನೀತಿಯನ್ನು ಓದಿ
ಮಾರ್ಗ ಸರಿಯಾದ ನಂತರ, ಹೋಸ್ಟ್‌ನಿಂದ ಹೊರಕ್ಕೆ ನೀತಿಯನ್ನು ನಡೆಯಿರಿ ಮತ್ತು ಕೌಂಟರ್‌ಗಳು ಚಲಿಸುವ ಒಂದೇ ಪದರವನ್ನು ಗಮನಿಸಿ:
ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verboseಕೇಳುತ್ತಿರುವ ಸಾಕೆಟ್ ನಿಯಮಗಳಿಗಿಂತ ಬೇರೆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ. ಪೋರ್ಟ್‌ನಲ್ಲಿ ಏನೂ ಕೇಳದಿದ್ದರೆ, ಕರ್ನಲ್ ಸಂಪರ್ಕವನ್ನು ನಿರಾಕರಿಸುತ್ತದೆ ಮತ್ತು ಯಾವುದೇ ಒಳಬರುವ ನಿಯಮ ಸಂಬಂಧಿತವಲ್ಲ. ಸಾಕೆಟ್ ಇದ್ದು ದೂರದ ಕ್ಲೈಂಟ್‌ನಿಂದ ಸಂಪರ್ಕ ಸಮಯ ಮೀರಿದರೆ, ಮಾರ್ಗದಲ್ಲಿ ಎಲ್ಲೋ ಬಿಸಾಡುವಿಕೆ ನಡೆಯುತ್ತಿದೆ, ಮತ್ತು ನಿಯಮಗಳ ಕೌಂಟರ್‌ಗಳು ಅದು ಇಲ್ಲಿಯೇ ನಡೆಯುತ್ತಿದೆಯೇ ಎಂದು ಹೇಳುತ್ತವೆ.
ಹೊರಗಿನಿಂದ ಊಹಿಸುವ ಬದಲು ನೀವು ಸಂಶಯಿಸುವ ಪ್ರೊಫೈಲ್ ಅಥವಾ ಸರಪಳಿಗೆ ಲಾಗಿಂಗ್ ಆನ್ ಮಾಡಿ. ಮೂಲ, ಗಮ್ಯಸ್ಥಾನ ಮತ್ತು ಪೋರ್ಟ್ ಹೆಸರಿಸುವ ಒಂದೇ ದಾಖಲಾದ ಬಿಸಾಡುವಿಕೆ ಪದರ ಮತ್ತು ನಿಯಮವನ್ನು ಗುರುತಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ಯಾಕೆಟ್ ಬಂದಿತು ಎಂಬುದನ್ನೂ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಇದನ್ನು ಕ್ಲೈಂಟ್ ಬದಿಯ ಯಾವುದೇ ಪರೀಕ್ಷೆ ಸ್ಥಾಪಿಸಲಾರದು.
ಟನೆಲ್ ಅಲ್ಲಿಯೇ ಮುಗಿದಾಗ ಗೇಟ್‌ವೇಯ ನಿರ್ಧಾರವನ್ನು ಓದಿ
ಸೈಟ್-ಟು-ಸೈಟ್ ಅಥವಾ ದೂರಸ್ಥ ಪ್ರವೇಶ ಗೇಟ್‌ವೇಯಲ್ಲಿ, VPN ಬಳಕೆದಾರರನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ ಮತ್ತು ನೀತಿ ಸಂಪನ್ಮೂಲವನ್ನು ಅಧಿಕೃತಗೊಳಿಸುತ್ತದೆ, ಮತ್ತು ಅವು ಪ್ರತ್ಯೇಕ ಅನುಮತಿಗಳು. ಟನೆಲ್‌ಗೆ ಪ್ರವೇಶ ಪಡೆದ ಬಳಕೆದಾರರಿಗೆ ಪ್ರತಿ ಆಂತರಿಕ ಹೋಸ್ಟ್‌ಗೂ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪ್ರವೇಶ ಸಿಗುವುದಿಲ್ಲ, ಮತ್ತು ನಿರಾಕರಣೆ ಸಾಮಾನ್ಯವಾಗಿ ಟನೆಲ್ ಸ್ವತಃ ಆರೋಗ್ಯವಾಗಿರುವಾಗ ಫಾರ್ವರ್ಡಿಂಗ್ ನಿಯಮದಿಂದ ಬರುತ್ತದೆ. ಅದೇ ಬೇರ್ಪಡುವಿಕೆ IPsec ನಲ್ಲೂ ಕಾಣುತ್ತದೆ, ಅಲ್ಲಿ ಸಂಚಾರವನ್ನು ಆಯ್ಕೆಮಾಡುವ ಭದ್ರತಾ ನೀತಿ ಅದನ್ನು ಒಳಗೆ ಬಿಡುವ ಫಿಲ್ಟರ್‌ಗಿಂತ ಭಿನ್ನವಾಗಿದೆ, ಮತ್ತು ಆದ್ದರಿಂದ ಎರಡನ್ನೂ ವಿಭಿನ್ನ ಕಾರ್ಯವಿಧಾನಗಳಾಗಿ RFC 4301.
ಹಿಂದಿರುಗುವ ಮಾರ್ಗವನ್ನು ಹೋಗುವ ಮಾರ್ಗದಷ್ಟೇ ಎಚ್ಚರಿಕೆಯಿಂದ ಪರಿಶೀಲಿಸಿ. ಸ್ಥಿತಿ ಫಿಲ್ಟರಿಂಗ್ ಉತ್ತರವನ್ನು ನೋಡಬೇಕು, ಆದ್ದರಿಂದ ಟನೆಲ್ ಮೂಲಕ ಒಂದು ದಿಕ್ಕಿನಲ್ಲಿ ಮತ್ತು ಅದರ ಸುತ್ತಲೂ ಇನ್ನೊಂದು ದಿಕ್ಕಿನಲ್ಲಿ ಅಸಮ್ಮಿತ ಮಾರ್ಗನಿರ್ದೇಶನವು ಯಾದೃಚ್ಛಿಕವೆನಿಸುವ ಮತ್ತು ಕೆಲವು ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಮಾತ್ರ ಪುನರಾವರ್ತನೆಯಾಗುವ ಬಿಸಾಡುವಿಕೆಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಸಂಚಾರ ಗೇಟ್‌ವೇ ತಲುಪಿ ನಿಂತರೆ, ಏನನ್ನೂ ವಿಸ್ತರಿಸುವ ಮೊದಲು ಫಾರ್ವರ್ಡಿಂಗ್ ನಿಯಮ ಮತ್ತು ಹಿಂದಿರುಗುವ ಮಾರ್ಗವನ್ನು ಜೊತೆಯಾಗಿ ಓದಿ.
ಗೇಟ್‌ವೇ ಎಂಬುದು NAT ಅಥವಾ ಮಾಸ್ಕರೇಡ್ ನಿಯಮ ನಿಜವಾದ ಮೂಲವನ್ನು ಮರೆಮಾಡಬಹುದಾದ ಸ್ಥಳವೂ ಆಗಿದೆ. ಆಂತರಿಕ ಹೋಸ್ಟ್‌ಗಳು ಕ್ಲೈಂಟ್ ಬದಲು ಗೇಟ್‌ವೇ ವಿಳಾಸವನ್ನು ನೋಡಿದರೆ, ಕ್ಲೈಂಟ್ ಪೂಲ್‌ಗೆ ಹೊಂದಿಕೆಯಾಗಬೇಕಾದ ಅವರ ಹೋಸ್ಟ್ ಫೈರ್‌ವಾಲ್ ನಿಯಮಗಳು ಎಂದಿಗೂ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ, ಮತ್ತು ಪರಿಹಾರ ಪ್ರತಿ ಸರ್ವರ್‌ನಲ್ಲ, ಗೇಟ್‌ವೇಯಲ್ಲಿದೆ.
ಅತ್ಯಂತ ಸಣ್ಣ ಪದರವನ್ನು ಬದಲಿಸಿ, ನಂತರ ಪರಿಶೀಲಿಸಿ
ವಿಶಾಲ ರಿಪೇರಿಯನ್ನು ವಿರೋಧಿಸಿ. ಹೋಸ್ಟ್ ಫೈರ್‌ವಾಲ್ ಆಫ್ ಮಾಡುವುದು, ಎಲ್ಲವನ್ನೂ ಅನುಮತಿಸುವ ನಿಯಮ ಸೇರಿಸುವುದು, ಅಥವಾ ಪ್ರತಿ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ವಿಶ್ವಾಸಾರ್ಹ ಪ್ರೊಫೈಲ್‌ಗೆ ತಳ್ಳುವುದು — ಪ್ರತಿಯೊಂದೂ ತನ್ನ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದ ನಿಯಂತ್ರಣವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ, ಮತ್ತು ಬದಲಾವಣೆ ಘಟನೆಯ ನಂತರವೂ ಉಳಿಯುತ್ತದೆ. ಮೂಲ ಶ್ರೇಣಿ ಮತ್ತು ಸಂಬಂಧಿತ ಪೋರ್ಟ್‌ಗೆ ಸೀಮಿತವಾದ ನಿಯಮವನ್ನು ಪರಿಶೀಲಿಸುವುದು ಸುಲಭ, ತೆಗೆದುಹಾಕುವುದು ಸುಲಭ, ಮತ್ತು ಯಂತ್ರದ ಉಳಿದ ನೀತಿಯನ್ನು ಅಕ್ಷತವಾಗಿ ಬಿಡುತ್ತದೆ.
ವಿಫಲವಾದ ಅದೇ ಪರೀಕ್ಷೆಯಿಂದ, ಅದೇ ಕ್ಲೈಂಟ್‌ನಿಂದ ಪರಿಶೀಲಿಸಿ, ನಂತರ ಮತ್ತೆ ಸಂಪರ್ಕಗೊಂಡ ಮೇಲೆ ಇನ್ನೊಮ್ಮೆ, ಏಕೆಂದರೆ ಟನೆಲ್ ಮರುಸಂಧಾನಕ್ಕೆ ಮೊದಲು ಹೊಂದಿಕೆಯಾಗುತ್ತಿದ್ದ ನಿಯಮ ನಂತರ ಹೊಂದಿಕೆಯಾಗದೇ ಇರಬಹುದು:
nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/ಅದನ್ನು ಮುಚ್ಚುವ ಮೊದಲು:
- ಗಮ್ಯಸ್ಥಾನದ ಮಾರ್ಗ ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್‌ನಿಂದ ಹೊರಡುತ್ತದೆ, ಮತ್ತು ಮೂಲ ವಿಳಾಸ ನೀತಿ ನಿರೀಕ್ಷಿಸುವುದಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ.
- ಪೋರ್ಟ್‌ನಲ್ಲಿ ಏನೋ ಕೇಳುತ್ತಿದೆ, ಮತ್ತು ನಿರಾಕರಣೆ ಅಥವಾ ಸಮಯ ಮಿತಿ ಊಹೆಯಲ್ಲ, ಹೆಸರಿಸಿದ ನಿಯಮಕ್ಕೆ ಆರೋಪಿಸಲಾಗಿದೆ.
- ಗೇಟ್‌ವೇ ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಮುಂದಕ್ಕೆ ಸಾಗಿಸುತ್ತದೆ, ಮತ್ತು ಗಮ್ಯಸ್ಥಾನ ನಿಮ್ಮ ನಿಯಮಗಳನ್ನು ಬರೆದ ಮೂಲವನ್ನು ನೋಡುತ್ತದೆ.
- ಪರೀಕ್ಷೆ ಪಾಸಾಗಲು ಯಾವುದೇ ನಿಯಂತ್ರಣ ಆಫ್ ಮಾಡಲಾಗಿಲ್ಲ, ಮತ್ತು ನೀವು ಮಾಡಿದ ಬದಲಾವಣೆ ಒಂದು ಮೂಲ ಶ್ರೇಣಿ ಮತ್ತು ಒಂದು ಪೋರ್ಟ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ.