VPN ಬದಲಾವಣೆಯ ನಂತರ ರೌಟರ್ ನಿರ್ವಾಹಕ ಪುಟ ಉತ್ತರಿಸುವುದನ್ನು ಏಕೆ ನಿಲ್ಲಿಸುತ್ತದೆ

ಸುರಂಗವನ್ನು ಪರೀಕ್ಷಿಸಲು ನೀವು ಮಾರ್ಗ ಅಥವಾ ಫೈರ್‌ವಾಲ್ ನಿಯಮವನ್ನು ಬದಲಿಸಿದ್ದೀರಿ, ಮತ್ತು ಈಗ ಹತ್ತು ನಿಮಿಷಗಳ ಹಿಂದೆ ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಿಂದ ನಿರ್ವಾಹಕ ಪುಟ ಉತ್ತರಿಸುತ್ತಿಲ್ಲ. ಮೊದಲ ಪ್ರತಿಕ್ರಿಯೆ VPN ಅನ್ನು ದೂಷಿಸುವುದು. ಬಹುಪಾಲು ಸಂದರ್ಭಗಳಲ್ಲಿ ಸುರಂಗ ಆರೋಗ್ಯಕರವಾಗಿರುತ್ತದೆ ಮತ್ತು ಮೂರರಲ್ಲಿ ಒಂದು ಬೇರೆ ವಿಷಯ ಮುರಿದಿರುತ್ತದೆ: ರೌಟರ್ನ ಸ್ವಂತ ವಿಳಾಸಕ್ಕೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವಿಲ್ಲ, ಇನ್ಪುಟ್ ನೀತಿ ವಿನಂತಿಯನ್ನು ಬಿಸಾಡುತ್ತದೆ, ಅಥವಾ ನೀವು ಕರೆಯುವ ವಿಳಾಸದಲ್ಲಿ ವೆಬ್ ಸೇವೆ ಕೇಳುತ್ತಿಲ್ಲ. ಮೂರೂ ಬ್ರೌಸರ್ನಲ್ಲಿ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ, ಆದ್ದರಿಂದ ಜನರು ಒಂದು ಗಂಟೆ ಸುರಂಗವನ್ನು ಮರುಪ್ರಾರಂಭಿಸುತ್ತಾರೆ ಮತ್ತು ಏನನ್ನೂ ಕಲಿಯುವುದಿಲ್ಲ.

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

ಸುರಂಗ ಎಂದಿಗೂ ನಿರ್ವಹಣಾ ಮಾರ್ಗವಾಗಿರಲಿಲ್ಲ

ಫಾರ್ವರ್ಡಿಂಗ್ ಮತ್ತು ಇನ್ಪುಟ್ ಬೇರೆ ಬೇರೆ ಕೆಲಸಗಳು. "ಕ್ಲೈಂಟ್ ಸುರಂಗದ ಮೂಲಕ NAS ತಲುಪಬಹುದೇ?" ಎಂಬುದು ರೌಟರ್ ಮೂಲಕ ಹಾದುಹೋಗುವ ಪ್ಯಾಕೆಟ್ಗಳ ಬಗ್ಗೆ ಫಾರ್ವರ್ಡಿಂಗ್ ಪ್ರಶ್ನೆ. "ನಾನು ರೌಟರ್ನ SSH ಪೋರ್ಟ್ ತೆರೆಯಬಹುದೇ?" ಎಂಬುದು ರೌಟರ್ನಗೇ ವಿಳಾಸ ಮಾಡಿದ ಪ್ಯಾಕೆಟ್ಗಳ ಬಗ್ಗೆ ಇನ್ಪುಟ್ ಪ್ರಶ್ನೆ. ಫಾರ್ವರ್ಡ್ ಮಾಡಿದ ಸಂಚಾರಕ್ಕಾಗಿ ಬರೆದ ಅನುಮತಿ ನಿಯಮ ಎರಡನೇ ಪ್ರಶ್ನೆಗೆ ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಸಂಚಾರವನ್ನು ಪರಿಪೂರ್ಣವಾಗಿ ಸಾಗಿಸುವ ಸುರಂಗವೂ ನಿಮ್ಮ ನಿರ್ವಾಹಕ ಅಧಿವೇಶನವನ್ನು ನಿರಾಕರಿಸುವುದಕ್ಕೆ ಇದೇ ಸಾಮಾನ್ಯ ಕಾರಣ.

