"ಇನ್ಸ್ಪೆಕ್ಟರ್" ಏಜೆಂಟ್ಗಳನ್ನು ಎಣಿಸೋಣ

ರಶಿಯಾದಲ್ಲಿ ನಿಷೇಧಿತ ಮಾಹಿತಿಯ ಪಟ್ಟಿಯಲ್ಲಿ ನಿರ್ಬಂಧಿಸುವ ನಿಯಂತ್ರಣವನ್ನು ಸ್ವಯಂಚಾಲಿತ ವ್ಯವಸ್ಥೆ "ಇನ್ಸ್ಪೆಕ್ಟರ್" ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತದೆ ಎಂಬುದು ರಹಸ್ಯವಲ್ಲ. ಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಇಲ್ಲಿ ಚೆನ್ನಾಗಿ ಬರೆಯಲಾಗಿದೆ Habr ನಲ್ಲಿ ಲೇಖನ, ಅದೇ ಸ್ಥಳದಿಂದ ಚಿತ್ರ:

ಪೂರೈಕೆದಾರರಲ್ಲಿ ನೇರವಾಗಿ ಸ್ಥಾಪಿಸಲಾಗಿದೆ ಮಾಡ್ಯೂಲ್ "ಏಜೆಂಟ್ ಇನ್ಸ್ಪೆಕ್ಟರ್":

"ಏಜೆಂಟ್ ಇನ್ಸ್ಪೆಕ್ಟರ್" ಮಾಡ್ಯೂಲ್ ಸ್ವಯಂಚಾಲಿತ ಸಿಸ್ಟಮ್ "ಇನ್ಸ್ಪೆಕ್ಟರ್" (ಎಎಸ್ "ಇನ್ಸ್ಪೆಕ್ಟರ್") ರ ರಚನಾತ್ಮಕ ಅಂಶವಾಗಿದೆ. ಜುಲೈ 15.1, 15.4 ರ ಫೆಡರಲ್ ಕಾನೂನಿನ 27-2006 ರ ಫೆಡರಲ್ ಕಾನೂನಿನಿಂದ ಸ್ಥಾಪಿಸಲಾದ ನಿಬಂಧನೆಗಳ ಚೌಕಟ್ಟಿನೊಳಗೆ ಟೆಲಿಕಾಂ ಆಪರೇಟರ್‌ಗಳ ಅನುಸರಣೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಈ ವ್ಯವಸ್ಥೆಯನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. "ಮಾಹಿತಿ, ಮಾಹಿತಿ ತಂತ್ರಜ್ಞಾನಗಳು ಮತ್ತು ಮಾಹಿತಿ ರಕ್ಷಣೆಯ ಮೇಲೆ. ”

AS "Revizor" ಅನ್ನು ರಚಿಸುವ ಮುಖ್ಯ ಉದ್ದೇಶವೆಂದರೆ ಜುಲೈ 15.1, 15.4 ರ ಫೆಡರಲ್ ಕಾನೂನಿನ 27-2006 ನೆಯ ಆರ್ಟಿಕಲ್ಸ್ 149-FZ "ಮಾಹಿತಿ, ಮಾಹಿತಿ ತಂತ್ರಜ್ಞಾನಗಳು ಮತ್ತು ಮಾಹಿತಿ ರಕ್ಷಣೆಯ ಕುರಿತು ಟೆಲಿಕಾಂ ಆಪರೇಟರ್‌ಗಳ ಅನುಸರಣೆಯ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಖಚಿತಪಡಿಸುವುದು. "ನಿಷೇಧಿತ ಮಾಹಿತಿಯ ಪ್ರವೇಶದ ಸತ್ಯಗಳನ್ನು ಗುರುತಿಸುವ ವಿಷಯದಲ್ಲಿ ಮತ್ತು ನಿಷೇಧಿತ ಮಾಹಿತಿಗೆ ಪ್ರವೇಶವನ್ನು ನಿರ್ಬಂಧಿಸಲು ಉಲ್ಲಂಘನೆಗಳ ಬಗ್ಗೆ ಪೋಷಕ ಸಾಮಗ್ರಿಗಳನ್ನು (ಡೇಟಾ) ಪಡೆಯುವ ವಿಷಯದಲ್ಲಿ.

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

ನಾವು ಎಣಿಸುವ ಮೊದಲು, ಇದು ಏಕೆ ಸಾಧ್ಯ ಎಂದು ನೋಡೋಣ.

ಸಿದ್ಧಾಂತದ ಒಂದು ಬಿಟ್

ಏಜೆಂಟರು HTTP(S) ವಿನಂತಿಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ಸಂಪನ್ಮೂಲದ ಲಭ್ಯತೆಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತಾರೆ, ಉದಾಹರಣೆಗೆ:

TCP, 14678  >  80, "[SYN] Seq=0"
TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678  >  80, "[ACK] Seq=1 Ack=1"

HTTP, "GET /somepage HTTP/1.1"
TCP, 80  >  14678, "[ACK] Seq=1 Ack=71"
HTTP, "HTTP/1.1 302 Found"

TCP, 14678  >  80, "[FIN, ACK] Seq=71 Ack=479"
TCP, 80  >  14678, "[FIN, ACK] Seq=479 Ack=72"
TCP, 14678  >  80, "[ACK] Seq=72 Ack=480"

ಪೇಲೋಡ್ ಜೊತೆಗೆ, ವಿನಂತಿಯು ಸಂಪರ್ಕ ಸ್ಥಾಪನೆಯ ಹಂತವನ್ನು ಸಹ ಒಳಗೊಂಡಿದೆ: ವಿನಿಮಯ SYN и SYN-ACK, ಮತ್ತು ಸಂಪರ್ಕವನ್ನು ಪೂರ್ಣಗೊಳಿಸುವ ಹಂತಗಳು: FIN-ACK.

