ਆਓ ਏਜੰਟਾਂ ਨੂੰ "ਇੰਸਪੈਕਟਰ" ਗਿਣੀਏ

ਇਹ ਕੋਈ ਰਹੱਸ ਨਹੀਂ ਹੈ ਕਿ ਰੂਸ ਵਿੱਚ ਪਾਬੰਦੀਸ਼ੁਦਾ ਜਾਣਕਾਰੀ ਦੀ ਸੂਚੀ ਵਿੱਚ ਬਲੌਕ ਕਰਨ ਦੇ ਨਿਯੰਤਰਣ ਦੀ ਨਿਗਰਾਨੀ ਸਵੈਚਾਲਿਤ ਸਿਸਟਮ "ਇੰਸਪੈਕਟਰ" ਦੁਆਰਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ. ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਇਸ ਵਿੱਚ ਇੱਥੇ ਚੰਗੀ ਤਰ੍ਹਾਂ ਲਿਖਿਆ ਗਿਆ ਹੈ Habr 'ਤੇ ਲੇਖ, ਉਸੇ ਥਾਂ ਤੋਂ ਤਸਵੀਰ:

ਪ੍ਰਦਾਤਾ 'ਤੇ ਸਿੱਧਾ ਇੰਸਟਾਲ ਕੀਤਾ ਮੋਡੀਊਲ "ਏਜੰਟ ਇੰਸਪੈਕਟਰ":

"ਏਜੰਟ ਇੰਸਪੈਕਟਰ" ਮੋਡੀਊਲ ਆਟੋਮੇਟਿਡ ਸਿਸਟਮ "ਇੰਸਪੈਕਟਰ" (AS "ਇੰਸਪੈਕਟਰ") ਦਾ ਇੱਕ ਢਾਂਚਾਗਤ ਤੱਤ ਹੈ। ਇਹ ਸਿਸਟਮ 15.1 ਜੁਲਾਈ, 15.4 ਦੇ ਸੰਘੀ ਕਾਨੂੰਨ ਨੰਬਰ 27-FZ “ਜਾਣਕਾਰੀ, ਸੂਚਨਾ ਤਕਨਾਲੋਜੀ ਅਤੇ ਸੂਚਨਾ ਸੁਰੱਖਿਆ 'ਤੇ ਧਾਰਾ 2006-149 ਦੁਆਰਾ ਸਥਾਪਿਤ ਪ੍ਰਬੰਧਾਂ ਦੇ ਢਾਂਚੇ ਦੇ ਅੰਦਰ ਪਹੁੰਚ ਪਾਬੰਦੀ ਲੋੜਾਂ ਵਾਲੇ ਟੈਲੀਕਾਮ ਓਪਰੇਟਰਾਂ ਦੁਆਰਾ ਪਾਲਣਾ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ। "

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 ਐਡਰੈੱਸ ਜਾਂ ਡੋਮੇਨ ਨਾਮ ਦੁਆਰਾ ਬਲੌਕ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਅਸੀਂ ਕੋਈ ਬੇਨਤੀਆਂ ਨਹੀਂ ਦੇਖਾਂਗੇ। ਇਹ ਬਲਾਕਿੰਗ ਦੀਆਂ ਸਭ ਤੋਂ ਵਿਨਾਸ਼ਕਾਰੀ ਕਿਸਮਾਂ ਹਨ, ਜੋ ਇੱਕ IP ਪਤੇ ਜਾਂ ਇੱਕ ਡੋਮੇਨ 'ਤੇ ਸਾਰੀ ਜਾਣਕਾਰੀ 'ਤੇ ਸਾਰੇ ਸਰੋਤਾਂ ਦੀ ਪਹੁੰਚਯੋਗਤਾ ਵੱਲ ਅਗਵਾਈ ਕਰਦੀਆਂ ਹਨ। ਬਲਾਕਿੰਗ ਦੀ ਇੱਕ "ਯੂਆਰਐਲ ਦੁਆਰਾ" ਕਿਸਮ ਵੀ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਫਿਲਟਰਿੰਗ ਸਿਸਟਮ ਨੂੰ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ HTTP ਬੇਨਤੀ ਸਿਰਲੇਖ ਨੂੰ ਪਾਰਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਬਲੌਕ ਕਰਨਾ ਹੈ। ਅਤੇ ਇਸ ਤੋਂ ਪਹਿਲਾਂ, ਜਿਵੇਂ ਕਿ ਉੱਪਰ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਇੱਕ ਕਨੈਕਸ਼ਨ ਸਥਾਪਨਾ ਪੜਾਅ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਟਰੈਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹੋ, ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਫਿਲਟਰ ਇਸ ਨੂੰ ਗੁਆ ਦੇਵੇਗਾ।

