VPN ಮೇಲೆ Nmap ನ ಕರ್ರಾಷ್ ಸ್ಕ್ಯಾನ್ ವಿಫಲವಾಗಿದೆ, ಆದರೆ -sT ಸಂಪರ್ಕ ಕೆಲಸ ಮಾಡುತ್ತದೆಯೇ?
ಕರ್ರಾಷ್ ಪ್ಯಾಕೆಟ್ ಸ್ಕ್ಯಾನ್ ಮತ್ತು ಸಾಮಾನ್ಯ TCP ಸಂಪರ್ಕಕ್ಕೆ ಬೇರೆ ಬೇರೆ ವಿಶೇಷಾಧಿಕಾರ ಬೇಕು. ಮೊದಲು ಸಂಪರ್ಕ ಪರಿಶೀಲನೆ ನಡೆಸಿ, ಪ್ರತಿ ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಅಕ್ಷರಶಃ ಓದಿ, ನಂತರ ಫಲಿತಾಂಶದಲ್ಲಿ ನಿಲ್ಲಿಸಿ.
ಪುಟ ಸುರಂಗದ ಮೂಲಕ ಲೋಡ್ ಆಗುತ್ತಿರುವಾಗ ಪೋರ್ಟ್ ಸ್ಕ್ಯಾನ್ ಹೋಸ್ಟ್ ಡೌನ್ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಮೊದಲ ಊಹೆ VPN ಏನೋ ತಡೆಯುತ್ತಿದೆ ಎಂದು. ಸಾಮಾನ್ಯವಾಗಿ ಅದು ಹೊಸದನ್ನು ತಡೆಯುವುದಿಲ್ಲ. ಎರಡು ಪರೀಕ್ಷೆಗಳು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ನಿಂದ ಬೇರೆ ಬೇರೆ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಕೇಳುತ್ತವೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಮಾತ್ರ ಕರ್ರಾಷ್ ಪ್ಯಾಕೆಟ್ ಪ್ರವೇಶ ಬೇಕು. ಸುರಂಗವನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಯಾವ ಸಾಮರ್ಥ್ಯ ವಿಫಲವಾಯಿತು ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ.
ಸಾಮರ್ಥ್ಯವನ್ನು ಸುರಂಗದಿಂದ ಬೇರ್ಪಡಿಸಿ
ಸಾಮಾನ್ಯ ಅಪ್ಲಿಕೇಶನ್ ಕರ್ನೆಲ್ಗೆ TCP ಸಂಪರ್ಕ ತೆರೆಯಲು ಕೇಳುತ್ತದೆ, ಮತ್ತು ಕರ್ನೆಲ್ ವಿಶೇಷ ಹಕ್ಕಿಲ್ಲದೆ ಹ್ಯಾಂಡ್ಷೇಕ್ ಮಾಡುತ್ತದೆ. ಕರ್ರಾಷ್ ಸ್ಕ್ಯಾನ್ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ತಾನೇ ನಿರ್ಮಿಸುತ್ತದೆ, ಇದಕ್ಕೆ ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಪ್ರಕಾರ ಕರ್ರಾಷ್ ಸಾಕೆಟ್ ಅಥವಾ ಸೆರೆಹಿಡಿಯುವ ಡ್ರೈವರ್ ಬೇಕು. ಇವು ಅನುಮತಿ ಮತ್ತು ಡ್ರೈವರ್ ಪ್ರಶ್ನೆಗಳು, ಮತ್ತು VPN ಸಂಪರ್ಕಗೊಂಡಿರಲಿ ಇರಲಿ ಎಂದು ಬೇರೆಯಾಗದೇ ಇರುತ್ತವೆ.
ಈ ವ್ಯತ್ಯಾಸವೇ ಸಾಮಾನ್ಯ ಅಸಮಮಿತಿಯನ್ನು ವಿವರಿಸುತ್ತದೆ. curl ಯಶಸ್ವಿಯಾಗುತ್ತದೆ ಏಕೆಂದರೆ ಸಾಕೆಟ್ ಮಾರ್ಗ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದರೆ SYN ಸ್ಕ್ಯಾನ್ ವಿಫಲವಾಗುತ್ತದೆ ಏಕೆಂದರೆ ಪ್ರಕ್ರಿಯೆ ಸುರಂಗದ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಕರ್ರಾಷ್ ಸಾಕೆಟ್ ತೆರೆಯಲು ಸಾಗದು. ಇದು ವಿರುದ್ಧ ಸಂದರ್ಭವನ್ನೂ ವಿವರಿಸುತ್ತದೆ: ಮಾರ್ಗ ಪ್ರೋಬ್ ಬಿಸಾಡುವುದರಿಂದ ಕರ್ರಾಷ್ ಸ್ಕ್ಯಾನ್ ಫಿಲ್ಟರ್ ಆಗಿದೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ, ಆದರೆ ಅಪ್ಲಿಕೇಶನ್ ಮಾರ್ಗ ಚೆನ್ನಾಗಿರುತ್ತದೆ.
ಎರಡೂ ಫಲಿತಾಂಶಗಳಲ್ಲಿ ಯಾವುದೂ ದೂರದ ಸೇವೆಯನ್ನು ವರ್ಣಿಸುವುದಿಲ್ಲ. ಎರಡೂ ಒಂದೇ ವಿಧಾನದ ಅಡಿಯಲ್ಲಿ ಒಂದೇ ಮಾರ್ಗವನ್ನು ವರ್ಣಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ವಿಧಾನವನ್ನು ತೀರ್ಮಾನಕ್ಕೆ ಜೋಡಿಸಿ ಇಟ್ಟುಕೊಳ್ಳಿ.
ಸಂಪರ್ಕ ಪರಿಶೀಲನೆಯನ್ನು ಒಂದು ಅನುಮೋದಿತ ಹೋಸ್ಟ್ನಲ್ಲಿ ನಡೆಸಿ
ನಿಮ್ಮ ಕಾರ್ಯ ಒಂದೇ ಹೋಸ್ಟ್ ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ನಂತರ ಕರ್ರಾಷ್ ಪ್ರವೇಶ ಬೇಡದ ಮೋಡ್ ಬಳಸಿ. ಇಲ್ಲಿನ ಉದಾಹರಣ ಗುರಿ 198.51.100.24, ಈ ರೀತಿಯ ಉದಾಹರಣಕ್ಕೆ ಕಾಯ್ಕೆಯಿರಿಸಲಾಗಿರುವ ದಸ್ತಾವೇಜು ಸ್ಥಳ.
ಒಂದು ಸಾಲು, ಒಂದು ಹೋಸ್ಟ್, ಒಂದು ಪೋರ್ಟ್, ಯಾವುದೂ ಶೋಧ ಹಂತವಿಲ್ಲ:
nmap -sT -Pn -p 443 --unprivileged 198.51.100.24-sT ಪೂರ್ಣ TCP ಸಂಪರ್ಕವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಅಪ್ಲಿಕೇಶನ್ ಬಳಸುವ ಅದೇ ಕರ್ನೆಲ್ ಮಾರ್ಗವನ್ನು ಅಭ್ಯಸಿಸುತ್ತದೆ ಮತ್ತು ಸೆರೆಹಿಡಿಯುವ ಡ್ರೈವರ್ ಬೇಕಿಲ್ಲ. -Pn ಹೋಸ್ಟ್ ಶೋಧವನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ; nmap ಸ್ಥಳೀಯ ವಿಭಾಗದ ಗುರಿಗಳಿಗೆ ಲಿಂಕ್ ಪರ್ಯಾಯದ ರಿಜಾಲ್ಯೂಶನ್ ಅನ್ನು ಇನ್ನೂ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಈ ಫ್ಲ್ಯಾಗ್ ಶೂನ್ಯ ಪೂರ್ವ ಸಂಚಾರದ ಭರವಸಿಗೆ ಅಲ್ಲ. --unprivileged nmap ಗೆ ಕರ್ರಾಷ್ ಅಥವಾ ಆಲಿಸುವ ಹಕ್ಕುಗಳಿಲ್ಲ ಎಂದು ಭಾವಿಸಲು ಹೇಳುತ್ತದೆ, ಇದು ವಿಧಾನವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ ಮತ್ತು ಯಾವುದನ್ನೂ ನೀಡುವುದಿಲ್ಲ.
ಪ್ರತಿ ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಒಂದು ಬದಲಾವಣೆಯಂತೆ ಓದಿ, ದುರಸ್ತಿಯಂತೆ ಅಲ್ಲ
ಪ್ರತಿ ಆಯ್ಕೆಯನ್ನು ವಿಧಾನದ ಬಗ್ಗೆ ಒಂದು ಹೇಳಿಕೆಯಂತೆ ಪರಿಗಣಿಸಿ. -sT, -Pn ಅಥವಾ --unprivileged ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ಮಾರ್ಗ ಸೇರಿಸುವುದಿಲ್ಲ, ದೂರದ ಬೆಂಕಿ ತೆರೆಯುವುದಿಲ್ಲ ಅಥವಾ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಪರಿಶೀಲಿಸುವುದಿಲ್ಲ. ಸಂಪರ್ಕ ಸ್ಕ್ಯಾನ್ ಸೇವೆ ದಾಖಲೆ ಮಾಡುವ ನಿಜವಾದ ಹ್ಯಾಂಡ್ಷೇಕ್ ಅನ್ನೂ ಪೂರೈಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಅನುಮೋದಿತ ಪರಿಶೀಲನೆ ಮತ್ತು ಅನುಮೋದಿತವಲ್ಲದ ಜಾಲಿ ಸರ್ವರ್ ದೃಷ್ಟಿಯಿಂದ ವ್ಯಾಪ್ತಿ ಮತ್ತು ವೇಗವನ್ನು ಹೊರತುಪಡಿಸಿ ಒಂದೇ ರೀತಿಯಂತೆ ಕಾಣುತ್ತವೆ. ಆಉಟ್ಪುಟ್ ಬದಲಾಗುವವರೆ ಆಯ್ಕೆಗಳನ್ನು ನೇರುಗೂಡಿಸುವುದು ವಿಧಾನದ ಸಮಸ್ಯೆಯನ್ನು ಜಾಲ ಕಂಡುಗಳಂತೆ ದಾಖಲೆ ಮಾಡುವ ರೀತಿ.
ಆಉಟ್ಪುಟ್ ಮುಚ್ಚಿದೆ ಎಂದು ಹೇಳಿದಾಗ, ಯಾವುದೋ ಒಂದು ರೀಸೆಟ್ನೊಂದಿಗೆ ಉತ್ತರ ನೀಡಿದೆ, ಮತ್ತು ಅದು ಮೌನದಿಂದ ಬೇರೆ ಕಂಡು. ಆಉಟ್ಪುಟ್ ಫಿಲ್ಟರ್ ಆಗಿದೆ ಎಂದು ಹೇಳಿದಾಗ, ಸಾಧನವು ಪ್ರೋಬ್ ಅಥವಾ ಅದರ ಉತ್ತರವನ್ನು ಬಿಸಾಡಿದೆ, ಮತ್ತು VPN ಆಕಸ್ಮಿಕವಾಗಿರಲಾದು. ನಿಖರವಾದ ಪದಗುಚ್ಛವನ್ನು ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಶೋಧ ಹಂತದ ತೀರ್ಪು ಮತ್ತು ಪ್ರೋಬ್ ಮಟ್ಟದ ವಿಫಲತೆ ಬೇರೆ ಬೇರೆ ಪದರಗಳನ್ನು ಸೂಚಿಸುತ್ತವೆ.
ವಿಶೇಷಾಧಿಕಾರದ ಮೋಡ್ ನಿಜವಾಗಿ ಬೇಕಿದ್ದರೆ, ಹಕ್ಕು, ಡ್ರೈವರ್ ಮತ್ತು ಇಂಟರ್ಫೇಸ್ ಜೋಡಣೆ ಬೇಂಬಲಿತವೇ ಎಂದು ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಮಾಲೀಕ ನಿರ್ಣಯಿಸುತ್ತಾರೆ. ಅದೇ ಕರೆಯನ್ನು ಉನ್ನತಗೊಳಿಸುವುದು ಅದರ ವಿಧಾನವನ್ನು ಬದಲಾಯಿಸುವುದಿಲ್ಲ.
ಸಂಚಾರ ಫಲಿತಾಂಶದಲ್ಲಿ ನಿಲ್ಲಿಸಿ, ನಂತರ ಸೇವೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ
ಪೂರೈಸಿದ ಹ್ಯಾಂಡ್ಷೇಕ್ ಒಂದು ವಿಳಾಸ, ಪೋರ್ಟ್, ಮೂಲ ಮತ್ತು ಕ್ಷಣದ ಬಗ್ಗೆ ಒಂದೇ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರ ನೀಡುತ್ತದೆ. ಬ್ಯಾಕ್ಎಂಡ್ ಆರೋಗ್ಯವಾಗಿದೆ ಎಂದು ಅದು ಸಾಬೀತು ಮಾಡುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅಥವಾ ಮುಂಭಾಗದ ಪ್ರಾಕ್ಸಿ ಸಂಪರ್ಕವನ್ನು ಸ್ವೀಕರಿಸಬಹುದು, ಅದರ ಹಿಂದೆಯ ಅಪ್ಲಿಕೇಶನ್ ನಿಂತಿರಬಹುದು.
ಸೇವೆಯ ಸ್ವಂತ ಕ್ಲೈಂಟ್ನೊಂದಿಗೆ ಮುಂದುವರಿಸಿ, ಇದರಿಂದ TLS ಗುರುತ್ವ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ವರ್ತನೆಯನ್ನು ಪ್ರತ್ಯೇಕ ಸತ್ಯಗಳಂತೆ ಗಮನಿಸಬಹುದು:
openssl s_client -connect 198.51.100.24:443 -servername staging.example.net </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
curl -sS -o /dev/null -w '%{http_code}\n' https://staging.example.net/healthಇನ್ನೂಂದು ಅಭ್ಯಾಸ ಫಲಿತಾಂಶವನ್ನು ಉಪಯೋಗಕ್ಕೆ ಇರಿಸುತ್ತದೆ. ನಿಖರವಾದ ಆದೇಶ, ಅದು ಬಳಸಿದ ಮೂಲ ವಿಳಾಸ ಮತ್ತು ಸಮಯವನ್ನು ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಆ ಸಂದರ್ಭವಿಲ್ಲದೆ ಸಂಚಾರ ಫಲಿತಾಂಶವನ್ನು ಮರುಮತ್ತು ಮಾಡಲು ಅಥವಾ ಹೋಲಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಪ್ರಮಾಣಪತ್ರವು ನೀವು ನಿರೀಕ್ಷಿಸದ ಹೋಸ್ಟ್ ಹೆಸರನ್ನು ಹೇಳಿದರೆ, ಸಂಚಾರ ಕೆಲಸ ಮಾಡಿತು ಮತ್ತು ಮಾರ್ಗನಿರ್ದೇಶನ ಎಂದೂ ಸಮಸ್ಯೆ ಆಗಿರಲಿಲ್ಲ; ದೋಷ ವರ್ಚುಅಲ್ ಹೋಸ್ಟಿಂಗ್ ಅಥವಾ DNSನಲ್ಲಿದೆ. ಹ್ಯಾಂಡ್ಷೇಕ್ ವಿಫಲವಾದರೆ, ಸುರಂಗದ ಬಗ್ಗೆ ಸಾಮಾನ್ಯೀಕರಿಸುವ ಬದಲು ಸ್ಥಳೀಯ ದೋಷ ಶ್ರೇಣಿಯನ್ನು ದಾಖಲಿಸಿ. ವ್ಯಾಪ್ತಿ ಟಿಪ್ಪಣಿಯನ್ನು ಫಲಿತಾಂಶದ ಪಕ್ಕದಲ್ಲಿ ಇಟ್ಟುಕೊಳ್ಳಿ, ಏಕೆಂದರೆ ಮುಂದಿನ ವ್ಯಕ್ತಿ ಯಾವ ವಿಧಾನ ಅದನ್ನು ಉತ್ಪನ್ನ ಮಾಡಿತು ಎಂದು ತಿಳಿಯಬೇಕು.