ನಿಷೇಧಿತ ಮಾಹಿತಿಯ ರಿಜಿಸ್ಟರ್ ಹಲವಾರು ರೀತಿಯ ನಿರ್ಬಂಧಿಸುವಿಕೆಯನ್ನು ಒಳಗೊಂಡಿದೆ. ನಿಸ್ಸಂಶಯವಾಗಿ, ಐಪಿ ವಿಳಾಸ ಅಥವಾ ಡೊಮೇನ್ ಹೆಸರಿನಿಂದ ಸಂಪನ್ಮೂಲವನ್ನು ನಿರ್ಬಂಧಿಸಿದರೆ, ನಾವು ಯಾವುದೇ ವಿನಂತಿಗಳನ್ನು ನೋಡುವುದಿಲ್ಲ. ಇವುಗಳು ಅತ್ಯಂತ ವಿನಾಶಕಾರಿ ನಿರ್ಬಂಧಿಸುವಿಕೆಯ ವಿಧಗಳಾಗಿವೆ, ಇದು ಒಂದು IP ವಿಳಾಸದಲ್ಲಿ ಅಥವಾ ಡೊಮೇನ್‌ನಲ್ಲಿನ ಎಲ್ಲಾ ಮಾಹಿತಿಯಲ್ಲಿನ ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳ ಪ್ರವೇಶಿಸುವಿಕೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ. "URL ಮೂಲಕ" ನಿರ್ಬಂಧಿಸುವಿಕೆಯ ಪ್ರಕಾರವೂ ಇದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಫಿಲ್ಟರಿಂಗ್ ಸಿಸ್ಟಮ್ ನಿಖರವಾಗಿ ಏನನ್ನು ನಿರ್ಬಂಧಿಸಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು HTTP ವಿನಂತಿ ಹೆಡರ್ ಅನ್ನು ಪಾರ್ಸ್ ಮಾಡಬೇಕು. ಮತ್ತು ಅದರ ಮೊದಲು, ಮೇಲೆ ನೋಡಬಹುದಾದಂತೆ, ನೀವು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಬಹುದಾದ ಸಂಪರ್ಕ ಸ್ಥಾಪನೆಯ ಹಂತ ಇರಬೇಕು, ಏಕೆಂದರೆ ಫಿಲ್ಟರ್ ಅದನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ.

ಇದನ್ನು ಮಾಡಲು, ನೀವು ಫಿಲ್ಟರಿಂಗ್ ಸಿಸ್ಟಂನ ಕೆಲಸವನ್ನು ಸುಗಮಗೊಳಿಸಲು "URL" ಮತ್ತು HTTP ನಿರ್ಬಂಧಿಸುವ ಪ್ರಕಾರದೊಂದಿಗೆ ಸೂಕ್ತವಾದ ಉಚಿತ ಡೊಮೇನ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ, ಮೇಲಾಗಿ ದೀರ್ಘಾವಧಿಯಿಂದ ಕೈಬಿಡಲಾಗಿದೆ, ಏಜೆಂಟ್‌ಗಳನ್ನು ಹೊರತುಪಡಿಸಿ ಬಾಹ್ಯ ದಟ್ಟಣೆಯ ಪ್ರವೇಶವನ್ನು ಕಡಿಮೆ ಮಾಡಲು. ಈ ಕಾರ್ಯವು ಕಷ್ಟಕರವಲ್ಲ ಎಂದು ಬದಲಾಯಿತು; ನಿಷೇಧಿತ ಮಾಹಿತಿಯ ರಿಜಿಸ್ಟರ್‌ನಲ್ಲಿ ಮತ್ತು ಪ್ರತಿ ರುಚಿಗೆ ಸಾಕಷ್ಟು ಉಚಿತ ಡೊಮೇನ್‌ಗಳಿವೆ. ಆದ್ದರಿಂದ, ಡೊಮೇನ್ ಅನ್ನು ಖರೀದಿಸಲಾಗಿದೆ ಮತ್ತು VPS ಚಾಲನೆಯಲ್ಲಿರುವ IP ವಿಳಾಸಗಳಿಗೆ ಲಿಂಕ್ ಮಾಡಲಾಗಿದೆ tcpdump ಮತ್ತು ಎಣಿಕೆ ಪ್ರಾರಂಭವಾಯಿತು.

"ಲೆಕ್ಕ ಪರಿಶೋಧಕರ" ಲೆಕ್ಕಪರಿಶೋಧನೆ

ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ ನಿಯಂತ್ರಿತ ಕ್ರಿಯೆಯನ್ನು ಸೂಚಿಸುವ ವಿನಂತಿಗಳ ಆವರ್ತಕ ಸ್ಫೋಟಗಳನ್ನು ನಾನು ನಿರೀಕ್ಷಿಸುತ್ತೇನೆ. ನಾನು ಅದನ್ನು ನೋಡಲಿಲ್ಲ ಎಂದು ಹೇಳುವುದು ಅಸಾಧ್ಯ, ಆದರೆ ಸ್ಪಷ್ಟವಾದ ಚಿತ್ರವಿಲ್ಲ:

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

