ನಿಮ್ಮ ವೆಬ್ ಸರ್ವರ್ನಲ್ಲಿ VPN ಕ್ಲೈಂಟ್ ಅದರ ಉತ್ತರಗಳನ್ನು ಮುರಿಯುತ್ತದೆಯೇ?

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

ಮೂಲ-ಆಧಾರಿತ ರೂಟ್ ನಿಯಮವು ಸಾಮಾನ್ಯವಾಗಿ ಲಕ್ಷಣವನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ. ಅದು ಸಾಮಾನ್ಯವಾಗಿ ಅದನ್ನು ಪ್ರೇರೇಪಿಸಿದ ಸೈಟ್ಗಿಂತ ಹೆಚ್ಚು ಸಂಚಾರಕ್ಕೂ ವಿನಾಯಿತಿ ನೀಡುತ್ತದೆ, ಮತ್ತು ನಿಯಮವನ್ನು ಉಳಿಸುವ ಮೊದಲು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕಾದ ಭಾಗ ಅದೇ.

ಲಕ್ಷಣ: ಅದು ಸ್ಥಳೀಯವಾಗಿ ಉತ್ತರಿಸುತ್ತದೆ, ಹೊರಗಿನಿಂದ ಅಲ್ಲ

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

ರೂಟಿಂಗ್ ಬದಲಿಸುವ ಮೊದಲು ಆಕಾರವನ್ನು ದೃಢೀಕರಿಸಿ: ಶ್ರೋತೃ ಸಕ್ರಿಯವಾಗಿದೆ, ಸ್ಥಳೀಯ ವಿನಂತಿ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ, ಮತ್ತು ಬಾಹ್ಯ ವಿನಂತಿ ಯಾವುದೇ ಉತ್ತರ ನೀಡುವುದಿಲ್ಲ. ಈ ಮೂರು ಅವಲೋಕನಗಳು ಒಟ್ಟಾಗಿ ವೆಬ್ ಸರ್ವರ್ ಸಂರಚನೆಯ ಬದಲು ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಸೂಚಿಸುತ್ತವೆ. ಇಷ್ಟು ಸ್ವಚ್ಛ ಅಸಮಮಿತಿ ಯಾವುದೇ ಲಾಗ್ ಸಾಲಿಗಿಂತ ಉಪಯುಕ್ತವಾಗಿದೆ, ಏಕೆಂದರೆ ಅದು ಒಂದು ದೋಷ ಸಂದೇಶ ಓದುವ ಮೊದಲೇ ಶ್ರೋತೃವನ್ನು ಹೊರಗಿಡುತ್ತದೆ.

ಕೆಲಸ ಮಾಡುವಾಗ ಸ್ವತಂತ್ರ ಆಡಳಿತ ಮಾರ್ಗವನ್ನು ತೆರೆದಿಡಿ. ನಿಮ್ಮದೇ SSH ಅಧಿವೇಶನವನ್ನು ಮುರಿಯುವ ನಿಯಮವು ಹತ್ತು ನಿಮಿಷಗಳ ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ಭೌತಿಕ ಭೇಟಿಯಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.

ಮೂಲ ಸೆಲೆಕ್ಟರ್ ನಿಜವಾಗಿ ಏನನ್ನು ಹೊಂದಿಸುತ್ತದೆ

Linux ನೀತಿ ರೂಟಿಂಗ್ನಲ್ಲಿ, from 192.168.50.2 ನಂತಹ ನಿಯಮವು ಮೂಲವು ಆ ವಿಳಾಸವಾಗಿರುವ ಪ್ಯಾಕೆಟ್ಗಳಿಗೆ ಹೊಂದುತ್ತದೆ. ಅದು ಪ್ಯಾಕೆಟ್ ಮನೆಯ ರೂಟರ್ ಮೂಲಕ ಪ್ರವೇಶಿಸಿದ ಸಂಭಾಷಣೆಯನ್ನು ಮುಂದುವರಿಸುತ್ತಿದೆ ಎಂಬ ಅಂಶವನ್ನು ಸಂಕೇತಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಅದನ್ನು ಯಾವ ಪ್ರಕ್ರಿಯೆ ರಚಿಸಿತೆಂದು ತಿಳಿಯದು. ಆ ಉದಾಹರಣೆಯಲ್ಲಿನ ವಿಳಾಸವು ಉದಾಹರಣಾತ್ಮಕ; ನಿಮ್ಮ ಹೋಸ್ಟ್ ನಿಜವಾಗಿ ಬಳಸುವ ವಿಳಾಸವನ್ನು ಹಾಕಿ. ಸಾಲನ್ನು ವಿಳಾಸಗಳ ಬಗ್ಗೆ ಒಂದು ಹೇಳಿಕೆಯಾಗಿ ಪರಿಗಣಿಸಿ, ಅದಕ್ಕಿಂತ ಹೆಚ್ಚೇನೂ ಅಲ್ಲ.

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

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

ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಮತ್ತು ನೀವು ಉದ್ದೇಶಿಸದ ಸಂಚಾರವನ್ನು ಪರಿಶೀಲಿಸಿ

