ಮೂಲ-ಪೋರ್ಟ್ ನಿಯಮವು ನಿಮ್ಮ ಒಂದು SSH ಮಾರ್ಗವನ್ನು ಏಕೆ ಮುರಿಯುತ್ತದೆ

ಒಂದೇ ಹೋಸ್ಟ್ನಲ್ಲಿ ಎರಡು ನಿರ್ವಹಣಾ ಪ್ರವೇಶಗಳು, ಒಂದು ಸೇವಾ ಪೋರ್ಟ್, ಮತ್ತು ಎರಡಕ್ಕೂ ಸಹಾಯ ಮಾಡಬೇಕಿದ್ದ ನೀತಿ ನಿಯಮ. ನಿಯಮವು ಮೂಲ ಪೋರ್ಟ್ 22 ಗೆ ಹೊಂದುತ್ತದೆ, ಹುಡುಕಾಟವನ್ನು WAN ಡೀಫಾಲ್ಟ್ ಮಾತ್ರ ತಿಳಿದಿರುವ ಟೇಬಲ್ಗೆ ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ನೇರ ಪ್ರವೇಶವು ಕೆಲಸ ಮಾಡುತ್ತಿರುವಾಗ VPN ಪ್ರವೇಶವು ಹೊಸ ಲಾಗಿನ್ಗಳಿಗೆ ಉತ್ತರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. ಸೆಲೆಕ್ಟರ್ ಸರಿಯಾಗಿ ಓದಿದ ನಂತರ ಇದರಲ್ಲಿ ಏನೂ ನಿಗೂಢವಿಲ್ಲ. ಮೂಲ ಪೋರ್ಟ್ ಸೇವೆಯನ್ನು ಗುರುತಿಸುತ್ತದೆ, ಸಂಪರ್ಕ ಬಂದ ಮಾರ್ಗವನ್ನಲ್ಲ.

ಎರಡು ಪ್ರವೇಶಗಳು, ಒಂದು ಸೇವಾ ಪೋರ್ಟ್

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

ಈ ವ್ಯತ್ಯಾಸವು ಉತ್ತರದ ಮಾರ್ಗವನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಸಾಕು, ಮತ್ತು ಪೋರ್ಟ್ ಆಧಾರಿತ ನಿಯಮವು ಬಿಟ್ಟುಬಿಡುವ ವ್ಯತ್ಯಾಸವೂ ಇದೇ. ಎರಡೂ ಸೆಷನ್ಗಳು ಮೂಲ ಪೋರ್ಟ್ 22 ಇರುವ ಉತ್ತರಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಆ ಪೋರ್ಟ್ಗೆ ಹೊಂದುವ ನಿಯಮ ಅವನ್ನು ಬೇರ್ಪಡಿಸಲಾರದು. ಅದು ಎರಡೂ ಹುಡುಕಾಟಗಳನ್ನು ಒಂದೇ ಟೇಬಲ್ಗೆ ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದು ಹೊಂದಿಕೆಯಾಗದ ಉತ್ತರವನ್ನು ಪಡೆಯುತ್ತದೆ. ಪರಿಹಾರವೆಂದರೆ ನಿಜವಾಗಿ ಭಿನ್ನವಾಗಿರುವ ಗುಣಲಕ್ಷಣಕ್ಕೆ ಹೊಂದಿಸುವುದು.

ಪ್ರತಿ ಪ್ರವೇಶಕ್ಕೂ ಅದರದೇ ಪೋರ್ಟ್ ನೀಡುವುದೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಅದನ್ನು ಅಗತ್ಯವೆಂದು ಪರಿಗಣಿಸುವುದು SSH ನ ಗುಣವಲ್ಲ, ವಿನ್ಯಾಸದ ಆಯ್ಕೆ.

ನಿಯಮವನ್ನು ಓದಿ, ನಂತರ ಟೇಬಲ್