ಒಂದು ಸಣ್ಣ ಸಾಹಿತ್ಯದ ವ್ಯತಿರಿಕ್ತತೆ. ಒಂದು ದಿನದ ನಂತರ ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ, ನನ್ನ ಹೋಸ್ಟಿಂಗ್ ಪೂರೈಕೆದಾರರು ಸುವ್ಯವಸ್ಥಿತವಾದ ವಿಷಯದೊಂದಿಗೆ ಪತ್ರವನ್ನು ಕಳುಹಿಸಿದ್ದಾರೆ, ನಿಮ್ಮ ಸೌಲಭ್ಯಗಳು RKN ನಿಷೇಧಿತ ಪಟ್ಟಿಯಿಂದ ಸಂಪನ್ಮೂಲವನ್ನು ಒಳಗೊಂಡಿವೆ ಎಂದು ಹೇಳಿದರು, ಆದ್ದರಿಂದ ಅದನ್ನು ನಿರ್ಬಂಧಿಸಲಾಗಿದೆ. ಮೊದಲಿಗೆ ನನ್ನ ಖಾತೆಯನ್ನು ನಿರ್ಬಂಧಿಸಲಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸಿದೆ, ಇದು ಹಾಗಲ್ಲ. ಆಗ ಅವರು ನನಗೆ ಈಗಾಗಲೇ ತಿಳಿದಿರುವ ವಿಷಯದ ಬಗ್ಗೆ ನನಗೆ ಎಚ್ಚರಿಕೆ ನೀಡುತ್ತಿದ್ದಾರೆ ಎಂದು ನಾನು ಭಾವಿಸಿದೆ. ಆದರೆ ಹೋಸ್ಟರ್ ನನ್ನ ಡೊಮೇನ್ ಮುಂದೆ ಅದರ ಫಿಲ್ಟರ್ ಅನ್ನು ಆನ್ ಮಾಡಿದೆ ಮತ್ತು ಇದರ ಪರಿಣಾಮವಾಗಿ ನಾನು ಡಬಲ್ ಫಿಲ್ಟರಿಂಗ್ ಅಡಿಯಲ್ಲಿ ಬಂದಿದ್ದೇನೆ: ಪೂರೈಕೆದಾರರಿಂದ ಮತ್ತು ಹೋಸ್ಟರ್ನಿಂದ. ಫಿಲ್ಟರ್ ವಿನಂತಿಗಳ ತುದಿಗಳನ್ನು ಮಾತ್ರ ರವಾನಿಸಿದೆ: FIN-ACK и RST ನಿಷೇಧಿತ URL ನಲ್ಲಿ ಎಲ್ಲಾ HTTP ಅನ್ನು ಕತ್ತರಿಸುವುದು. ಮೇಲಿನ ಗ್ರಾಫ್‌ನಿಂದ ನೀವು ನೋಡುವಂತೆ, ಮೊದಲ ದಿನದ ನಂತರ ನಾನು ಕಡಿಮೆ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಲು ಪ್ರಾರಂಭಿಸಿದೆ, ಆದರೆ ನಾನು ಅದನ್ನು ಇನ್ನೂ ಸ್ವೀಕರಿಸಿದ್ದೇನೆ, ಇದು ವಿನಂತಿಯ ಮೂಲಗಳನ್ನು ಎಣಿಸುವ ಕಾರ್ಯಕ್ಕೆ ಸಾಕಷ್ಟು ಸಾಕಾಗಿತ್ತು.

ವಿಷಯಕ್ಕೆ ಬನ್ನಿ. ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಎರಡು ಸ್ಫೋಟಗಳು ಪ್ರತಿದಿನ ಸ್ಪಷ್ಟವಾಗಿ ಗೋಚರಿಸುತ್ತವೆ, ಮೊದಲನೆಯದು ಚಿಕ್ಕದಾಗಿದೆ, ಮಧ್ಯರಾತ್ರಿಯ ನಂತರ ಮಾಸ್ಕೋ ಸಮಯದ ನಂತರ, ಎರಡನೆಯದು 6 ರವರೆಗೆ ಬಾಲದೊಂದಿಗೆ 12 ಗಂಟೆಗೆ ಹತ್ತಿರದಲ್ಲಿದೆ. ಶಿಖರವು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಸಂಭವಿಸುವುದಿಲ್ಲ. ಮೊದಲಿಗೆ, ಏಜೆಂಟ್‌ಗಳ ತಪಾಸಣೆಗಳನ್ನು ನಿಯತಕಾಲಿಕವಾಗಿ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ ಎಂಬ ಊಹೆಯ ಆಧಾರದ ಮೇಲೆ ಈ ಅವಧಿಗಳಲ್ಲಿ ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ಎಲ್ಲಾ ಅವಧಿಗಳಲ್ಲಿ ಮಾತ್ರ ಬೀಳುವ IP ವಿಳಾಸಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ನಾನು ಬಯಸುತ್ತೇನೆ. ಆದರೆ ಎಚ್ಚರಿಕೆಯಿಂದ ಪರಿಶೀಲಿಸಿದಾಗ, ಇತರ ಆವರ್ತನಗಳೊಂದಿಗೆ, ಪ್ರತಿ ಗಂಟೆಗೆ ಒಂದು ವಿನಂತಿಯವರೆಗೆ ಇತರ ಮಧ್ಯಂತರಗಳಲ್ಲಿ ಬೀಳುವ ಅವಧಿಗಳನ್ನು ನಾನು ತ್ವರಿತವಾಗಿ ಕಂಡುಹಿಡಿದಿದ್ದೇನೆ. ನಂತರ ನಾನು ಸಮಯ ವಲಯಗಳ ಬಗ್ಗೆ ಯೋಚಿಸಿದೆ ಮತ್ತು ಬಹುಶಃ ಅದು ಅವರೊಂದಿಗೆ ಏನಾದರೂ ಮಾಡಿರಬಹುದು ಎಂದು ನಾನು ಭಾವಿಸಿದೆ, ನಂತರ ಸಾಮಾನ್ಯವಾಗಿ ಸಿಸ್ಟಮ್ ಜಾಗತಿಕವಾಗಿ ಸಿಂಕ್ರೊನೈಸ್ ಆಗದಿರಬಹುದು ಎಂದು ನಾನು ಭಾವಿಸಿದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, NAT ಬಹುಶಃ ಒಂದು ಪಾತ್ರವನ್ನು ವಹಿಸುತ್ತದೆ ಮತ್ತು ಅದೇ ಏಜೆಂಟ್ ವಿವಿಧ ಸಾರ್ವಜನಿಕ IP ಗಳಿಂದ ವಿನಂತಿಗಳನ್ನು ಮಾಡಬಹುದು.