ವಿರುದ್ಧ ತಪ್ಪು ಎಂದರೆ ಇಂಟರ್ಫೇಸ್ ಹೆಸರನ್ನು ನಂಬುವುದು. ಸುರಂಗ ಸಹಭಾಗಿಗೆ ಎನ್ಕ್ರಿಪ್ಟ್ ಆಗುತ್ತದೆ, ಅದರ ಹಿಂದಿನ ಪ್ರತಿ ಸೇವೆಗೂ ಅಲ್ಲ, ಮತ್ತು ಇಂಟರ್ಫೇಸ್ ಲೇಬಲ್ನಲ್ಲಿನ VPN ಪದ ಯಾವ ಮೂಲಗಳಿಗೆ ಲಾಗಿನ್ ಅನುಮತಿ ಇರಬೇಕು ಎಂಬುದನ್ನು ಹೇಳುವುದಿಲ್ಲ.

ಮೊದಲ ಪದರ: ರೌಟರ್ನ ಸ್ವಂತ ವಿಳಾಸಕ್ಕೆ ಮಾರ್ಗವಿದೆಯೇ?

ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸಿ ಪ್ಯಾಕೆಟ್ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂದು ಕರ್ನೆಲ್ಗೆ ಕೇಳಿ. Linux ನಲ್ಲಿ ip route get 10.6.0.1 ಆಯ್ಕೆಯಾದ ಮಾರ್ಗ, ಹೊರಹೋಗುವ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಮೂಲ ವಿಳಾಸವನ್ನು ಮುದ್ರಿಸುತ್ತದೆ. ಅದು ನಿಮ್ಮ ಪೂರೈಕೆದಾರರ ಕಡೆಗಿನ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ವರದಿ ಮಾಡಿದರೆ, ಪ್ಯಾಕೆಟ್ ಎಂದಿಗೂ ಸುರಂಗವನ್ನು ಪ್ರವೇಶಿಸುವುದಿಲ್ಲ, ಮತ್ತು ರೌಟರ್ನ ಯಾವುದೇ ನಿಯಮ ಅದನ್ನು ಉಳಿಸಲಾರದು.

ಸುರಂಗದ ಬದಿಗೆ ಪ್ರಶ್ನೆಯ ತನ್ನದೇ ಆವೃತ್ತಿ ಇದೆ. WireGuard AllowedIPs ಅನ್ನು ಕ್ರಿಪ್ಟೋಕೀ ಮಾರ್ಗನಿರ್ದೇಶನ ಕೋಷ್ಟಕವಾಗಿ ಪರಿಗಣಿಸುತ್ತದೆ: ಪ್ರತಿ ತುದಿಯಲ್ಲಿ ಸಹಭಾಗಿ ಯಾವ ಮೂಲ ವಿಳಾಸಗಳನ್ನು ಬಳಸಬಹುದು ಮತ್ತು ಯಾವ ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು ಆ ಸಹಭಾಗಿಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ ಎಂದು ಘೋಷಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ ನಮೂದು ರೌಟರ್ನ ಸುರಂಗ ವಿಳಾಸವನ್ನು ಒಳಗೊಂಡಿಲ್ಲದಿದ್ದರೆ, ಕ್ಲೈಂಟ್ಗೆ ಅಲ್ಲಿಗೆ ಮಾರ್ಗವಿಲ್ಲ. ಆ ಕ್ಲೈಂಟ್ಗಾಗಿ ಸರ್ವರ್ ನಮೂದು ಕ್ಲೈಂಟ್ನ ಸುರಂಗ ವಿಳಾಸವನ್ನು ಆವರಿಸದಿದ್ದರೆ, ಸರ್ವರ್ ಯಾವುದೇ ಫೈರ್‌ವಾಲ್ ನಿಯಮವನ್ನು ನೋಡುವ ಮೊದಲೇ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಬಿಸಾಡುತ್ತದೆ.

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

