ಹೋಸ್ಟ್ ಹೊರಮುಖ VPN ಚಲಾಯಿಸುವಾಗ ಸ್ಥಳೀಯ SSH ಉಳಿಸಿಕೊಳ್ಳಿ

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

ಕೆಳಗಿನ ಹಂತಗಳು ನಿರ್ವಾಹಕರು ಅದೇ LAN ನಲ್ಲಿದ್ದಾರೆ ಎಂದು ಊಹಿಸುತ್ತವೆ.ದೂರಸ್ಥ ಆಡಳಿತವು ಬೇರೆ ಉತ್ತರವಿರುವ ಬೇರೆ ಸಮಸ್ಯೆ.

SSH ಅನ್ನು ನಿರ್ವಾಹಕರು ಬಳಸುವ ವಿಳಾಸಕ್ಕೆ ಬಂಧಿಸಿ

ಲಿಸನರ್ನಿಂದ ಪ್ರಾರಂಭಿಸಿ.ss -ltnp | grep :22 sshd ಯಾವುದಕ್ಕೆ ಬದ್ಧವಾಗಿದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು 0.0.0.0 ನಲ್ಲಿನ ಲಿಸನರ್ ಟನೆಲ್ ಸೇರಿದಂತೆ ಪ್ರತಿ interface ನಿಂದ ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ. LAN ವಿಳಾಸಕ್ಕೆ ಬಂಧಿಸುವುದು ಹೆಚ್ಚು ಸಂಕುಚಿತ ಮತ್ತು ಉದ್ದೇಶವನ್ನು ಗೋಚರವಾಗಿಸುತ್ತದೆ:ListenAddress 192.168.10.20 ಒಳಗೆsshd_config, ನಂತರ configuration ಪರೀಕ್ಷೆ ಮತ್ತು ಮರುಲೋಡ್. ಆ ವಿಳಾಸದಲ್ಲಿ ಟೈಪೋ wildcard ಗಿಂತ ಹೆಚ್ಚು ಗೋಚರವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ವಿಳಾಸವಿಲ್ಲದಿದ್ದಾಗ sshd ಪ್ರಾರಂಭವಾಗಲು ನಿರಾಕರಿಸುತ್ತದೆ.

host key ಪರಿಶೀಲನೆ ಮತ್ತು ಪ್ರತಿ ಬಳಕೆದಾರರ ದೃಢೀಕರಣವನ್ನು ಇರುವಂತೆಯೇ ಇಡಿ. “ಇದು ಸ್ಥಳೀಯ ನೆಟ್ವರ್ಕ್ ಮಾತ್ರ” ಎಂಬುದು ದೃಢೀಕರಣ ವಿಧಾನವಲ್ಲ, ಮತ್ತು ಮಾರ್ಗ ಚಿಕ್ಕದಾಗಿರುವುದರಿಂದ key ಪರಿಶೀಲನೆಯನ್ನು ಬಿಟ್ಟುಬಿಡುವ ನಿರ್ವಹಣಾ ಚಾನೆಲ್ ದುರುಪಯೋಗಕ್ಕಾಗಿ ಕಾಯುತ್ತಿರುವ ಚಾನೆಲ್. DHCP ಮೀಸಲಾತಿ ಅಥವಾ ಸ್ಥಿರ ವಿಳಾಸ ಗುರಿಯನ್ನು ಊಹಿಸಬಹುದಾದಂತೆ ಮಾಡುತ್ತದೆ, ಅದನ್ನು ಸರ್ವರ್ನ ಸಾರ್ವಜನಿಕ ಗುರುತಾಗಿ ಮಾಡದೆ.

LAN ಮಾರ್ಗವನ್ನು ಟನೆಲ್ನ ಹೊರಗೆ ಇಡಿ

192.168.10.0/24 ನಲ್ಲಿ ವಿಳಾಸವಿರುವ host ಗೆ ಆ prefix ಗಾಗಿ ಸಂಪರ್ಕಿತ ಮಾರ್ಗ ಇರುತ್ತದೆ, ಮತ್ತು ಅದೇ table ನಲ್ಲಿ ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟ ಮಾರ್ಗ VPN ನ default ಅನ್ನು ಸೋಲಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ ಟನೆಲ್ ಮೇಲೆ ಬಂದಾಗ ಸ್ಥಳೀಯ SSH ಹೆಚ್ಚಾಗಿ ತಾನಾಗಿಯೇ ಕೆಲಸ ಮಾಡುತ್ತಲೇ ಇರುತ್ತದೆ. ಊಹಿಸುವ ಬದಲು ಅದನ್ನು ಪರಿಶೀಲಿಸಿ:ip route get 192.168.10.50 kernel ಬಳಸುವ interface ಮತ್ತು ಮೂಲ ವಿಳಾಸವನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು ಉತ್ತರವು ಟನೆಲ್ ಅಲ್ಲ, LAN ಸಾಧನವಾಗಿರಬೇಕು. ನಿರ್ವಾಹಕರ ಯಂತ್ರದಿಂದಲೂ ಪರಿಶೀಲನೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ, ಏಕೆಂದರೆ packet ಗಳು ತಲುಪುತ್ತವೆಯೇ ಎಂಬುದನ್ನು ಅದರ ಸ್ವಂತ table ನಿರ್ಧರಿಸುತ್ತದೆ. ಒಂದೇ ತಂತಿಯಲ್ಲಿ ಇರುವ ಎರಡು host ಗಳು ಯಾವ ದಿಕ್ಕು ತಲುಪಬಹುದು ಎಂಬುದರಲ್ಲಿ ಭಿನ್ನಾಭಿಪ್ರಾಯ ಹೊಂದಬಹುದು.