ನೀತಿ ನಿಯಮವು ಕ್ರಮಬದ್ಧ ಸೆಲೆಕ್ಟರ್, ಮತ್ತು ಉಪಯುಕ್ತ ಉತ್ತರ ನೀಡುವ ಮೊದಲ ನಿಯಮ ಹುಡುಕಾಟವನ್ನು ಮುಗಿಸುತ್ತದೆ. ಪಟ್ಟಿಯನ್ನು ಕ್ರಮವಾಗಿ ಓದಿ ಮತ್ತು ಯಾವ ನಿಯಮ ಗೆಲ್ಲಬಹುದೆಂದು ಗಮನಿಸಿ.

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

ip -4 rule show
ip route show table 100
ip route show table main

ಈ ಎರಡೂ ಔಟ್ಪುಟ್ಗಳು ಒಟ್ಟಾಗಿ ಫಲಿತಾಂಶವನ್ನು ವಿವರಿಸುತ್ತವೆ; ಅವುಗಳಲ್ಲಿ ಒಂದೊಂದೂ ಒಂಟಿಯಾಗಿ ತಪ್ಪು ತೀರ್ಮಾನಕ್ಕೆ ಆಹ್ವಾನಿಸುತ್ತದೆ.

ನಿಯಮವನ್ನು ನೀವು ಉದ್ದೇಶಿಸಿದ ಹರಿವಿಗೆ ಸೀಮಿತಗೊಳಿಸಿ

ಎರಡು ಪ್ರವೇಶಗಳನ್ನು ಬೇರ್ಪಡಿಸುವ ಗುಣಲಕ್ಷಣ ಸ್ಥಳೀಯ ಮೂಲ ವಿಳಾಸ. ಆ ವಿಳಾಸಕ್ಕೆ ಹೊಂದುವ ನಿಯಮ ಸುರಂಗ ಸೆಷನ್ಗಳನ್ನು ಮಾತ್ರ ಖಾಸಗಿ ಟೇಬಲ್ಗೆ ಕಳುಹಿಸುತ್ತದೆ ಮತ್ತು ನೇರ ಸೆಷನ್ಗಳನ್ನು ಮುಖ್ಯ ಟೇಬಲ್ನಲ್ಲಿ ಬಿಡುತ್ತದೆ.

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

sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1

ಎರಡೂ ಪ್ರವೇಶಗಳನ್ನು ಒಂದೇ ಸ್ಥಳೀಯ ವಿಳಾಸಕ್ಕೆ ಅನುವಾದಿಸಿದರೆ, ಆ ಭೇದ ಕಣ್ಮರೆಯಾಗುತ್ತದೆ ಮತ್ತು ವಿನ್ಯಾಸಕ್ಕೆ ಬದಲಾಗಿ ಸಂಪರ್ಕ-ಅರಿವಿನ ಸ್ಥಿತಿ ಬೇಕು.

ಶ್ರೋತೃ, ಅನುಮತಿ ಮತ್ತು ಉತ್ತರ-ಆಯ್ಕೆಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ

ಸೆಷನ್ ಕೆಲಸ ಮಾಡುವ ಮೊದಲು ಮೂರು ಪ್ರತ್ಯೇಕ ವಿಷಯಗಳು ನಿಜವಾಗಿರಬೇಕು: ವಿಳಾಸ ಇದೆ, ಸೇವೆ ಅದರ ಮೇಲೆ ಕೇಳುತ್ತದೆ, ಮತ್ತು ಉತ್ತರವು ಹಿಂತಿರುಗುವ ದಾರಿ ಕಂಡುಕೊಳ್ಳುತ್ತದೆ. ಮಾರ್ಗ ಬದಲಾವಣೆ ಮೂರನೆಯದನ್ನು ಮಾತ್ರ ಸರಿಪಡಿಸುತ್ತದೆ.