ਅਜਿਹਾ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਫਿਲਟਰਿੰਗ ਸਿਸਟਮ ਦੇ ਕੰਮ ਦੀ ਸਹੂਲਤ ਲਈ "URL" ਅਤੇ HTTP ਬਲੌਕਿੰਗ ਕਿਸਮ ਦੇ ਨਾਲ ਇੱਕ ਢੁਕਵਾਂ ਮੁਫਤ ਡੋਮੇਨ ਚੁਣਨ ਦੀ ਲੋੜ ਹੈ, ਤਰਜੀਹੀ ਤੌਰ 'ਤੇ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਛੱਡਿਆ ਗਿਆ, ਏਜੰਟਾਂ ਨੂੰ ਛੱਡ ਕੇ ਬਾਹਰੀ ਆਵਾਜਾਈ ਦੇ ਦਾਖਲੇ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਕਰਨ ਲਈ। ਇਹ ਕੰਮ ਬਿਲਕੁਲ ਵੀ ਮੁਸ਼ਕਲ ਨਹੀਂ ਹੋਇਆ; ਵਰਜਿਤ ਜਾਣਕਾਰੀ ਦੇ ਰਜਿਸਟਰ ਵਿੱਚ ਅਤੇ ਹਰ ਸਵਾਦ ਲਈ ਬਹੁਤ ਸਾਰੇ ਮੁਫਤ ਡੋਮੇਨ ਹਨ. ਇਸ ਲਈ, ਡੋਮੇਨ ਨੂੰ ਖਰੀਦਿਆ ਗਿਆ ਸੀ ਅਤੇ ਇੱਕ VPS ਚੱਲ ਰਹੇ IP ਪਤਿਆਂ ਨਾਲ ਲਿੰਕ ਕੀਤਾ ਗਿਆ ਸੀ tcpdump ਅਤੇ ਗਿਣਤੀ ਸ਼ੁਰੂ ਹੋ ਗਈ।

"ਆਡੀਟਰਾਂ" ਦਾ ਆਡਿਟ

ਮੈਨੂੰ ਬੇਨਤੀਆਂ ਦੇ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਬਰਸਟ ਦੇਖਣ ਦੀ ਉਮੀਦ ਸੀ, ਜੋ ਮੇਰੀ ਰਾਏ ਵਿੱਚ ਨਿਯੰਤਰਿਤ ਕਾਰਵਾਈ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ। ਇਹ ਕਹਿਣਾ ਅਸੰਭਵ ਹੈ ਕਿ ਮੈਂ ਇਸਨੂੰ ਬਿਲਕੁਲ ਨਹੀਂ ਦੇਖਿਆ, ਪਰ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਕੋਈ ਸਪੱਸ਼ਟ ਤਸਵੀਰ ਨਹੀਂ ਸੀ:

ਜੋ ਕਿ ਹੈਰਾਨੀ ਦੀ ਗੱਲ ਨਹੀਂ ਹੈ, ਇੱਥੋਂ ਤੱਕ ਕਿ ਇੱਕ ਡੋਮੇਨ 'ਤੇ ਵੀ ਜਿਸਦੀ ਕਿਸੇ ਨੂੰ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ ਅਤੇ ਕਦੇ ਨਾ ਵਰਤੇ ਗਏ IP 'ਤੇ, ਇੱਥੇ ਬਹੁਤ ਸਾਰੀ ਅਣਚਾਹੀ ਜਾਣਕਾਰੀ ਹੋਵੇਗੀ, ਜਿਵੇਂ ਕਿ ਆਧੁਨਿਕ ਇੰਟਰਨੈਟ। ਪਰ ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਮੈਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਖਾਸ URL ਲਈ ਬੇਨਤੀਆਂ ਦੀ ਲੋੜ ਸੀ, ਇਸ ਲਈ ਸਾਰੇ ਸਕੈਨਰ ਅਤੇ ਪਾਸਵਰਡ ਕਰੈਕਰ ਜਲਦੀ ਲੱਭੇ ਗਏ ਸਨ. ਨਾਲ ਹੀ, ਇਹ ਸਮਝਣਾ ਕਾਫ਼ੀ ਆਸਾਨ ਸੀ ਕਿ ਸਮਾਨ ਬੇਨਤੀਆਂ ਦੇ ਪੁੰਜ ਦੇ ਆਧਾਰ 'ਤੇ ਹੜ੍ਹ ਕਿੱਥੇ ਸੀ। ਅੱਗੇ, ਮੈਂ IP ਐਡਰੈੱਸ ਦੀ ਮੌਜੂਦਗੀ ਦੀ ਬਾਰੰਬਾਰਤਾ ਨੂੰ ਕੰਪਾਇਲ ਕੀਤਾ ਅਤੇ ਮੈਨੂਅਲ ਤੌਰ 'ਤੇ ਪੂਰੇ ਸਿਖਰ 'ਤੇ ਗਿਆ, ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖ ਕੀਤਾ ਜੋ ਪਿਛਲੇ ਪੜਾਵਾਂ 'ਤੇ ਇਸ ਨੂੰ ਗੁਆ ਚੁੱਕੇ ਹਨ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਮੈਂ ਉਹਨਾਂ ਸਾਰੇ ਸਰੋਤਾਂ ਨੂੰ ਕੱਟ ਦਿੱਤਾ ਜੋ ਇੱਕ ਪੈਕੇਜ ਵਿੱਚ ਭੇਜੇ ਗਏ ਸਨ, ਉਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੇ ਨਹੀਂ ਸਨ। ਅਤੇ ਇਹ ਉਹ ਹੈ ਜੋ ਹੋਇਆ:

ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਗੀਤਕਾਰੀ ਵਿਭਿੰਨਤਾ। ਇੱਕ ਦਿਨ ਤੋਂ ਥੋੜ੍ਹੀ ਦੇਰ ਬਾਅਦ, ਮੇਰੇ ਹੋਸਟਿੰਗ ਪ੍ਰਦਾਤਾ ਨੇ ਇੱਕ ਸੁਚਾਰੂ ਸਮੱਗਰੀ ਦੇ ਨਾਲ ਇੱਕ ਪੱਤਰ ਭੇਜਿਆ, ਜਿਸ ਵਿੱਚ ਕਿਹਾ ਗਿਆ ਹੈ ਕਿ ਤੁਹਾਡੀਆਂ ਸਹੂਲਤਾਂ ਵਿੱਚ RKN ਪਾਬੰਦੀਸ਼ੁਦਾ ਸੂਚੀ ਵਿੱਚੋਂ ਇੱਕ ਸਰੋਤ ਹੈ, ਇਸਲਈ ਇਸਨੂੰ ਬਲੌਕ ਕੀਤਾ ਗਿਆ ਹੈ। ਪਹਿਲਾਂ ਮੈਂ ਸੋਚਿਆ ਕਿ ਮੇਰਾ ਖਾਤਾ ਬਲੌਕ ਹੋ ਗਿਆ ਹੈ, ਅਜਿਹਾ ਨਹੀਂ ਸੀ। ਫਿਰ ਮੈਂ ਸੋਚਿਆ ਕਿ ਉਹ ਮੈਨੂੰ ਉਸ ਚੀਜ਼ ਬਾਰੇ ਚੇਤਾਵਨੀ ਦੇ ਰਹੇ ਸਨ ਜਿਸ ਬਾਰੇ ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦਾ ਸੀ। ਪਰ ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਹੋਸਟਰ ਨੇ ਮੇਰੇ ਡੋਮੇਨ ਦੇ ਸਾਹਮਣੇ ਆਪਣਾ ਫਿਲਟਰ ਚਾਲੂ ਕਰ ਦਿੱਤਾ ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ ਮੈਂ ਡਬਲ ਫਿਲਟਰਿੰਗ ਦੇ ਅਧੀਨ ਆਇਆ: ਪ੍ਰਦਾਤਾਵਾਂ ਤੋਂ ਅਤੇ ਹੋਸਟਰ ਤੋਂ. ਫਿਲਟਰ ਨੇ ਸਿਰਫ ਬੇਨਤੀਆਂ ਦੇ ਅੰਤ ਨੂੰ ਪਾਸ ਕੀਤਾ: FIN-ACK и RST ਇੱਕ ਵਰਜਿਤ URL 'ਤੇ ਸਾਰੇ HTTP ਨੂੰ ਕੱਟਣਾ। ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਉਪਰੋਕਤ ਗ੍ਰਾਫ ਤੋਂ ਦੇਖ ਸਕਦੇ ਹੋ, ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਬਾਅਦ ਮੈਂ ਘੱਟ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ, ਪਰ ਮੈਨੂੰ ਅਜੇ ਵੀ ਇਹ ਪ੍ਰਾਪਤ ਹੋਇਆ, ਜੋ ਕਿ ਬੇਨਤੀ ਸਰੋਤਾਂ ਦੀ ਗਿਣਤੀ ਕਰਨ ਦੇ ਕੰਮ ਲਈ ਕਾਫ਼ੀ ਸੀ.