ಊಹೆ ಎರಡು ಕಡೆ ಮುರಿಯುತ್ತದೆ. ನೀತಿ ಆಧಾರಿತ routing ನಿಯಮವು ಮುಖ್ಯ table ಅನ್ನು ನೋಡುವ ಮೊದಲೇ default ಟನೆಲ್ ಕಡೆ ತೋರಿಸುವ table ಗೆ traffic ಕಳುಹಿಸಬಹುದು. ಲಾಕ್ಡೌನ್ ಅಥವಾ kill switch ವೈಶಿಷ್ಟ್ಯವಿರುವ VPN ಕ್ಲೈಂಟ್ ಕೂಡ ಟನೆಲ್ ಗೆ ಪ್ರವೇಶಿಸದ traffic ಅನ್ನು ತಡೆಯಬಹುದು, routing table ಏನೇ ಹೇಳಿದರೂ.

routed ನಿರ್ವಹಣಾ VLAN ಗಳು ಇನ್ನೊಂದು ಪ್ರಕರಣ. ನಿರ್ವಾಹಕರು ಸ್ಥಳೀಯ router ನ ಹಿಂದೆ 192.168.50.0/24 ನಲ್ಲಿ ಕುಳಿತಿದ್ದರೆ, ಸರ್ವರ್ಗೆ ಆ prefix ಗಾಗಿ 192.168.10.1 ಮೂಲಕ ಸ್ಪಷ್ಟ ಮಾರ್ಗ ಬೇಕು, ಮತ್ತು ಆ ಮಾರ್ಗ ಮರುಸಂಪರ್ಕವನ್ನು ತಾಳಿಕೊಳ್ಳಬೇಕು. ಅಪವಾದವನ್ನು ನಿರ್ವಹಣಾ prefix ಗೆ ನಿರ್ದಿಷ್ಟವಾಗಿ ಇಡಿ; ಖಾಸಗಿ ಶ್ರೇಣಿಗಳಿಗೆ ವಿಶಾಲ ಅಪವಾದ ಟನೆಲ್ನ ಉದ್ದೇಶವನ್ನು ವಿಫಲಗೊಳಿಸುತ್ತದೆ.

Firewall ಅಪವಾದವನ್ನು ನಿಯಮದಷ್ಟೇ ಸಂಕುಚಿತಗೊಳಿಸಿ

host ನಲ್ಲಿ firewall ಚಲಿಸುತ್ತಿದ್ದರೆ, SSH ಅನ್ನು ನಿರ್ವಹಣಾ ಮೂಲದಿಂದ ಮಾತ್ರ ಮತ್ತು LAN interface ನಲ್ಲಿ ಮಾತ್ರ ಅನುಮತಿಸಿ. 22 ಪೋರ್ಟ್ ಅನ್ನು ಎಲ್ಲಿಂದಲಾದರೂ ಅನುಮತಿಸುವ ನಿಯಮ ಅಗತ್ಯಕ್ಕಿಂತ ವಿಶಾಲ ಮತ್ತು ಪರಿಶೀಲನೆಯಲ್ಲಿ ಸಮರ್ಥಿಸಲು ಕಷ್ಟ. nftables host ನಲ್ಲಿ ನಿಯಮವು interface ಮತ್ತು ಮೂಲ ಹೊಂದಿಕೆಯೊಂದಿಗೆ input chain ನಲ್ಲಿರುತ್ತದೆ; iptables host ನಲ್ಲಿ ಸಮಾನವಾದದ್ದು-i ಮತ್ತು-s ಮೇಲಿನ ಎರಡು ಹೊಂದಿಕೆಗಳ ಜೋಡಿ. ನಿಯಮಕ್ಕೆ ಅದು ಸೇವೆ ಸಲ್ಲಿಸುವ ನಿರ್ವಾಹಕ ಗುಂಪಿನ ಟಿಪ್ಪಣಿ ಬರೆಯಿರಿ, ಮುಂದಿನ ಲೆಕ್ಕಪರಿಶೋಧನೆಗೆ 22 ಪೋರ್ಟ್ ಏಕೆ ತೆರೆದಿದೆ ಎಂದು ಊಹಿಸಬೇಕಾಗದಿರಲಿ.