ಎರಡನೇ ಪದರ: ಇನ್ಪುಟ್ ನೀತಿ, ಫಾರ್ವರ್ಡಿಂಗ್ ನೀತಿ ಅಲ್ಲ

ಫೈರ್‌ವಾಲ್ಗಳು ಪ್ಯಾಕೆಟ್ ಬರುವ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ನಿಯಮಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತವೆ. pfSense ಮತ್ತು OPNsense ನಲ್ಲಿ ಇಂಟರ್ಫೇಸ್ ಟ್ಯಾಬ್ ಮತ್ತು ನಿಯಮಗಳ ಕ್ರಮ ಫೈರ್‌ವಾಲ್ನ ಸ್ವಂತ ಸೇವೆಗಳಿಗೆ ಸಂಚಾರ ಅನುಮತಿಸಲಾಗಿದೆಯೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ; LAN ಕ್ಲೈಂಟ್ಗಳನ್ನು ಇಂಟರ್ನೆಟ್ಗೆ ಹೊರಡಿಸುವ ನಿಯಮ ಸುರಂಗ ಸಹಭಾಗಿಗೆ ವೆಬ್ GUI ತೆರೆಯಲು ಅನುಮತಿಸುವ ನಿಯಮವಲ್ಲ. firewall4 ಇರುವ OpenWrt ನಲ್ಲಿ ಪ್ರತಿ ವಲಯವೂ ಇನ್ಪುಟ್ ನೀತಿಯನ್ನು ಹೊಂದಿರುತ್ತದೆ, option input 'ACCEPT' ಅಥವಾ 'REJECT', ಮತ್ತು ಇನ್ಪುಟ್ REJECT ಇರುವ ವಲಯದಲ್ಲಿನ ಸುರಂಗ ಇಂಟರ್ಫೇಸ್ ನಿರ್ವಹಣಾ ಸಂಪರ್ಕಗಳನ್ನು ನಿರಾಕರಿಸುತ್ತದೆ, ಆದರೆ ಫಾರ್ವರ್ಡಿಂಗ್ ಅನುಮತಿಸಿದ್ದರೆ ಸಂಚಾರವನ್ನು ಇನ್ನೂ ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ.

ಹೊಸ ಮಾರ್ಗ ಕೆಲಸ ಮಾಡಲಿ ಎಂದು ಆಂಟಿ-ಲಾಕ್ಔಟ್ ನಿಯಮವನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬೇಡಿ. ಆ ನಿಯಮ ಕೆಟ್ಟ ನಿಯಮವು LAN ನಿರ್ವಹಣಾ ವಿಳಾಸವನ್ನು ಲಾಕ್ ಮಾಡದಂತೆ ತಡೆಯುತ್ತದೆ; ಅದು LAN ಉಪಜಾಲವನ್ನು ರಕ್ಷಿಸುತ್ತದೆ, ನೀವು ಈಗ ತಯಾರಿಸಿದ ಸುರಂಗ ಉಪಜಾಲವನ್ನಲ್ಲ. ನಿರ್ವಾಹಕ ಮೂಲಕ್ಕಾಗಿ ಒಂದು ಸನಿಹ ನಿಯಮ ಸೇರಿಸಿ ಮತ್ತು ಸುರಕ್ಷತಾ ಜಾಲವನ್ನು ಹಾಗೆಯೇ ಬಿಡಿ. pfSense ನ ನಿರ್ವಾಹಕ ಪ್ರವೇಶ ದಾಖಲೆ ಆ ನಿಯಂತ್ರಣಗಳು ಎಲ್ಲಿವೆ ಎಂದು ವಿವರಿಸುತ್ತದೆ.

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

ಮೂರನೇ ಪದರ: ಆ ವಿಳಾಸದಲ್ಲಿ ಏನಾದರೂ ಕೇಳುತ್ತಿದೆಯೇ?

