"இன்ஸ்பெக்டர்" முகவர்களை எண்ணுவோம்

ரஷ்யாவில் தடைசெய்யப்பட்ட தகவல்களின் பட்டியலில் தடுக்கும் கட்டுப்பாடு "இன்ஸ்பெக்டர்" என்ற தானியங்கி அமைப்பு மூலம் கண்காணிக்கப்படுகிறது என்பது இரகசியமல்ல. இது எப்படி வேலை செய்கிறது என்பது இங்கே நன்றாக எழுதப்பட்டுள்ளது ஹப்ர் பற்றிய கட்டுரை, அதே இடத்தில் இருந்து படம்:

வழங்குநரிடம் நேரடியாக நிறுவப்பட்டது தொகுதி "ஏஜெண்ட் இன்ஸ்பெக்டர்":

"ஏஜென்ட் இன்ஸ்பெக்டர்" தொகுதி என்பது தானியங்கு அமைப்பு "இன்ஸ்பெக்டர்" (AS "இன்ஸ்பெக்டர்") இன் கட்டமைப்பு உறுப்பு ஆகும். ஜூலை 15.1, 15.4 எண். 27-FZ இன் ஃபெடரல் சட்டத்தின் 2006-149 “தகவல், தகவல் தொழில்நுட்பங்கள் மற்றும் தகவல் பாதுகாப்பு குறித்த விதிகள் XNUMX-XNUMX இல் நிறுவப்பட்ட விதிகளின் கட்டமைப்பிற்குள் அணுகல் கட்டுப்பாடு தேவைகளுடன் தொலைதொடர்பு ஆபரேட்டர்களின் இணக்கத்தை கண்காணிக்க இந்த அமைப்பு வடிவமைக்கப்பட்டுள்ளது. ”

AS "Revizor" ஐ உருவாக்குவதன் முக்கிய நோக்கம், ஜூலை 15.1, 15.4 எண். 27-FZ "தகவல், தகவல் தொழில்நுட்பங்கள் மற்றும் தகவல் பாதுகாப்பு பற்றிய ஃபெடரல் சட்டத்தின் கட்டுரைகள் 2006-149 மூலம் நிறுவப்பட்ட தேவைகளுடன் தொலைதொடர்பு ஆபரேட்டர்களின் இணக்கத்தை கண்காணிப்பதை உறுதி செய்வதாகும். "தடைசெய்யப்பட்ட தகவல்களுக்கான அணுகல் உண்மைகளை அடையாளம் காணுதல் மற்றும் தடைசெய்யப்பட்ட தகவலுக்கான அணுகலைக் கட்டுப்படுத்தும் மீறல்கள் பற்றிய துணைப் பொருட்களை (தரவு) பெறுதல் ஆகியவற்றின் அடிப்படையில்.

எல்லாமே இல்லை என்றால், பல வழங்குநர்கள் இந்த சாதனத்தை நிறுவியிருக்கிறார்கள் என்ற உண்மையை கணக்கில் எடுத்துக்கொண்டால், இது போன்ற பீக்கான் ஆய்வுகளின் பெரிய நெட்வொர்க் இருந்திருக்க வேண்டும். பழுத்த அட்லஸ் மேலும், ஆனால் மூடிய அணுகலுடன். இருப்பினும், ஒரு கலங்கரை விளக்கம் என்பது எல்லா திசைகளிலும் சமிக்ஞைகளை அனுப்பும் ஒரு கலங்கரை விளக்கமாகும், ஆனால் அவற்றைப் பிடித்து, எதைப் பிடித்தோம், எத்தனை பிடித்தோம் என்று பார்த்தால் என்ன செய்வது?

எண்ணுவதற்கு முன், இது ஏன் சாத்தியமாகும் என்று பார்ப்போம்.

ஒரு பிட் கோட்பாடு