ನನ್ನ ಆರಂಭಿಕ ಗುರಿ ನಿಖರವಾಗಿಲ್ಲದ ಕಾರಣ, ನಾನು ಒಂದು ವಾರದಲ್ಲಿ ನನಗೆ ಸಿಕ್ಕಿದ ಎಲ್ಲಾ ವಿಳಾಸಗಳನ್ನು ಎಣಿಸಿದೆ ಮತ್ತು ಸಿಕ್ಕಿತು - 2791. ಒಂದು ವಿಳಾಸದಿಂದ ಸ್ಥಾಪಿಸಲಾದ TCP ಸೆಷನ್‌ಗಳ ಸಂಖ್ಯೆಯು ಸರಾಸರಿ 4 ಆಗಿದ್ದು, ಸರಾಸರಿ 2. ಪ್ರತಿ ವಿಳಾಸಕ್ಕೆ ಟಾಪ್ ಸೆಷನ್‌ಗಳು: 464, 231, 149, 83, 77. ಮಾದರಿಯ 95% ರಿಂದ ಪ್ರತಿ ವಿಳಾಸಕ್ಕೆ 8 ಸೆಷನ್‌ಗಳು. ಸರಾಸರಿಯು ತುಂಬಾ ಹೆಚ್ಚಿಲ್ಲ, ಗ್ರಾಫ್ ಸ್ಪಷ್ಟವಾದ ದೈನಂದಿನ ಆವರ್ತಕತೆಯನ್ನು ತೋರಿಸುತ್ತದೆ ಎಂದು ನಾನು ನಿಮಗೆ ನೆನಪಿಸುತ್ತೇನೆ, ಆದ್ದರಿಂದ 4 ದಿನಗಳಲ್ಲಿ 8 ರಿಂದ 7 ರವರೆಗೆ ಏನನ್ನಾದರೂ ನಿರೀಕ್ಷಿಸಬಹುದು. ಒಮ್ಮೆ ಸಂಭವಿಸುವ ಎಲ್ಲಾ ಸೆಷನ್‌ಗಳನ್ನು ನಾವು ಹೊರಹಾಕಿದರೆ, ನಾವು 5 ಕ್ಕೆ ಸಮಾನವಾದ ಸರಾಸರಿಯನ್ನು ಪಡೆಯುತ್ತೇವೆ. ಆದರೆ ಸ್ಪಷ್ಟ ಮಾನದಂಡದ ಆಧಾರದ ಮೇಲೆ ನಾನು ಅವುಗಳನ್ನು ಹೊರಗಿಡಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, ಯಾದೃಚ್ಛಿಕ ಪರಿಶೀಲನೆಯು ನಿಷೇಧಿತ ಸಂಪನ್ಮೂಲಕ್ಕಾಗಿ ವಿನಂತಿಗಳಿಗೆ ಸಂಬಂಧಿಸಿದೆ ಎಂದು ತೋರಿಸಿದೆ.

ವಿಳಾಸಗಳು ವಿಳಾಸಗಳಾಗಿವೆ, ಆದರೆ ಅಂತರ್ಜಾಲದಲ್ಲಿ, ಸ್ವಾಯತ್ತ ವ್ಯವಸ್ಥೆಗಳು - AS, ಇದು ಹೆಚ್ಚು ಮಹತ್ವದ್ದಾಗಿದೆ 1510, ಸರಾಸರಿ 2 ವಿಳಾಸಗಳು ಪ್ರತಿ AS ಗೆ ಸರಾಸರಿ 1. ಪ್ರತಿ AS ಗೆ ಉನ್ನತ ವಿಳಾಸಗಳು: 288, 77, 66, 39, 27. ಮಾದರಿಯ ಗರಿಷ್ಠ 95% ಪ್ರತಿ AS ಗೆ 4 ವಿಳಾಸಗಳು. ಇಲ್ಲಿ ಸರಾಸರಿ ನಿರೀಕ್ಷಿಸಲಾಗಿದೆ - ಪ್ರತಿ ಪೂರೈಕೆದಾರರಿಗೆ ಒಬ್ಬ ಏಜೆಂಟ್. ನಾವು ಅಗ್ರಸ್ಥಾನವನ್ನು ಸಹ ನಿರೀಕ್ಷಿಸುತ್ತೇವೆ - ಅದರಲ್ಲಿ ದೊಡ್ಡ ಆಟಗಾರರಿದ್ದಾರೆ. ದೊಡ್ಡ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ, ಏಜೆಂಟ್‌ಗಳು ಪ್ರಾಯಶಃ ಆಪರೇಟರ್‌ನ ಉಪಸ್ಥಿತಿಯ ಪ್ರತಿಯೊಂದು ಪ್ರದೇಶದಲ್ಲಿ ನೆಲೆಗೊಂಡಿರಬೇಕು ಮತ್ತು NAT ಬಗ್ಗೆ ಮರೆಯಬೇಡಿ. ನಾವು ಅದನ್ನು ದೇಶದ ಮೂಲಕ ತೆಗೆದುಕೊಂಡರೆ, ಗರಿಷ್ಠವು ಹೀಗಿರುತ್ತದೆ: 1409 - RU, 42 - UA, 23 - CZ, 36 ಇತರ ಪ್ರದೇಶಗಳಿಂದ, RIPE NCC ಅಲ್ಲ. ರಷ್ಯಾದ ಹೊರಗಿನಿಂದ ವಿನಂತಿಗಳು ಗಮನ ಸೆಳೆಯುತ್ತವೆ. ಡೇಟಾವನ್ನು ಭರ್ತಿ ಮಾಡುವಾಗ ಜಿಯೋಲೊಕೇಶನ್ ದೋಷಗಳು ಅಥವಾ ರಿಜಿಸ್ಟ್ರಾರ್ ದೋಷಗಳಿಂದ ಇದನ್ನು ಬಹುಶಃ ವಿವರಿಸಬಹುದು. ಅಥವಾ ರಷ್ಯಾದ ಕಂಪನಿಯು ರಷ್ಯಾದ ಬೇರುಗಳನ್ನು ಹೊಂದಿಲ್ಲದಿರಬಹುದು ಅಥವಾ ವಿದೇಶಿ ಪ್ರತಿನಿಧಿ ಕಚೇರಿಯನ್ನು ಹೊಂದಿರಬಹುದು ಏಕೆಂದರೆ ಅದು ಸುಲಭವಾಗಿದೆ, ಇದು ವಿದೇಶಿ ಸಂಸ್ಥೆ RIPE NCC ಯೊಂದಿಗೆ ವ್ಯವಹರಿಸುವಾಗ ನೈಸರ್ಗಿಕವಾಗಿದೆ. ಕೆಲವು ಭಾಗವು ನಿಸ್ಸಂದೇಹವಾಗಿ ಅತಿರೇಕವಾಗಿದೆ, ಆದರೆ ಅದನ್ನು ಪ್ರತ್ಯೇಕಿಸುವುದು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಕಷ್ಟಕರವಾಗಿದೆ, ಏಕೆಂದರೆ ಸಂಪನ್ಮೂಲವು ನಿರ್ಬಂಧಿಸುವ ಹಂತದಲ್ಲಿದೆ, ಮತ್ತು ಎರಡನೇ ದಿನದಿಂದ ಡಬಲ್ ಬ್ಲಾಕಿಂಗ್ ಅಡಿಯಲ್ಲಿ, ಮತ್ತು ಹೆಚ್ಚಿನ ಅವಧಿಗಳು ಹಲವಾರು ಸೇವಾ ಪ್ಯಾಕೆಟ್‌ಗಳ ವಿನಿಮಯವಾಗಿದೆ. ಇದು ಒಂದು ಸಣ್ಣ ಭಾಗ ಎಂದು ಒಪ್ಪಿಕೊಳ್ಳೋಣ.