ਬਿੰਦੂ 'ਤੇ ਪ੍ਰਾਪਤ ਕਰੋ. ਮੇਰੀ ਰਾਏ ਵਿੱਚ, ਹਰ ਰੋਜ਼ ਦੋ ਬਰਸਟ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ, ਪਹਿਲਾ ਛੋਟਾ, ਅੱਧੀ ਰਾਤ ਦੇ ਮਾਸਕੋ ਸਮੇਂ ਤੋਂ ਬਾਅਦ, ਦੂਜਾ ਦੁਪਹਿਰ 6 ਵਜੇ ਤੱਕ ਪੂਛ ਦੇ ਨਾਲ ਸਵੇਰੇ 12 ਵਜੇ ਦੇ ਨੇੜੇ. ਸਿਖਰ ਬਿਲਕੁਲ ਉਸੇ ਸਮੇਂ ਨਹੀਂ ਵਾਪਰਦਾ. ਪਹਿਲਾਂ, ਮੈਂ ਉਹਨਾਂ IP ਪਤਿਆਂ ਨੂੰ ਚੁਣਨਾ ਚਾਹੁੰਦਾ ਸੀ ਜੋ ਸਿਰਫ ਇਹਨਾਂ ਪੀਰੀਅਡਾਂ ਵਿੱਚ ਅਤੇ ਹਰੇਕ ਪੀਰੀਅਡ ਵਿੱਚ ਆਉਂਦੇ ਹਨ, ਇਸ ਧਾਰਨਾ ਦੇ ਅਧਾਰ ਤੇ ਕਿ ਏਜੰਟਾਂ ਦੁਆਰਾ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਜਾਂਚਾਂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਪਰ ਧਿਆਨ ਨਾਲ ਸਮੀਖਿਆ ਕਰਨ 'ਤੇ, ਮੈਂ ਤੇਜ਼ੀ ਨਾਲ ਖੋਜ ਕੀਤੀ ਕਿ ਪੀਰੀਅਡ ਹੋਰ ਅੰਤਰਾਲਾਂ ਵਿੱਚ ਆਉਂਦੇ ਹਨ, ਹੋਰ ਬਾਰੰਬਾਰਤਾਵਾਂ ਦੇ ਨਾਲ, ਹਰ ਘੰਟੇ ਇੱਕ ਬੇਨਤੀ ਤੱਕ. ਫਿਰ ਮੈਂ ਟਾਈਮ ਜ਼ੋਨਾਂ ਬਾਰੇ ਸੋਚਿਆ ਅਤੇ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਇਸਦਾ ਉਹਨਾਂ ਨਾਲ ਕੋਈ ਲੈਣਾ-ਦੇਣਾ ਸੀ, ਫਿਰ ਮੈਂ ਸੋਚਿਆ ਕਿ ਆਮ ਤੌਰ 'ਤੇ ਸਿਸਟਮ ਨੂੰ ਵਿਸ਼ਵ ਪੱਧਰ 'ਤੇ ਸਮਕਾਲੀ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ. ਇਸ ਤੋਂ ਇਲਾਵਾ, NAT ਸ਼ਾਇਦ ਇੱਕ ਭੂਮਿਕਾ ਨਿਭਾਏਗਾ ਅਤੇ ਉਹੀ ਏਜੰਟ ਵੱਖ-ਵੱਖ ਜਨਤਕ IPs ਤੋਂ ਬੇਨਤੀਆਂ ਕਰ ਸਕਦਾ ਹੈ।