இது போன்ற 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 மணி வரை ஒரு வால். உச்சம் சரியாக ஒரே நேரத்தில் ஏற்படாது. முதலில், இந்த காலகட்டங்களில் மட்டுமே விழும் ஐபி முகவரிகளையும், எல்லா காலகட்டங்களிலும் உள்ள ஒவ்வொன்றையும் தேர்ந்தெடுக்க விரும்பினேன், முகவர்கள் மூலம் சோதனைகள் அவ்வப்போது செய்யப்படுகின்றன என்ற அனுமானத்தின் அடிப்படையில். ஆனால் கவனமாக மதிப்பாய்வு செய்தபோது, ​​ஒவ்வொரு மணி நேரத்திற்கும் ஒரு கோரிக்கை வரை பிற அதிர்வெண்களுடன் பிற இடைவெளிகளில் வரும் காலங்களை விரைவாகக் கண்டுபிடித்தேன். பின்னர் நான் நேர மண்டலங்களைப் பற்றி யோசித்தேன், அவற்றுடன் ஏதாவது தொடர்பு இருக்கலாம் என்று நினைத்தேன், பொதுவாக இந்த அமைப்பு உலகளவில் ஒத்திசைக்கப்படாது என்று நினைத்தேன். கூடுதலாக, NAT ஒருவேளை ஒரு பாத்திரத்தை வகிக்கும் மற்றும் அதே முகவர் வெவ்வேறு பொது IP களில் இருந்து கோரிக்கைகளை செய்யலாம்.

எனது ஆரம்ப இலக்கு சரியாக இல்லாததால், ஒரு வாரத்தில் நான் கண்ட அனைத்து முகவரிகளையும் எண்ணினேன் - 2791. ஒரு முகவரியிலிருந்து நிறுவப்பட்ட TCP அமர்வுகளின் எண்ணிக்கை சராசரியாக 4 ஆகும், சராசரி 2. ஒரு முகவரிக்கு மேல் அமர்வுகள்: 464, 231, 149, 83, 77. மாதிரியின் 95% இலிருந்து ஒரு முகவரிக்கு 8 அமர்வுகள் ஆகும். சராசரியானது மிக அதிகமாக இல்லை, வரைபடமானது தெளிவான தினசரி கால இடைவெளியைக் காட்டுகிறது என்பதை நினைவூட்டுகிறேன், எனவே 4 நாட்களில் 8 முதல் 7 வரை ஏதாவது ஒன்றை எதிர்பார்க்கலாம். ஒரு முறை நிகழும் அனைத்து அமர்வுகளையும் தூக்கி எறிந்தால், 5 க்கு சமமான சராசரியைப் பெறுவோம். ஆனால் தெளிவான அளவுகோலின் அடிப்படையில் அவற்றை என்னால் விலக்க முடியவில்லை. மாறாக, அவை தடைசெய்யப்பட்ட ஆதாரத்திற்கான கோரிக்கைகளுடன் தொடர்புடையவை என்று ஒரு சீரற்ற சோதனை காட்டியது.

முகவரிகள் முகவரிகள், ஆனால் இணையத்தில், தன்னாட்சி அமைப்புகள் - AS, இது மிகவும் முக்கியமானதாக மாறியது 1510, சராசரியாக ஒரு AS க்கு 2 முகவரிகள் சராசரி 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 மண்டலத்தில் ரஷ்யாவில் இதேபோன்ற எண்ணிக்கையிலான AS கள் பதிவு செய்யப்பட்டுள்ளன - 6230, இவை அனைத்தும் வழங்குநர்கள் அல்ல. UserSide இன்னும் கண்டிப்பான கணக்கீடு செய்தது மற்றும் 3940 இல் 2017 நிறுவனங்களைப் பெற்றது, மேலும் இது மேலே இருந்து மதிப்பீடு ஆகும். எப்படியிருந்தாலும், எங்களிடம் இரண்டரை மடங்கு குறைவான ஒளிரும் ஏஎஸ்கள் உள்ளன. ஆனால் AS வழங்குநருக்கு கண்டிப்பாக சமமாக இல்லை என்பதை இங்கே புரிந்து கொள்ள வேண்டும். சில வழங்குநர்கள் தங்கள் சொந்த AS ஐக் கொண்டிருக்கவில்லை, சிலருக்கு ஒன்றுக்கு மேற்பட்டவை உள்ளன. ஒவ்வொருவருக்கும் இன்னும் முகவர்கள் இருப்பதாக நாம் கருதினால், யாரோ ஒருவர் மற்றவர்களை விட வலுவாக வடிகட்டுகிறார், அதனால் அவர்களின் கோரிக்கைகள் குப்பையிலிருந்து பிரித்தறிய முடியாதவை, அவர்கள் சென்றால். ஆனால் ஒரு தோராயமான மதிப்பீட்டிற்கு, எனது மேற்பார்வையின் காரணமாக எதையாவது இழந்தாலும், அது மிகவும் சகித்துக்கொள்ளக்கூடியது.