VPN ಕ್ಲೈಂಟ್ನ ಸ್ವಂತ filter ಅನ್ನೂ ಪರಿಶೀಲಿಸಿ. ಕೆಲವು ಕ್ಲೈಂಟ್ಗಳು ವಿನ್ಯಾಸದ ಪ್ರಕಾರ ಸ್ಥಳೀಯ traffic ಅನ್ನು ಬಿಡುವ ನಿಯಮಗಳನ್ನು ಸ್ಥಾಪಿಸುತ್ತವೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಮಟ್ಟದ drop ಮೇಲಿನ ಸರಿಯಾದ firewall ನಿಯಮ ಏನನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ. host firewall ಸಂಪಾದಿಸುವ ಮೊದಲು ಕ್ಲೈಂಟ್ configuration ಓದಿ, ಏಕೆಂದರೆ ಸರಣಿಯಲ್ಲಿ ಎರಡು filter ಯಾವುದಕ್ಕೂ ಹೋಲದ ವೈಫಲ್ಯವನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ.

ಎರಡೂ ಸ್ಥಿತಿಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ

ಪರೀಕ್ಷೆಯನ್ನು ಎರಡು ಬಾರಿ ನಡೆಸಿ: ಒಮ್ಮೆ ಟನೆಲ್ ಸಂಪರ್ಕಿತವಾಗಿರುವಾಗ ಮತ್ತು ಒಮ್ಮೆ ಸಂಪರ್ಕ ಕಡಿತಗೊಂಡಿರುವಾಗ. ಪ್ರತಿ ಸ್ಥಿತಿಯಲ್ಲಿ ಲಿಸನರ್, ಮಾರ್ಗ ಮತ್ತು ನಿರ್ವಾಹಕರ ಯಂತ್ರದಿಂದ ನಿಜವಾದ SSH ಲಾಗಿನ್ ದೃಢೀಕರಿಸಿ. ಟನೆಲ್ ಮೇಲಿರುವಾಗ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುವ ಮಾರ್ಗ ಸ್ಥಳೀಯ ನಿರ್ವಹಣಾ ಮಾರ್ಗವಲ್ಲ; ಅದು ಕಾಕತಾಳೀಯ.

ನಂತರ SSH session ತೆರೆದಿರುವಾಗ ಟನೆಲ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ. ಉಳಿದುಕೊಳ್ಳುವ session routing ಸ್ಥಿರವಾಗಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ; ಬೀಳುವ session ಕ್ಲೈಂಟ್ ಮರುಸಂಪರ್ಕದಲ್ಲಿ ಮಾರ್ಗ ಅಥವಾ filter ಗಳನ್ನು ಮತ್ತೆ ಬರೆಯುತ್ತಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಇದನ್ನು ಘಟನೆಯ ಮೊದಲು ತಿಳಿಯುವುದು ಒಳ್ಳೆಯದು, ಸಮಯದಲ್ಲಿ ಅಲ್ಲ.

ನೀವು ಪರೀಕ್ಷಿಸಿದ ಮೂಲ ವಿಳಾಸವನ್ನು ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ 192.168.10.50 ಗಾಗಿ ಬರೆದ ನಿಯಮ ನಿರ್ವಾಹಕರ ಲ್ಯಾಪ್ಟಾಪ್ ಬೇರೆ subnet ಗೆ ಹೋದಾಗ ಸದ್ದಿಲ್ಲದೆ ವಿಫಲವಾಗುತ್ತದೆ.

ಚೇತರಿಕೆ ಮಾರ್ಗವನ್ನು runbook ನಲ್ಲಿ ಬರೆಯಿರಿ

ಹೊರಮುಖ VPN ಸ್ಥಳೀಯ ಮಾರ್ಗವನ್ನು ಮುರಿದರೆ ಏನಾಗುತ್ತದೆ ಎಂದು ಈಗಲೇ ನಿರ್ಧರಿಸಿ. console ಪ್ರವೇಶ, ಎರಡನೇ ನಿರ್ವಹಣಾ ವಿಳಾಸ, ಅಥವಾ ಕ್ಲೈಂಟ್ ನಿಲ್ಲಿಸುವ ದಾಖಲಿತ ಕಾರ್ಯವಿಧಾನ — ಎಲ್ಲವೂ ಕಾನೂನುಬದ್ಧ ಉತ್ತರಗಳು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ನೀವು ಲಾಗಿನ್ ಮಾಡಬೇಕಾದ ಕ್ಷಣದಲ್ಲಿ ಸಮಸ್ಯೆಯನ್ನು ಕಂಡುಹಿಡಿಯುವುದಕ್ಕಿಂತ ಉತ್ತಮ. ಸರ್ವರ್ ದೂರದಲ್ಲಿದ್ದರೆ ಸ್ಥಳೀಯ ಮಾರ್ಗ ಇಲ್ಲ, ಮತ್ತು ಸರಿಯಾದ ವಿನ್ಯಾಸವೆಂದರೆ ಬಹಿರಂಗ ಸಾರ್ವಜನಿಕ ಪೋರ್ಟ್ ಬದಲು ಪ್ರತ್ಯೇಕ ಅನುಮೋದಿತ ದೂರಸ್ಥ-ಪ್ರವೇಶ ಮಾರ್ಗ ಅಥವಾ bastion.

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