ಈ ಸಂಖ್ಯೆಗಳನ್ನು ಈಗಾಗಲೇ ರಷ್ಯಾದಲ್ಲಿ ಪೂರೈಕೆದಾರರ ಸಂಖ್ಯೆಯೊಂದಿಗೆ ಹೋಲಿಸಬಹುದು. RKN ಪ್ರಕಾರ "ದತ್ತಾಂಶ ರವಾನೆಗಾಗಿ ಸಂವಹನ ಸೇವೆಗಳು, ಧ್ವನಿಯನ್ನು ಹೊರತುಪಡಿಸಿ" ಗಾಗಿ ಪರವಾನಗಿಗಳು - 6387, ಆದರೆ ಇದು ಮೇಲಿನಿಂದ ಅತಿ ಹೆಚ್ಚು ಅಂದಾಜು, ಈ ಎಲ್ಲಾ ಪರವಾನಗಿಗಳು ಏಜೆಂಟ್ ಅನ್ನು ಸ್ಥಾಪಿಸುವ ಅಗತ್ಯವಿರುವ ಇಂಟರ್ನೆಟ್ ಪೂರೈಕೆದಾರರಿಗೆ ನಿರ್ದಿಷ್ಟವಾಗಿ ಅನ್ವಯಿಸುವುದಿಲ್ಲ. RIPE NCC ವಲಯದಲ್ಲಿ ಇದೇ ರೀತಿಯ ಸಂಖ್ಯೆಯ AS ಗಳನ್ನು ರಷ್ಯಾದಲ್ಲಿ ನೋಂದಾಯಿಸಲಾಗಿದೆ - 6230, ಅದರಲ್ಲಿ ಎಲ್ಲರೂ ಪೂರೈಕೆದಾರರಲ್ಲ. UserSide ಹೆಚ್ಚು ಕಟ್ಟುನಿಟ್ಟಾದ ಲೆಕ್ಕಾಚಾರವನ್ನು ಮಾಡಿದೆ ಮತ್ತು 3940 ರಲ್ಲಿ 2017 ಕಂಪನಿಗಳನ್ನು ಸ್ವೀಕರಿಸಿದೆ ಮತ್ತು ಇದು ಮೇಲಿನಿಂದ ಅಂದಾಜು ಆಗಿದೆ. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಎರಡೂವರೆ ಪಟ್ಟು ಕಡಿಮೆ ಸಂಖ್ಯೆಯ ಪ್ರಕಾಶಿತ ಎಎಸ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಆದರೆ ಇಲ್ಲಿ ಎಎಸ್ ಒದಗಿಸುವವರಿಗೆ ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಸಮಾನವಾಗಿಲ್ಲ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಯೋಗ್ಯವಾಗಿದೆ. ಕೆಲವು ಪೂರೈಕೆದಾರರು ತಮ್ಮದೇ ಆದ AS ಅನ್ನು ಹೊಂದಿಲ್ಲ, ಕೆಲವರು ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚಿನದನ್ನು ಹೊಂದಿದ್ದಾರೆ. ಪ್ರತಿಯೊಬ್ಬರೂ ಇನ್ನೂ ಏಜೆಂಟ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ ಎಂದು ನಾವು ಭಾವಿಸಿದರೆ, ಯಾರಾದರೂ ಇತರರಿಗಿಂತ ಹೆಚ್ಚು ಬಲವಾಗಿ ಫಿಲ್ಟರ್ ಮಾಡುತ್ತಾರೆ, ಆದ್ದರಿಂದ ಅವರ ವಿನಂತಿಗಳು ಕಸದಿಂದ ಪ್ರತ್ಯೇಕಿಸಲಾಗುವುದಿಲ್ಲ, ಅವರು ಅವರನ್ನು ತಲುಪಿದರೆ. ಆದರೆ ಸ್ಥೂಲವಾದ ಮೌಲ್ಯಮಾಪನಕ್ಕೆ ಇದು ಸಾಕಷ್ಟು ಸಹನೀಯವಾಗಿದೆ, ನನ್ನ ಮೇಲ್ವಿಚಾರಣೆಯಿಂದ ಏನಾದರೂ ಕಳೆದುಹೋದರೂ ಸಹ.

ಡಿಪಿಐ ಬಗ್ಗೆ