DPI பற்றி

எனது ஹோஸ்டிங் வழங்குநர் அதன் வடிப்பானை இரண்டாவது நாளிலிருந்து இயக்கியிருந்தாலும், முதல் நாளிலிருந்து கிடைத்த தகவலின் அடிப்படையில் தடுப்பது வெற்றிகரமாகச் செயல்படுகிறது என்று முடிவு செய்யலாம். HTTP மற்றும் TCP அமர்வுகளை (மேலே உள்ள எடுத்துக்காட்டில் உள்ளதைப் போல) 4 ஆதாரங்கள் மட்டுமே பெற முடிந்தது. மேலும் 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 "இன்ஸ்பெக்டர்" உடன் ஒப்பிட்டுப் பார்த்தேன் பழுத்த அட்லஸ். இந்த ஒப்பீடு மிகவும் நியாயமானது மற்றும் முகவர்களின் பெரிய நெட்வொர்க் நன்மை பயக்கும். எடுத்துக்காட்டாக, நாட்டின் பல்வேறு பகுதிகளில் உள்ள பல்வேறு வழங்குநர்களிடமிருந்து கிடைக்கும் வளங்களின் தரத்தை தீர்மானித்தல். நீங்கள் தாமதங்களைக் கணக்கிடலாம், வரைபடங்களை உருவாக்கலாம், அனைத்தையும் பகுப்பாய்வு செய்யலாம் மற்றும் உள்நாட்டிலும் உலக அளவிலும் ஏற்படும் மாற்றங்களைக் காணலாம். இது மிகவும் நேரடியான வழி அல்ல, ஆனால் வானியலாளர்கள் "நிலையான மெழுகுவர்த்திகளை" பயன்படுத்துகின்றனர், ஏன் முகவர்களைப் பயன்படுத்தக்கூடாது? அவர்களின் நிலையான நடத்தையை அறிந்து (கண்டுபிடித்து), அவர்களைச் சுற்றி நிகழும் மாற்றங்களை நீங்கள் தீர்மானிக்க முடியும் மற்றும் இது வழங்கப்பட்ட சேவைகளின் தரத்தை எவ்வாறு பாதிக்கிறது. அதே நேரத்தில், நீங்கள் நெட்வொர்க்கில் ஆய்வுகளை சுயாதீனமாக வைக்க தேவையில்லை; Roskomnadzor ஏற்கனவே அவற்றை நிறுவியுள்ளது.

நான் தொட விரும்பும் மற்றொரு விஷயம் என்னவென்றால், ஒவ்வொரு கருவியும் ஒரு ஆயுதமாக இருக்கலாம். AS "இன்ஸ்பெக்டர்" என்பது ஒரு மூடிய நெட்வொர்க், ஆனால் தடைசெய்யப்பட்ட பட்டியலிலிருந்து அனைத்து ஆதாரங்களுக்கான கோரிக்கைகளை அனுப்புவதன் மூலம் முகவர்கள் அனைவரையும் ஒப்படைக்கிறார்கள். அத்தகைய வளத்தை வைத்திருப்பது எந்த பிரச்சனையும் இல்லை. மொத்தத்தில், ஏஜெண்டுகள் மூலம் வழங்குபவர்கள், அறியாமலேயே, தங்களின் நெட்வொர்க்கைப் பற்றி ஒருவேளை மதிப்புள்ளதை விட அதிகமாகச் சொல்கிறார்கள்: டிபிஐ மற்றும் டிஎன்எஸ் வகைகள், ஏஜெண்டின் இருப்பிடம் (மத்திய முனை மற்றும் சேவை நெட்வொர்க்?), தாமதங்கள் மற்றும் இழப்புகளின் நெட்வொர்க் குறிப்பான்கள் - இது மிகவும் வெளிப்படையானது மட்டுமே. தங்கள் வளங்களின் கிடைக்கும் தன்மையை மேம்படுத்த முகவர்களின் செயல்களை யாரோ ஒருவர் கண்காணிப்பது போல, வேறு நோக்கங்களுக்காக யாரேனும் இதைச் செய்யலாம், இதற்கு எந்தத் தடையும் இல்லை. இதன் விளைவாக இரட்டை முனைகள் கொண்ட மற்றும் மிகவும் பன்முக கருவியாகும், இதை யார் வேண்டுமானாலும் பார்க்கலாம்.

ஆதாரம்: www.habr.com