ਕਿਉਂਕਿ ਮੇਰਾ ਸ਼ੁਰੂਆਤੀ ਟੀਚਾ ਬਿਲਕੁਲ ਨਹੀਂ ਸੀ, ਮੈਂ ਉਨ੍ਹਾਂ ਸਾਰੇ ਪਤਿਆਂ ਦੀ ਗਿਣਤੀ ਕੀਤੀ ਜੋ ਮੈਂ ਇੱਕ ਹਫ਼ਤੇ ਵਿੱਚ ਪ੍ਰਾਪਤ ਕੀਤੇ ਅਤੇ ਪ੍ਰਾਪਤ ਕੀਤੇ - 2791. ਇੱਕ ਪਤੇ ਤੋਂ ਸਥਾਪਤ TCP ਸੈਸ਼ਨਾਂ ਦੀ ਸੰਖਿਆ ਔਸਤਨ 4 ਹੈ, ਜਿਸਦਾ ਮੱਧਮਾਨ 2 ਹੈ। ਪ੍ਰਤੀ ਪਤੇ ਦੇ ਸਿਖਰ ਸੈਸ਼ਨ: 464, 231, 149, 83, 77। ਨਮੂਨੇ ਦੇ 95% ਵਿੱਚੋਂ ਅਧਿਕਤਮ 8 ਸੈਸ਼ਨ ਪ੍ਰਤੀ ਪਤਾ ਹੈ। ਮੱਧਮਾਨ ਬਹੁਤ ਉੱਚਾ ਨਹੀਂ ਹੈ, ਮੈਨੂੰ ਤੁਹਾਨੂੰ ਯਾਦ ਦਿਵਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਗ੍ਰਾਫ ਇੱਕ ਸਪਸ਼ਟ ਰੋਜ਼ਾਨਾ ਮਿਆਦ ਦਿਖਾਉਂਦਾ ਹੈ, ਇਸਲਈ ਕੋਈ 4 ਦਿਨਾਂ ਵਿੱਚ 8 ਤੋਂ 7 ਦੇ ਆਸਪਾਸ ਕੁਝ ਦੀ ਉਮੀਦ ਕਰ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਅਸੀਂ ਇੱਕ ਵਾਰ ਹੋਣ ਵਾਲੇ ਸਾਰੇ ਸੈਸ਼ਨਾਂ ਨੂੰ ਬਾਹਰ ਕੱਢਦੇ ਹਾਂ, ਤਾਂ ਸਾਨੂੰ 5 ਦੇ ਬਰਾਬਰ ਇੱਕ ਮੱਧਮਾਨ ਮਿਲੇਗਾ। ਪਰ ਮੈਂ ਇੱਕ ਸਪੱਸ਼ਟ ਮਾਪਦੰਡ ਦੇ ਆਧਾਰ 'ਤੇ ਉਹਨਾਂ ਨੂੰ ਬਾਹਰ ਨਹੀਂ ਕਰ ਸਕਦਾ ਸੀ। ਇਸਦੇ ਉਲਟ, ਇੱਕ ਬੇਤਰਤੀਬ ਜਾਂਚ ਨੇ ਦਿਖਾਇਆ ਕਿ ਉਹ ਇੱਕ ਵਰਜਿਤ ਸਰੋਤ ਲਈ ਬੇਨਤੀਆਂ ਨਾਲ ਸਬੰਧਤ ਸਨ।