ನನ್ನ ಹೋಸ್ಟಿಂಗ್ ಪೂರೈಕೆದಾರರು ಎರಡನೇ ದಿನದಿಂದ ಅದರ ಫಿಲ್ಟರ್ ಅನ್ನು ಆನ್ ಮಾಡಿದ್ದಾರೆ ಎಂಬ ಅಂಶದ ಹೊರತಾಗಿಯೂ, ಮೊದಲ ದಿನದ ಮಾಹಿತಿಯ ಆಧಾರದ ಮೇಲೆ ನಿರ್ಬಂಧಿಸುವಿಕೆಯು ಯಶಸ್ವಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಎಂದು ನಾವು ತೀರ್ಮಾನಿಸಬಹುದು. ಕೇವಲ 4 ಮೂಲಗಳು ಮಾತ್ರ ಪ್ರವೇಶಿಸಲು ಸಾಧ್ಯವಾಯಿತು ಮತ್ತು HTTP ಮತ್ತು TCP ಸೆಷನ್‌ಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪೂರ್ಣಗೊಳಿಸಿದೆ (ಮೇಲಿನ ಉದಾಹರಣೆಯಲ್ಲಿರುವಂತೆ). ಇನ್ನೂ 460 ಕಳುಹಿಸಬಹುದು GET, ಆದರೆ ಅಧಿವೇಶನವನ್ನು ತಕ್ಷಣವೇ ಕೊನೆಗೊಳಿಸಲಾಗುತ್ತದೆ RST. ಗಮನ ಕೊಡಿ TTL:

TTL 50, TCP, 14678  >  80, "[SYN] Seq=0"
TTL 64, TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TTL 50, TCP, 14678  >  80, "[ACK] Seq=1 Ack=1"

HTTP, "GET /filteredpage HTTP/1.1"
TTL 64, TCP, 80  >  14678, "[ACK] Seq=1 Ack=294"

#Вот это прислал фильтр
TTL 53, TCP, 14678  >  80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678  >  80, "[RST] Seq=3458729893"

HTTP, "HTTP/1.1 302 Found"

#А это попытка исходного узла получить потерю
TTL 50, TCP ACKed unseen segment, 14678 > 80, "[ACK] Seq=294 Ack=145"

TTL 50, TCP, 14678  >  80, "[FIN, ACK] Seq=294 Ack=145"
TTL 64, TCP, 80  >  14678, "[FIN, ACK] Seq=171 Ack=295"

TTL 50, TCP Dup ACK 14678 > 80 "[ACK] Seq=295 Ack=145"

#Исходный узел понимает что сессия разрушена
TTL 50, TCP, 14678  >  80, "[RST] Seq=294"
TTL 50, TCP, 14678  >  80, "[RST] Seq=295"

ಇದರ ವ್ಯತ್ಯಾಸಗಳು ವಿಭಿನ್ನವಾಗಿರಬಹುದು: ಕಡಿಮೆ RST ಅಥವಾ ಹೆಚ್ಚಿನ ಮರುಪ್ರಸಾರಗಳು - ಫಿಲ್ಟರ್ ಮೂಲ ನೋಡ್‌ಗೆ ಏನು ಕಳುಹಿಸುತ್ತದೆ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು ಅತ್ಯಂತ ವಿಶ್ವಾಸಾರ್ಹ ಟೆಂಪ್ಲೇಟ್ ಆಗಿದೆ, ಇದು ವಿನಂತಿಸಿದ ನಿಷೇಧಿತ ಸಂಪನ್ಮೂಲ ಎಂದು ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ. ಜೊತೆಗೆ ಅಧಿವೇಶನದಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುವ ಉತ್ತರ ಯಾವಾಗಲೂ ಇರುತ್ತದೆ TTL ಹಿಂದಿನ ಮತ್ತು ನಂತರದ ಪ್ಯಾಕೇಜ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚು.

ಉಳಿದವರಿಂದ ನೋಡಲೂ ಸಾಧ್ಯವಿಲ್ಲ GET:

TTL 50, TCP, 14678  >  80, "[SYN] Seq=0"
TTL 64, TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"

#Вот это прислал фильтр
TTL 53, TCP, 14678  >  80, "[RST] Seq=1"

ಅಥವಾ ಹೀಗೆ:

TTL 50, TCP, 14678  >  80, "[SYN] Seq=0"
TTL 64, TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TTL 50, TCP, 14678  >  80, "[ACK] Seq=1 Ack=1"

#Вот это прислал фильтр
TTL 53, TCP, 14678  >  80, "[RST, PSH] Seq=1"

TTL 50, TCP ACKed unseen segment, 14678 > 80, "[FIN, ACK] Seq=89 Ack=172"
TTL 50, TCP ACKed unseen segment, 14678 > 80, "[FIN, ACK] Seq=89 Ack=172"

#Опять фильтр, много раз
TTL 53, TCP, 14678  >  80, "[RST, PSH] Seq=1"
...

ವ್ಯತ್ಯಾಸವು ಖಂಡಿತವಾಗಿಯೂ ಗೋಚರಿಸುತ್ತದೆ TTL ಫಿಲ್ಟರ್‌ನಿಂದ ಏನಾದರೂ ಬಂದರೆ. ಆದರೆ ಆಗಾಗ್ಗೆ ಏನೂ ಬರುವುದಿಲ್ಲ:

TCP, 14678  >  80, "[SYN] Seq=0"
TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TCP Retransmission, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
...

ಅಥವಾ ಹೀಗೆ:

TCP, 14678  >  80, "[SYN] Seq=0"
TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678  >  80, "[ACK] Seq=1 Ack=1"

#Прошло несколько секунд без трафика

TCP, 80  >  14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...

ಮತ್ತು ಇದೆಲ್ಲವೂ ಪುನರಾವರ್ತನೆಯಾಗುತ್ತದೆ ಮತ್ತು ಪುನರಾವರ್ತನೆಯಾಗುತ್ತದೆ ಮತ್ತು ಪುನರಾವರ್ತಿಸಲಾಗುತ್ತದೆ, ಗ್ರಾಫ್ನಲ್ಲಿ ನೋಡಬಹುದಾದಂತೆ, ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಬಾರಿ, ಪ್ರತಿದಿನ.