ನಿಯಮಗಳು ಮತ್ತು ಕೋಷ್ಟಕಗಳನ್ನು ಓದಿ, ನಂತರ ನಿರ್ದಿಷ್ಟ ಮೂಲ ಮತ್ತು ಗಮ್ಯ ಜೋಡಿ ಯಾವ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಕರ್ನಲ್ಗೆ ಕೇಳಿ. ಹೋಸ್ಟ್ನಿಂದಲೇ ಪರೀಕ್ಷಿಸುವುದು ಹೊರಗಿನಿಂದ ಪರೀಕ್ಷಿಸುವುದಕ್ಕೆ ಸಮವಲ್ಲ, ಆದ್ದರಿಂದ ಎರಡನ್ನೂ ಮಾಡಿ.

ip rule show
ip route show table 100
ip route get 203.0.113.44 from 192.168.50.2
ss -ltnp '( sport = :443 )'

ನಂತರ ಹೊಸ ಬಾಹ್ಯ ಸಂಪರ್ಕವನ್ನು ಸ್ವೀಕರಿಸಿ ಮತ್ತು ಪ್ರತ್ಯೇಕವಾಗಿ, ಇನ್ನೂ VPN ಮೂಲಕ ಹೊರಡಬೇಕಾದ ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಿ. ಎರಡನೆಯದು ಈಗ ನೇರವಾಗಿ ಹೊರಟರೆ, ವಿನಾಯಿತಿಯು ನೀವು ಪರಿಹರಿಸುತ್ತಿದ್ದ ಸಮಸ್ಯೆಗಿಂತ ವಿಶಾಲವಾಗಿದೆ, ಮತ್ತು ಮುಖ್ಯ ಪರೀಕ್ಷೆ ಎಂದರೆ ನೀವು ಬದಲಿಸಲು ಉದ್ದೇಶಿಸದಿದ್ದದ್ದು.

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

ವಿನಾಯಿತಿ ಎಷ್ಟು ಸಂಕುಚಿತವಾಗಿರಬಹುದು ಎಂದು ನಿರ್ಧರಿಸಿ

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

ನೀವು ಅವಲಂಬಿಸಿರುವ ಒಪ್ಪಂದವನ್ನು ದಾಖಲಿಸಿ: ಸಾರ್ವಜನಿಕ ಮ್ಯಾಪಿಂಗ್, ವಿನಂತಿ ತಲುಪಿಸುವ ಹೋಸ್ಟ್ ವಿಳಾಸ, ಮತ್ತು ಉತ್ತರ ತೆಗೆದುಕೊಳ್ಳಬೇಕಾದ ಮಾರ್ಗ. VPN ಪೂರೈಕೆದಾರರ ಮೂಲಕ ಪ್ರಕಟಿಸಿದ ಒಳಬರುವ ಸೇವೆ ಮನೆಯ ರೂಟರ್ ಮೂಲಕ ಪ್ರಕಟಿಸಿದ್ದಕ್ಕಿಂತ ಬೇರೆ ಒಪ್ಪಂದ, ಮತ್ತು ಒಂದು ಉದಾಹರಣೆಯಿಂದ ನಕಲಿಸಿದ ವಿನಾಯಿತಿ ಇನ್ನೊಂದಕ್ಕೆ ಹೆಚ್ಚಾಗಿ ತಪ್ಪು.

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