ಸೇವೆ ಚಾಲನೆಯಲ್ಲಿದ್ದರೂ ಒಂದೇ ವಿಳಾಸಕ್ಕೆ ಬಂಧಿಸಲ್ಪಟ್ಟಿರುವುದರಿಂದ ತಲುಪಲಾಗದಿರಬಹುದು. OpenWrt ನ uhttpd /etc/config/uhttpd ನಲ್ಲಿ ಸ್ಪಷ್ಟ ಶ್ರವಣ ನಮೂದುಗಳನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಉದಾಹರಣೆಗೆ list listen_http '0.0.0.0:80'; ಕೇವಲ LAN ವಿಳಾಸಕ್ಕೆ ಬಂಧಿಸುವ ನಿರ್ಮಾಣ ಸುರಂಗ ವಿಳಾಸದಲ್ಲಿ ಏನನ್ನೂ ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಶ್ರವಣ ಇಂಟರ್ಫೇಸ್ ಸೆಟ್ಟಿಂಗ್ ತೋರಿಸುವ ಉತ್ಪನ್ನಗಳೂ ಅದೇ ರೀತಿ ವರ್ತಿಸುತ್ತವೆ. ಮೇಲಿನ ಶ್ರವಣ ಆದೇಶಗಳು ಇದಕ್ಕೆ ನೇರವಾಗಿ ಉತ್ತರಿಸುತ್ತವೆ.

ನಂತರ ನಿರಾಕರಣೆಯನ್ನು ಮೌನದಿಂದ ಬೇರ್ಪಡಿಸಿ. nc -vz 10.6.0.1 443 ನಿರಾಕರಿಸಿದ ಸಂಪರ್ಕವನ್ನು ಹಿಂತಿರುಗಿಸಿದರೆ ಪ್ಯಾಕೆಟ್ ರೌಟರ್ ತಲುಪಿದೆ ಮತ್ತು ಏನೋ ಅದನ್ನು ನಿರಾಕರಿಸಿದೆ, ಮುಚ್ಚಿದ ಪೋರ್ಟ್ ಅಥವಾ ಸ್ಪಷ್ಟ ನಿರಾಕರಣಾ ನಿಯಮ. ಟೈಮ್ಔಟ್ವರೆಗೆ ನೇತಾಡುವುದು ಪ್ಯಾಕೆಟ್ ಬಿಸಾಡಲ್ಪಟ್ಟಿದೆ ಅಥವಾ ಎಂದಿಗೂ ಮಾರ್ಗನಿರ್ದೇಶಿಸಲ್ಪಟ್ಟಿಲ್ಲ ಎಂದರ್ಥ. ಈ ವ್ಯತ್ಯಾಸ ಮುಂದೆ ಯಾವ ಪದರವನ್ನು ಪರೀಕ್ಷಿಸಬೇಕು ಎಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು ಅದಕ್ಕೆ ಐದು ಸೆಕೆಂಡುಗಳು ಸಾಕು.

VPN ಇಂಟರ್ಫೇಸ್ ಒಂದು ಗಡಿ, ಚೇತರಿಕೆ ಮಾರ್ಗವಲ್ಲ

ಎನ್ಕ್ರಿಪ್ಷನ್ ತಂತಿಯನ್ನು ರಕ್ಷಿಸುತ್ತದೆ; ನಿರ್ವಾಹಕ ಪುಟವನ್ನು ಯಾರು ತೆರೆಯಬಹುದು ಎಂಬುದನ್ನು ಅದು ಹೇಳುವುದಿಲ್ಲ. ಸುರಂಗ ಕೆಲಸ ಮಾಡಿದ ನಂತರ, ಸುರಂಗ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ಅನುಮತಿಸಿ ತಲುಪುವಿಕೆಯನ್ನು ಪರಿಹರಿಸುವ ಪ್ರಚೋದನೆಯನ್ನು ವಿರೋಧಿಸಿ. ನಿರ್ವಾಹಕರಿಗೆ ಅವರ ಸ್ವಂತ ಸುರಂಗ ವಿಳಾಸಕ್ಕೆ ಬಂಧಿತ ನಿಯಮ ಅಥವಾ ಪ್ರತ್ಯೇಕ ನಿರ್ವಾಹಕ-ಮಾತ್ರ ಸುರಂಗ ನೀಡಿ, ಮತ್ತು ಸಾಮಾನ್ಯ ಬಳಕೆದಾರರು, NAS, ಕ್ಯಾಮೆರಾಗಳು ಮತ್ತು ಕುಟುಂಬದ ಲ್ಯಾಪ್ಟಾಪ್ಗಳನ್ನು ನಿರ್ವಹಣಾ ಪೋರ್ಟ್ನಿಂದ ದೂರವಿರಿಸಿ. ಫೈಲ್ ಹಂಚಿಕೆ ಬೇಕಾದ ಸಹಭಾಗಿ ರೌಟರ್ ಲಾಗಿನ್ನಿಂದ ಒಂದು ನಿಯಮ ದೂರದಲ್ಲಿರಬಾರದು.