ಶ್ರೋತೃ ಸಂರಚನೆ ತನ್ನದೇ ಫೈಲ್ ಮತ್ತು ತನ್ನದೇ ಮರುಲೋಡ್, ಮತ್ತು ಹಲವು ಆಲಿಸುವ ವಿಳಾಸಗಳು ಸಾಮಾನ್ಯ. ದೃಢೀಕರಣ ಮತ್ತೆ ಮೂರನೇ ನಿರ್ಧಾರ, ಮತ್ತು ರೂಟಿಂಗ್ ವಿನಾಯಿತಿ ಯಾರಿಗೂ ಪ್ರವೇಶ ನೀಡುವುದಿಲ್ಲ. ಎರಡೂ ಪ್ರವೇಶಗಳಲ್ಲಿ ಹೋಸ್ಟ್-ಕೀ ಪರಿಶೀಲನೆ, ಖಾತೆ ದೃಢೀಕರಣ ಮತ್ತು ಮೂಲ ನಿರ್ಬಂಧಗಳನ್ನು ಇರಿಸಿ, ಮತ್ತು ಒಂದು ನಿರ್ವಹಣಾ ಮಾರ್ಗ ಕೆಲಸ ಮಾಡಲು ಸುರಂಗದ ಇತರ ನಿಯಂತ್ರಣಗಳನ್ನು ದುರ್ಬಲಗೊಳಿಸುವ ಪ್ರಲೋಭನೆಯನ್ನು ನಿರೋಧಿಸಿ.

ನೀವು ಬದಲಿಸುತ್ತಿರುವ ಮಾರ್ಗವನ್ನು ಅವಲಂಬಿಸದ ಚೇತರಿಕೆ ಚಾನಲ್ ಇರಿಸಿ, ಏಕೆಂದರೆ ಇಲ್ಲಿನ ತಪ್ಪು ಸರಿಪಡಿಸುವಿಕೆಯನ್ನೇ ಲಾಕ್ ಮಾಡುತ್ತದೆ.

ಇದನ್ನು ಹೊಸ ಸೆಷನ್ ಮೂಲಕ ಸಾಬೀತುಪಡಿಸಿ, ಹಳೆಯದರಿಂದಲ್ಲ

ಸ್ಥಾಪಿತ ಟರ್ಮಿನಲ್ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಅದು ಬದಲಾವಣೆಗೆ ಮೊದಲೇ ಅನುಮತಿಸಲ್ಪಟ್ಟಿತು. ಪ್ರತಿ ಉದ್ದೇಶಿತ ಪ್ರವೇಶದ ಮೂಲಕ ಹೊಸ ಸೆಷನ್ ತೆರೆಯಿರಿ.

ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30

ನಂತರ VPN ಮರುಸಂಪರ್ಕವನ್ನು ಪುನರಾವರ್ತಿಸಿ ಮತ್ತು ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಿ, ಏಕೆಂದರೆ ಮರುಸಂಪರ್ಕವನ್ನು ತಾಳಿಕೊಳ್ಳುವ ಮಾರ್ಗವು ಮರುಸಂಪರ್ಕ ಖಾಲಿ ಮಾಡುವ ಟೇಬಲ್ಗೆ ಸೇರಿಸಿದ ಮಾರ್ಗದಂತೆಯೇ ಅಲ್ಲ. ನಿರಾಕರಿಸಲ್ಪಟ್ಟ ಮೂಲಗಳನ್ನು ಅನುಮತಿಸಲ್ಪಟ್ಟವುಗಳಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಗಮನಿಸಿ, ತಡೆಯಲ್ಪಟ್ಟ ಪ್ರಯತ್ನವು ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಸೆಷನ್ ಹಿಂದೆ ಅಡಗದಂತೆ. ಫಲಿತಾಂಶದ ಪಕ್ಕದಲ್ಲಿ ಸ್ಥಳೀಯ ವಿಳಾಸ, ನಿಯಮ ಮತ್ತು ಟೇಬಲ್ ಉಳಿಸಿ. ಬದಲಾಗಿ ಪೋರ್ಟ್ಗಳನ್ನು ವಿಭಜಿಸಿದರೆ, ಅದನ್ನು SSH ನ ಮಿತಿಯಲ್ಲ, ಕಾರ್ಯಾಚರಣಾ ನಿರ್ಧಾರವಾಗಿ ದಾಖಲಿಸಿ.