ਪਤੇ ਪਤੇ ਹੁੰਦੇ ਹਨ, ਪਰ ਇੰਟਰਨੈਟ ਤੇ, ਖੁਦਮੁਖਤਿਆਰੀ ਪ੍ਰਣਾਲੀਆਂ - ਏ.ਐਸ., ਜੋ ਕਿ ਵਧੇਰੇ ਮਹੱਤਵਪੂਰਨ ਸਾਬਤ ਹੋਈਆਂ 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 ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਕੁਦਰਤੀ ਹੈ। ਕੁਝ ਹਿੱਸਾ ਬਿਨਾਂ ਸ਼ੱਕ ਬੇਲੋੜਾ ਹੈ, ਪਰ ਇਸਨੂੰ ਵੱਖ ਕਰਨਾ ਭਰੋਸੇਯੋਗ ਤੌਰ 'ਤੇ ਮੁਸ਼ਕਲ ਹੈ, ਕਿਉਂਕਿ ਸਰੋਤ ਬਲਾਕਿੰਗ ਦੇ ਅਧੀਨ ਹੈ, ਅਤੇ ਦੂਜੇ ਦਿਨ ਤੋਂ ਡਬਲ ਬਲਾਕਿੰਗ ਦੇ ਅਧੀਨ ਹੈ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਸੈਸ਼ਨ ਸਿਰਫ ਕਈ ਸਰਵਿਸ ਪੈਕੇਟਾਂ ਦਾ ਵਟਾਂਦਰਾ ਹਨ। ਆਓ ਮੰਨੀਏ ਕਿ ਇਹ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਹਿੱਸਾ ਹੈ।

ਇਹਨਾਂ ਨੰਬਰਾਂ ਦੀ ਤੁਲਨਾ ਪਹਿਲਾਂ ਹੀ ਰੂਸ ਵਿੱਚ ਪ੍ਰਦਾਤਾਵਾਂ ਦੀ ਗਿਣਤੀ ਨਾਲ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ. ਆਰਕੇਐਨ ਦੇ ਅਨੁਸਾਰ "ਡਾਟਾ ਸੰਚਾਰ ਲਈ ਸੰਚਾਰ ਸੇਵਾਵਾਂ, ਵੌਇਸ ਨੂੰ ਛੱਡ ਕੇ" ਲਈ ਲਾਇਸੰਸ - 6387, ਪਰ ਇਹ ਉਪਰੋਕਤ ਤੋਂ ਬਹੁਤ ਉੱਚਾ ਅਨੁਮਾਨ ਹੈ, ਇਹ ਸਾਰੇ ਲਾਇਸੰਸ ਖਾਸ ਤੌਰ 'ਤੇ ਇੰਟਰਨੈਟ ਪ੍ਰਦਾਤਾਵਾਂ 'ਤੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੇ ਜਿਨ੍ਹਾਂ ਨੂੰ ਏਜੰਟ ਸਥਾਪਤ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। RIPE NCC ਜ਼ੋਨ ਵਿੱਚ ਰੂਸ ਵਿੱਚ ਰਜਿਸਟਰਡ ASs ਦੀ ਇੱਕ ਸਮਾਨ ਸੰਖਿਆ ਹੈ - 6230, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਾਰੇ ਪ੍ਰਦਾਤਾ ਨਹੀਂ ਹਨ। ਯੂਜ਼ਰਸਾਈਡ ਨੇ ਵਧੇਰੇ ਸਖਤ ਗਣਨਾ ਕੀਤੀ ਅਤੇ 3940 ਵਿੱਚ 2017 ਕੰਪਨੀਆਂ ਪ੍ਰਾਪਤ ਕੀਤੀਆਂ, ਅਤੇ ਇਹ ਉਪਰੋਕਤ ਤੋਂ ਇੱਕ ਅਨੁਮਾਨ ਹੈ। ਕਿਸੇ ਵੀ ਹਾਲਤ ਵਿੱਚ, ਸਾਡੇ ਕੋਲ ਪ੍ਰਕਾਸ਼ਿਤ AS ਦੀ ਗਿਣਤੀ ਢਾਈ ਗੁਣਾ ਘੱਟ ਹੈ। ਪਰ ਇੱਥੇ ਇਹ ਸਮਝਣ ਯੋਗ ਹੈ ਕਿ AS ਪ੍ਰਦਾਤਾ ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਹੈ. ਕੁਝ ਪ੍ਰਦਾਤਾਵਾਂ ਦਾ ਆਪਣਾ 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 ਨੂੰ ਹੋਸਟਰ ਦੁਆਰਾ ਫਿਲਟਰ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ। ਬੇਸ਼ੱਕ, ਇਸ ਨੇ ਇਕੱਠੀ ਕੀਤੀ ਸਮੱਗਰੀ ਦੀ ਗੁਣਵੱਤਾ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ, ਪਰ ਇਸਨੇ ਅਜੇ ਵੀ ਬਾਰੰਬਾਰਤਾ ਨੂੰ ਦੇਖਣਾ ਸੰਭਵ ਬਣਾਇਆ. ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਸਰੋਤਾਂ ਨੂੰ ਰੱਖਣ ਲਈ ਇੱਕ ਸਾਈਟ ਦੀ ਚੋਣ ਕਰਦੇ ਸਮੇਂ ਇਹ ਇੱਕ ਮਹੱਤਵਪੂਰਣ ਨੁਕਤਾ ਹੈ; ਮਨਾਹੀ ਵਾਲੀਆਂ ਸਾਈਟਾਂ ਅਤੇ ਆਰਕੇਐਨ ਦੀਆਂ ਬੇਨਤੀਆਂ ਦੀ ਸੂਚੀ ਦੇ ਨਾਲ ਕੰਮ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨ ਦੇ ਮੁੱਦੇ ਵਿੱਚ ਦਿਲਚਸਪੀ ਲੈਣਾ ਨਾ ਭੁੱਲੋ.