IPv6 ಬಗ್ಗೆ

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

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

ನಿರ್ಬಂಧಿಸುವುದು ಮತ್ತು ಏಜೆಂಟ್‌ಗಳು IPv6 ಗೆ ಒಂದು ದೊಡ್ಡ ಅಡಚಣೆಯಾಗಿದೆ, ಅದರ ಅನುಷ್ಠಾನವು ತುಂಬಾ ವೇಗವಾಗಿ ಚಲಿಸುತ್ತಿಲ್ಲ. ಇದು ದುಃಖಕರವಾಗಿದೆ. ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಿದವರು ತಮ್ಮ ಬಗ್ಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಹೆಮ್ಮೆಪಡಬಹುದು.

ತೀರ್ಮಾನಕ್ಕೆ

ನಾನು 100% ನಿಖರತೆಗಾಗಿ ಶ್ರಮಿಸಲಿಲ್ಲ, ದಯವಿಟ್ಟು ಇದಕ್ಕಾಗಿ ನನ್ನನ್ನು ಕ್ಷಮಿಸಿ, ಯಾರಾದರೂ ಈ ಕೆಲಸವನ್ನು ಹೆಚ್ಚಿನ ನಿಖರತೆಯೊಂದಿಗೆ ಪುನರಾವರ್ತಿಸಲು ಬಯಸುತ್ತಾರೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಈ ವಿಧಾನವು ತಾತ್ವಿಕವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆಯೇ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ನನಗೆ ಮುಖ್ಯವಾಗಿತ್ತು. ಉತ್ತರ ಹೌದು. ಪಡೆದ ಅಂಕಿಅಂಶಗಳು, ಮೊದಲ ಅಂದಾಜಿನಂತೆ, ನಾನು ಭಾವಿಸುತ್ತೇನೆ, ಸಾಕಷ್ಟು ವಿಶ್ವಾಸಾರ್ಹ.

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

ನನ್ನ VPS ಗಾಗಿ ಹೋಸ್ಟರ್ ತನ್ನದೇ ಆದ ಫಿಲ್ಟರ್ ಅನ್ನು ಸಹ ಒಳಗೊಂಡಿರುತ್ತದೆ ಎಂದು ನಾನು ಸಂಪೂರ್ಣವಾಗಿ ನಿರೀಕ್ಷಿಸಿರಲಿಲ್ಲ. ಬಹುಶಃ ಇದು ಸಾಮಾನ್ಯ ಅಭ್ಯಾಸವಾಗಿದೆ. ಕೊನೆಯಲ್ಲಿ, RKN ಹೋಸ್ಟರ್‌ಗೆ ಸಂಪನ್ಮೂಲವನ್ನು ಅಳಿಸಲು ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ಆದರೆ ಇದು ನನಗೆ ಆಶ್ಚರ್ಯವಾಗಲಿಲ್ಲ ಮತ್ತು ಕೆಲವು ರೀತಿಯಲ್ಲಿ ನನ್ನ ಅನುಕೂಲಕ್ಕೆ ಸಹ ಕೆಲಸ ಮಾಡಿದೆ. ಫಿಲ್ಟರ್ ಬಹಳ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ನಿಷೇಧಿತ URL ಗೆ ಎಲ್ಲಾ ಸರಿಯಾದ HTTP ವಿನಂತಿಗಳನ್ನು ಕಡಿತಗೊಳಿಸಿತು, ಆದರೆ ಪೂರೈಕೆದಾರರ ಫಿಲ್ಟರ್ ಮೂಲಕ ಹಿಂದೆ ಹಾದುಹೋದ ಸರಿಯಾದವುಗಳು ಅವುಗಳನ್ನು ತಲುಪಿಲ್ಲ, ಆದರೂ ಅಂತ್ಯಗಳ ರೂಪದಲ್ಲಿ ಮಾತ್ರ: FIN-ACK и RST - ಮೈನಸ್‌ಗೆ ಮೈನಸ್ ಮತ್ತು ಇದು ಬಹುತೇಕ ಪ್ಲಸ್ ಆಗಿ ಹೊರಹೊಮ್ಮಿತು. ಮೂಲಕ, IPv6 ಅನ್ನು ಹೋಸ್ಟರ್‌ನಿಂದ ಫಿಲ್ಟರ್ ಮಾಡಲಾಗಿಲ್ಲ. ಸಹಜವಾಗಿ, ಇದು ಸಂಗ್ರಹಿಸಿದ ವಸ್ತುಗಳ ಗುಣಮಟ್ಟವನ್ನು ಪರಿಣಾಮ ಬೀರಿತು, ಆದರೆ ಇದು ಇನ್ನೂ ಆವರ್ತನವನ್ನು ನೋಡಲು ಸಾಧ್ಯವಾಗಿಸಿತು. ಸಂಪನ್ಮೂಲಗಳನ್ನು ಇರಿಸಲು ಸೈಟ್ ಅನ್ನು ಆಯ್ಕೆಮಾಡುವಾಗ ಇದು ಒಂದು ಪ್ರಮುಖ ಅಂಶವಾಗಿದೆ ಎಂದು ಅದು ಬದಲಾಯಿತು; ನಿಷೇಧಿತ ಸೈಟ್‌ಗಳ ಪಟ್ಟಿ ಮತ್ತು RKN ನಿಂದ ವಿನಂತಿಗಳೊಂದಿಗೆ ಕೆಲಸವನ್ನು ಸಂಘಟಿಸುವ ವಿಷಯದಲ್ಲಿ ಆಸಕ್ತಿ ವಹಿಸಲು ಮರೆಯಬೇಡಿ.