ರೌಟರ್ನ ಪಾತ್ರ ಉತ್ತರವನ್ನು ಬದಲಿಸುತ್ತದೆ. ಸುರಂಗವನ್ನು ಮುಗಿಸುವ ರೌಟರ್ ಅದರಿಂದ ನಿರ್ವಾಹಕರನ್ನು ಕಾನೂನುಬದ್ಧವಾಗಿ ಸ್ವೀಕರಿಸಬಹುದು, ಆದರೆ ಸುರಂಗವನ್ನು ಕೇವಲ ಇಂಟರ್ನೆಟ್ ನಿರ್ಗಮನವಾಗಿ ಬಳಸುವ ರೌಟರ್ ಸಾಮಾನ್ಯವಾಗಿ ಹಾಗೆ ಮಾಡಬಾರದು. ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ ಉಪಜಾಲ ಅನುಮತಿ ಲಾಗಿನ್ ಅಲ್ಲ, ಆದ್ದರಿಂದ ಖಾತೆ ದೃಢೀಕರಣ ಮತ್ತು ಸಾಗಣೆ ಭದ್ರತೆಯನ್ನು ಆನ್ ಆಗಿಡಿ.

ಲಾಕ್ಔಟ್ ನಂತರ ಜನರು ಮಾಡುವ ಸರಿದೂಗಿಸುವ ಕ್ರಮ ಕೆಟ್ಟದು: WAN ನಿರ್ವಹಣೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವುದು ಅಥವಾ ಪೋರ್ಟ್ ಅನ್ನು ವೆಬ್ GUI ಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುವುದು. ಇದು ಸಣ್ಣ ಅಡಚಣೆಯನ್ನು ಶಾಶ್ವತ ಒಡ್ಡುವಿಕೆಯಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ, ಮತ್ತು ಲಾಗಿನ್ ಪುಟ ಆಗ ಇಂಟರ್ನೆಟ್ನ ಪ್ರತಿ ಸ್ಕ್ಯಾನರ್ಗೂ ತಲುಪಬಹುದಾಗುತ್ತದೆ. ಅನುಮತಿಸಿದ ಬದಿಯಂತೆ ನಿರಾಕರಿಸಿದ ಬದಿಯನ್ನೂ ಪರೀಕ್ಷಿಸಿ, ಇದರಿಂದ ನಿರ್ವಾಹಕ ಪ್ರವೇಶ ಇರಬಾರದ ಸಹಭಾಗಿಗೆ ಲಾಗಿನ್ ಪ್ರಾಂಪ್ಟ್ ಬದಲು ಟೈಮ್ಔಟ್ ಅಥವಾ ನಿರಾಕರಣೆ ಸಿಗುತ್ತದೆ.

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

ನೀತಿಯನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಹಿಂತಿರುಗುವ ದಾರಿಯನ್ನು ಸಿದ್ಧಪಡಿಸಿ