ਸ਼ੁਰੂ ਵਿੱਚ, ਮੈਂ AS "ਇੰਸਪੈਕਟਰ" ਨਾਲ ਤੁਲਨਾ ਕੀਤੀ RIPE ਐਟਲਸ. ਇਹ ਤੁਲਨਾ ਕਾਫ਼ੀ ਜਾਇਜ਼ ਹੈ ਅਤੇ ਏਜੰਟਾਂ ਦਾ ਇੱਕ ਵੱਡਾ ਨੈਟਵਰਕ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਦੇਸ਼ ਦੇ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਪ੍ਰਦਾਤਾਵਾਂ ਤੋਂ ਸਰੋਤਾਂ ਦੀ ਉਪਲਬਧਤਾ ਦੀ ਗੁਣਵੱਤਾ ਦਾ ਨਿਰਧਾਰਨ ਕਰਨਾ। ਤੁਸੀਂ ਦੇਰੀ ਦੀ ਗਣਨਾ ਕਰ ਸਕਦੇ ਹੋ, ਤੁਸੀਂ ਗ੍ਰਾਫ ਬਣਾ ਸਕਦੇ ਹੋ, ਤੁਸੀਂ ਇਸ ਸਭ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਸਥਾਨਕ ਅਤੇ ਵਿਸ਼ਵ ਪੱਧਰ 'ਤੇ ਹੋਣ ਵਾਲੀਆਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹੋ। ਇਹ ਸਭ ਤੋਂ ਸਿੱਧਾ ਤਰੀਕਾ ਨਹੀਂ ਹੈ, ਪਰ ਖਗੋਲ ਵਿਗਿਆਨੀ "ਸਟੈਂਡਰਡ ਮੋਮਬੱਤੀਆਂ" ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਏਜੰਟਾਂ ਦੀ ਵਰਤੋਂ ਕਿਉਂ ਨਹੀਂ ਕਰਦੇ? ਉਹਨਾਂ ਦੇ ਮਿਆਰੀ ਵਿਵਹਾਰ ਨੂੰ ਜਾਣ ਕੇ (ਲੱਭਣ ਤੋਂ ਬਾਅਦ), ਤੁਸੀਂ ਉਹਨਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਹੋਣ ਵਾਲੀਆਂ ਤਬਦੀਲੀਆਂ ਅਤੇ ਪ੍ਰਦਾਨ ਕੀਤੀਆਂ ਸੇਵਾਵਾਂ ਦੀ ਗੁਣਵੱਤਾ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ, ਇਹ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦੇ ਹੋ। ਅਤੇ ਉਸੇ ਸਮੇਂ, ਤੁਹਾਨੂੰ ਨੈੱਟਵਰਕ 'ਤੇ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਪੜਤਾਲਾਂ ਰੱਖਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ; Roskomnadzor ਨੇ ਉਹਨਾਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਸਥਾਪਿਤ ਕੀਤਾ ਹੈ।