ಆರಂಭದಲ್ಲಿ, ನಾನು AS "ಇನ್‌ಸ್ಪೆಕ್ಟರ್" ಅನ್ನು ಹೋಲಿಸಿದೆ RIPE ಅಟ್ಲಾಸ್. ಈ ಹೋಲಿಕೆಯು ಸಾಕಷ್ಟು ಸಮರ್ಥನೆಯಾಗಿದೆ ಮತ್ತು ಏಜೆಂಟ್‌ಗಳ ದೊಡ್ಡ ಜಾಲವು ಪ್ರಯೋಜನಕಾರಿಯಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ದೇಶದ ವಿವಿಧ ಭಾಗಗಳಲ್ಲಿ ವಿವಿಧ ಪೂರೈಕೆದಾರರಿಂದ ಸಂಪನ್ಮೂಲ ಲಭ್ಯತೆಯ ಗುಣಮಟ್ಟವನ್ನು ನಿರ್ಧರಿಸುವುದು. ನೀವು ವಿಳಂಬಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಬಹುದು, ನೀವು ಗ್ರಾಫ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಬಹುದು, ನೀವು ಎಲ್ಲವನ್ನೂ ವಿಶ್ಲೇಷಿಸಬಹುದು ಮತ್ತು ಸ್ಥಳೀಯವಾಗಿ ಮತ್ತು ಜಾಗತಿಕವಾಗಿ ಸಂಭವಿಸುವ ಬದಲಾವಣೆಗಳನ್ನು ನೋಡಬಹುದು. ಇದು ಅತ್ಯಂತ ನೇರವಾದ ಮಾರ್ಗವಲ್ಲ, ಆದರೆ ಖಗೋಳಶಾಸ್ತ್ರಜ್ಞರು "ಪ್ರಮಾಣಿತ ಮೇಣದಬತ್ತಿಗಳನ್ನು" ಬಳಸುತ್ತಾರೆ, ಏಜೆಂಟ್ಗಳನ್ನು ಏಕೆ ಬಳಸಬಾರದು? ಅವರ ಪ್ರಮಾಣಿತ ನಡವಳಿಕೆಯನ್ನು ತಿಳಿದುಕೊಳ್ಳುವುದು (ಕಂಡುಕೊಂಡ ನಂತರ), ನೀವು ಅವರ ಸುತ್ತಲೂ ಸಂಭವಿಸುವ ಬದಲಾವಣೆಗಳನ್ನು ನಿರ್ಧರಿಸಬಹುದು ಮತ್ತು ಒದಗಿಸಿದ ಸೇವೆಗಳ ಗುಣಮಟ್ಟವನ್ನು ಇದು ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ, ನೀವು ಸ್ವತಂತ್ರವಾಗಿ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಪ್ರೋಬ್ಗಳನ್ನು ಇರಿಸುವ ಅಗತ್ಯವಿಲ್ಲ; Roskomnadzor ಈಗಾಗಲೇ ಅವುಗಳನ್ನು ಸ್ಥಾಪಿಸಿದೆ.

ನಾನು ಸ್ಪರ್ಶಿಸಲು ಬಯಸುವ ಇನ್ನೊಂದು ಅಂಶವೆಂದರೆ ಪ್ರತಿಯೊಂದು ಸಾಧನವೂ ಆಯುಧವಾಗಬಹುದು. AS "ಇನ್‌ಸ್ಪೆಕ್ಟರ್" ಒಂದು ಮುಚ್ಚಿದ ನೆಟ್‌ವರ್ಕ್ ಆಗಿದೆ, ಆದರೆ ನಿಷೇಧಿತ ಪಟ್ಟಿಯಿಂದ ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುವ ಮೂಲಕ ಏಜೆಂಟ್‌ಗಳು ಎಲ್ಲರಿಗೂ ಹಸ್ತಾಂತರಿಸುತ್ತಾರೆ. ಅಂತಹ ಸಂಪನ್ಮೂಲವನ್ನು ಹೊಂದಿರುವುದು ಯಾವುದೇ ಸಮಸ್ಯೆಗಳನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುವುದಿಲ್ಲ. ಒಟ್ಟಾರೆಯಾಗಿ, ಏಜೆಂಟರ ಮೂಲಕ ಪೂರೈಕೆದಾರರು, ಅರಿವಿಲ್ಲದೆ, ತಮ್ಮ ನೆಟ್‌ವರ್ಕ್ ಕುರಿತು ಬಹುಶಃ ಮೌಲ್ಯಯುತವಾಗಿರುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನದನ್ನು ತಿಳಿಸಿ: DPI ಮತ್ತು DNS ಪ್ರಕಾರಗಳು, ಏಜೆಂಟ್‌ನ ಸ್ಥಳ (ಸೆಂಟ್ರಲ್ ನೋಡ್ ಮತ್ತು ಸೇವಾ ನೆಟ್‌ವರ್ಕ್?), ವಿಳಂಬ ಮತ್ತು ನಷ್ಟಗಳ ನೆಟ್‌ವರ್ಕ್ ಗುರುತುಗಳು - ಮತ್ತು ಇದು ಅತ್ಯಂತ ಸ್ಪಷ್ಟ ಮಾತ್ರ. ತಮ್ಮ ಸಂಪನ್ಮೂಲಗಳ ಲಭ್ಯತೆಯನ್ನು ಸುಧಾರಿಸಲು ಏಜೆಂಟ್‌ಗಳ ಕ್ರಮಗಳನ್ನು ಯಾರಾದರೂ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವಂತೆ, ಯಾರಾದರೂ ಇದನ್ನು ಇತರ ಉದ್ದೇಶಗಳಿಗಾಗಿ ಮಾಡಬಹುದು ಮತ್ತು ಇದಕ್ಕೆ ಯಾವುದೇ ಅಡೆತಡೆಗಳಿಲ್ಲ. ಫಲಿತಾಂಶವು ದ್ವಿಮುಖ ಮತ್ತು ಬಹುಮುಖಿ ಸಾಧನವಾಗಿದೆ, ಯಾರಾದರೂ ಇದನ್ನು ನೋಡಬಹುದು.

ಮೂಲ: www.habr.com