ಮೊದಲ ಬದಲಾವಣೆಗೆ ಮೊದಲು ನಾಲ್ಕು ವಿಷಯಗಳನ್ನು ಬರೆಯಿರಿ: ಸುರಂಗ ಸತ್ತರೆ ನೀವು ಸಾಧನವನ್ನು ಹೇಗೆ ತಲುಪುತ್ತೀರಿ, ಉದಾಹರಣೆಗೆ ಸರಣಿ ಕನ್ಸೋಲ್, ಪೂರೈಕೆದಾರರ ಕನ್ಸೋಲ್ ಅಥವಾ LAN ನಲ್ಲಿನ ಯಂತ್ರ; ಪ್ರಸ್ತುತ ಸಂರಚನೆ ಎಲ್ಲಿಗೆ ರಫ್ತಾಗುತ್ತದೆ; ಯಾವ ಒಂದು ನಿಯಮ ಅಥವಾ ಮಾರ್ಗವನ್ನು ನೀವು ಬದಲಿಸಲಿದ್ದೀರಿ; ಮತ್ತು ಆ ಅಂಶವನ್ನು ನಿಖರವಾಗಿ ಹೇಗೆ ಹಿಂತಿರುಗಿಸುತ್ತೀರಿ. OpenWrt ನಲ್ಲಿ sysupgrade -b /tmp/backup.tar.gz ಸಂರಚನೆಯನ್ನು ಹಿಡಿಯುತ್ತದೆ, ಮತ್ತು ಸಂಪಾದನೆಗಳು uci commit ವರೆಗೆ ಬಾಕಿ ಇರುತ್ತವೆ, ಇದು ಸಮಯಕ್ಕೆ ಗಮನಿಸಿದರೆ ಅಗ್ಗದ ರದ್ದತಿ ನೀಡುತ್ತದೆ. pfSense ಸಂರಚನಾ ಇತಿಹಾಸವನ್ನು ಇಡುತ್ತದೆ, ಮತ್ತು AutoConfigBackup ಅದು ಈಗಾಗಲೇ ಸಕ್ರಿಯವಿದ್ದರೆ ಮಾತ್ರ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ರೌಟರ್ fail-closed ನಿಯಮ ಸಮೂಹವನ್ನು ನಡೆಸುತ್ತಿದ್ದರೆ, ನೀವು ಯೋಜಿಸಿದ ನಿರ್ವಹಣಾ ಮಾರ್ಗ ಆ ನಿಯಮ ಬ್ಲಾಕ್ ಮಾಡುವ ಸಂಚಾರದ ಒಳಗಿಲ್ಲ ಎಂದು ದೃಢೀಕರಿಸಿ, ಮತ್ತು ಮರುಬೂಟ್ ಶಾಶ್ವತ ನಿಯಮಗಳನ್ನು ಅಳಿಸುವ ಬದಲು ಮತ್ತೆ ಅನ್ವಯಿಸುತ್ತದೆ ಎಂದು ನೆನಪಿಡಿ.

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

ಹೊರಡುವ ಮೊದಲು ತ್ವರಿತ ಪರಿಶೀಲನೆ:

• ನೀವು ಈಗ ಸಂಪಾದಿಸಿದ ನಿಯಮವನ್ನು ಅವಲಂಬಿಸದ ಮೂಲದಿಂದ ರೌಟರ್ ತಲುಪಬಹುದೇ?
• ಸುರಂಗ ಇಂಟರ್ಫೇಸ್ನ ಇನ್ಪುಟ್ ನೀತಿ ನಿರ್ವಾಹಕ ಮೂಲಕ್ಕೆ ಮಾತ್ರ ಅನುಮತಿ ನೀಡುತ್ತದೆಯೇ?
• ನಿರ್ವಹಣಾ ಸೇವೆ ಸುರಂಗದಲ್ಲಿ ಇರುವ ವಿಳಾಸಕ್ಕೆ ಬಂಧಿತವಾಗಿದೆಯೇ?
• ನೀವು ಒಂದು ನಿರಾಕರಿಸಿದ ಸಹಭಾಗಿ ಮತ್ತು ಒಂದು ಹೊಸ ಅಧಿವೇಶನವನ್ನು ಪರೀಕ್ಷಿಸಿದ್ದೀರಾ?
• WAN ನಿರ್ವಹಣಾ ಮೇಲ್ಮೈ ಇನ್ನೂ ಮುಚ್ಚಿದೆಯೇ?