ਇਕ ਹੋਰ ਨੁਕਤਾ ਜਿਸ 'ਤੇ ਮੈਂ ਛੂਹਣਾ ਚਾਹੁੰਦਾ ਹਾਂ ਉਹ ਹੈ ਕਿ ਹਰ ਸੰਦ ਇਕ ਹਥਿਆਰ ਹੋ ਸਕਦਾ ਹੈ. AS "ਇੰਸਪੈਕਟਰ" ਇੱਕ ਬੰਦ ਨੈੱਟਵਰਕ ਹੈ, ਪਰ ਏਜੰਟ ਵਰਜਿਤ ਸੂਚੀ ਵਿੱਚੋਂ ਸਾਰੇ ਸਰੋਤਾਂ ਲਈ ਬੇਨਤੀਆਂ ਭੇਜ ਕੇ ਹਰ ਕਿਸੇ ਨੂੰ ਸੌਂਪ ਦਿੰਦੇ ਹਨ। ਅਜਿਹੇ ਸਰੋਤ ਹੋਣ ਨਾਲ ਕੋਈ ਵੀ ਸਮੱਸਿਆ ਪੇਸ਼ ਨਹੀਂ ਹੁੰਦੀ। ਕੁੱਲ ਮਿਲਾ ਕੇ, ਏਜੰਟਾਂ ਦੁਆਰਾ ਪ੍ਰਦਾਤਾ, ਅਣਜਾਣੇ ਵਿੱਚ, ਉਹਨਾਂ ਦੇ ਨੈਟਵਰਕ ਬਾਰੇ ਬਹੁਤ ਕੁਝ ਦੱਸਦੇ ਹਨ ਜਿੰਨਾ ਕਿ ਸ਼ਾਇਦ ਇਸਦੀ ਕੀਮਤ ਹੈ: DPI ਅਤੇ DNS ਕਿਸਮਾਂ, ਏਜੰਟ ਦੀ ਸਥਿਤੀ (ਕੇਂਦਰੀ ਨੋਡ ਅਤੇ ਸੇਵਾ ਨੈਟਵਰਕ?), ਦੇਰੀ ਅਤੇ ਨੁਕਸਾਨ ਦੇ ਨੈਟਵਰਕ ਮਾਰਕਰ - ਅਤੇ ਇਹ ਹੈ ਸਿਰਫ ਸਭ ਤੋਂ ਸਪੱਸ਼ਟ. ਜਿਵੇਂ ਕੋਈ ਵਿਅਕਤੀ ਆਪਣੇ ਸਰੋਤਾਂ ਦੀ ਉਪਲਬਧਤਾ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਏਜੰਟਾਂ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰ ਸਕਦਾ ਹੈ, ਕੋਈ ਹੋਰ ਉਦੇਸ਼ਾਂ ਲਈ ਅਜਿਹਾ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਇਸ ਵਿੱਚ ਕੋਈ ਰੁਕਾਵਟ ਨਹੀਂ ਹੈ। ਨਤੀਜਾ ਇੱਕ ਦੋ-ਧਾਰੀ ਅਤੇ ਬਹੁਤ ਹੀ ਬਹੁਪੱਖੀ ਸਾਧਨ ਹੈ, ਕੋਈ ਵੀ ਇਸਨੂੰ ਦੇਖ ਸਕਦਾ ਹੈ.

ਸਰੋਤ: www.habr.com