"Байцаагч" агентуудыг тоолъё.

ОХУ-д хориглосон мэдээллийн жагсаалтад хориг тавих хяналтыг "Байцаагч" автоматжуулсан системээр хянадаг нь нууц биш юм. Энэ нь хэрхэн ажилладаг талаар энд маш сайн бичсэн байдаг Хабрын тухай нийтлэл, ижил газраас авсан зураг:

"Байцаагч" агентуудыг тоолъё.

Үйлчилгээ үзүүлэгч дээр шууд суулгасан "Агент байцаагч" модуль:

"Агент байцаагч" модуль нь "Байцаагч" (AS "Байцаагч") автоматжуулсан системийн бүтцийн элемент юм. Энэхүү систем нь 15.1 оны 15.4-р сарын 27-ны өдрийн 2006-ФЗ "Мэдээлэл, мэдээллийн технологи, мэдээллийг хамгаалах тухай" Холбооны хуулийн 149-XNUMX-т заасан заалтуудын хүрээнд харилцаа холбооны операторуудын хандалтын хязгаарлалтын шаардлагыг дагаж мөрдөхөд хяналт тавих зорилготой юм. ”

"Revizor" AS-ийг бий болгох гол зорилго нь 15.1 оны 15.4-р сарын 27-ны өдрийн 2006-ФЗ "Мэдээлэл, мэдээллийн технологи, мэдээллийг хамгаалах тухай" Холбооны хуулийн 149-XNUMX-т заасан шаардлагыг харилцаа холбооны операторуудын дагаж мөрдөх байдалд хяналт тавих явдал юм. "Хориотой мэдээлэлд нэвтрэх баримтыг олж тогтоох, хориотой мэдээлэлд нэвтрэх эрхийг хязгаарлах зөрчлийн талаар дэмжих материал (мэдээлэл) авах.

Бүгд биш юмаа гэхэд олон үйлчилгээ үзүүлэгч энэ төхөөрөмжийг суулгасан гэдгийг харгалзан үзвэл ийм дохионы мэдрэгч бүхий том сүлжээ байх ёстой байсан. 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 хаяг дээрх бүх нөөц эсвэл домэйн дээрх бүх мэдээллийг ашиглах боломжгүй болоход хүргэдэг блоклох хамгийн хор хөнөөлтэй төрлүүд юм. Мөн "URL-ээр" блоклох төрөл байдаг. Энэ тохиолдолд шүүлтүүрийн систем нь яг юуг хаахыг тодорхойлохын тулд HTTP хүсэлтийн толгой хэсгийг задлан шинжлэх ёстой. Үүнээс өмнө, дээр дурдсанчлан холболт үүсгэх үе шат байх ёстой, учир нь шүүлтүүр үүнийг алдах магадлалтай тул та хянахыг оролдож болно.

Үүнийг хийхийн тулд та "URL" болон HTTP блоклох төрөл бүхий тохиромжтой үнэгүй домэйн сонгох хэрэгтэй бөгөөд ингэснээр Агентуудаас бусад гадны урсгалыг багасгахын тулд шүүлтүүрийн системийн ажлыг хөнгөвчлөх, илүү удаан орхигдсон байх нь дээр. Энэ даалгавар нь тийм ч хэцүү биш байсан тул хориотой мэдээллийн бүртгэлд маш олон тооны үнэгүй домэйнууд байдаг. Тиймээс домэйныг худалдан авч VPS ажиллаж байгаа IP хаягуудтай холбосон tcpdump мөн тооллого эхэллээ.

"Аудитор"-ын аудит

Миний бодлоор хяналттай арга хэмжээ авахыг илтгэх хүсэлтүүд үе үе гарч ирнэ гэж би хүлээж байсан. Би үүнийг огт хараагүй гэж хэлэх боломжгүй, гэхдээ тодорхой зураг байхгүй байсан:

"Байцаагч" агентуудыг тоолъё.

Хэнд ч хэрэггүй домэйн, хэзээ ч ашиглагдаагүй IP дээр ч гэсэн орчин үеийн интернет гэх мэт олон тонн хүсээгүй мэдээлэл байх нь гайхмаар зүйл биш юм. Гэхдээ аз болоход надад зөвхөн тодорхой URL-ын хүсэлтүүд хэрэгтэй байсан тул бүх сканнерууд болон нууц үг хагалагчдыг хурдан олсон. Түүнчлэн, ижил төстэй хүсэлтийн масс дээр үндэслэсэн үер хаана байгааг ойлгоход хялбар байсан. Дараа нь би IP хаягуудын давтамжийг эмхэтгэж, өмнөх үе шатанд алдсан хүмүүсийг салгаж, дээд хэсгийг бүхэлд нь гараар дамжуулав. Нэмж дурдахад би нэг багцад илгээсэн бүх эх сурвалжийг хассан, одоо тийм ч олон биш байсан. Тэгээд ийм зүйл болсон:

"Байцаагч" агентуудыг тоолъё.

Уянгын жижиг ухралт. Хэдхэн хоногийн дараа миний хостинг үйлчилгээ үзүүлэгчээс танай байгууламжид 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, дунджаар AS тутамд 2 хаяг, медиан нь 1. AS тус бүрийн шилдэг хаягууд: 288, 77, 66, 39, 27. Түүврийн хамгийн ихдээ 95% нь AS тутамд 4 хаяг байна. Энд медиан хүлээгдэж байна - үйлчилгээ үзүүлэгч бүрт нэг агент. Бид бас дээд амжилтыг хүлээж байна - үүнд том тоглогчид байгаа. Том сүлжээнд агентууд нь операторын байгаа бүс бүрт байрлах ёстой бөгөөд NAT-ийн талаар бүү мартаарай. Хэрэв бид үүнийг улсаар нь авч үзвэл дээд тал нь: 1409 - RU, 42 - UA, 23 - CZ, RIPE NCC биш бусад бүс нутгаас 36 байх болно. ОХУ-аас гаднаас ирсэн хүсэлт хүмүүсийн анхаарлыг татдаг. Үүнийг өгөгдөл бөглөхдөө газарзүйн байршлын алдаа эсвэл бүртгэгчийн алдаагаар тайлбарлаж болох юм. Эсвэл Оросын компани орос үндэсгүй байж болно, эсвэл илүү хялбар байдаг тул гадаад төлөөлөгчийн газартай байх нь гадаадын RIPE NCC байгууллагатай харьцах нь зүйн хэрэг юм. Зарим хэсэг нь эргэлзээгүй илүүдэлтэй боловч нөөцийг блоклосон, хоёр дахь өдрөөсөө давхар блоклосон тул үүнийг салгахад найдвартай хэцүү байдаг бөгөөд ихэнх сессүүд нь зөвхөн хэд хэдэн үйлчилгээний багц солилцох явдал юм. Энэ бол багахан хэсэг гэдэгтэй санал нийлэе.

Эдгээр тоог аль хэдийн Орос дахь үйлчилгээ үзүүлэгчдийн тоотой харьцуулж болно. RKN мэдээлэв "Өгөгдөл дамжуулах үйлчилгээ, дуу хоолой оруулахгүй"-ийн лицензүүд - 6387, гэхдээ энэ нь дээрээс маш өндөр тооцоолол бөгөөд эдгээр бүх лиценз нь Агент суулгах шаардлагатай интернет үйлчилгээ үзүүлэгчдэд хамаарахгүй. RIPE NCC бүсэд Орос улсад бүртгэлтэй ижил тооны ASes байдаг - 6230 нь бүгд үйлчилгээ үзүүлэгч биш юм. UserSide илүү хатуу тооцоо хийсэн 3940 онд 2017 аж ахуйн нэгжийг хүлээн авсан нь дээрх тооцоолол юм. Ямар ч байсан бид хоёр ба хагас дахин бага гэрэлтүүлэгтэй АС-тай. Гэхдээ энд AS нь үйлчилгээ үзүүлэгчтэй хатуу тэнцүү биш гэдгийг ойлгох нь зүйтэй. Зарим үйлчилгээ үзүүлэгчид өөрийн гэсэн AS байхгүй, зарим нь нэгээс олон байдаг. Хэрэв бид хүн бүр Агенттай хэвээр байна гэж үзвэл хэн нэгэн нь бусдаас илүү хүчтэй шүүдэг бөгөөд ингэснээр тэдний хүсэлтийг хог хаягдлаас ялгах боломжгүй болно, хэрэв тэдгээр нь тэдэнд хүрэх юм бол. Гэхдээ миний хяналтаас болж ямар нэг зүйл алдагдсан ч гэсэн бүдүүлэг үнэлгээний хувьд үүнийг тэвчих боломжтой.

DPI-ийн тухай

Хэдийгээр миний хостинг үйлчилгээ үзүүлэгч хоёр дахь өдрөөс эхлэн шүүлтүүрээ асаасан ч эхний өдрийн мэдээлэлд үндэслэн блок амжилттай ажиллаж байна гэж дүгнэж болно. Зөвхөн 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-ийн хүсэлттэй ажиллах ажлыг зохион байгуулах асуудлыг сонирхож бүү мартаарай.

Эхэндээ би АС "Байцаагч"-тай харьцуулсан RIPE Атлас. Энэ харьцуулалт нь нэлээд үндэслэлтэй бөгөөд Агентуудын томоохон сүлжээ нь ашигтай байж болно. Жишээлбэл, улс орны янз бүрийн хэсэгт өөр өөр үйлчилгээ үзүүлэгчээс нөөцийн хүртээмжийн чанарыг тодорхойлох. Та саатал тооцоолж, график байгуулж, бүгдийг нь шинжилж, орон нутгийн болон дэлхийн хэмжээнд гарч буй өөрчлөлтүүдийг харж болно. Энэ бол хамгийн шууд арга биш, гэхдээ одон орон судлаачид "стандарт лаа" ашигладаг, яагаад Агентуудыг ашиглаж болохгүй гэж? Тэдний стандарт зан чанарыг мэдэж (олсон) та тэдний эргэн тойронд гарч буй өөрчлөлтүүд болон энэ нь үзүүлж буй үйлчилгээний чанарт хэрхэн нөлөөлж байгааг тодорхойлох боломжтой. Үүний зэрэгцээ та датчикуудыг сүлжээнд бие даан байрлуулах шаардлагагүй, Роскомнадзор аль хэдийн суулгасан байна.

Миний хөндөхийг хүсч буй өөр нэг зүйл бол багаж хэрэгсэл бүр зэвсэг байж болно. AS "Хянагч" нь хаалттай сүлжээ боловч агентууд хориглосон жагсаалтаас бүх нөөцийг авах хүсэлтийг илгээх замаар хүн бүрийг хүлээлгэн өгдөг. Ийм нөөцтэй байх нь ямар ч асуудал үүсгэдэггүй. Нийтдээ Агентуудаар дамжуулан үйлчилгээ үзүүлэгчид өөрсдийн сүлжээний талаар санамсаргүй байдлаар үнэ цэнэтэй зүйлээс илүү их зүйлийг хэлдэг: DPI ба DNS төрлүүд, Агентын байршил (төв зангилаа ба үйлчилгээний сүлжээ?), сүлжээний саатал, алдагдлын тэмдэглэгээ - энэ нь зөвхөн хамгийн тод. Хэн нэгэн Агентлагуудын нөөцийн хүртээмжийг сайжруулахын тулд хийж буй үйлдлийг хянаж чаддаг шиг хэн нэгэн үүнийг өөр зорилгоор хийж болох бөгөөд үүнд ямар ч саад бэрхшээл байхгүй. Үр дүн нь хоёр талдаа, маш олон талт хэрэгсэл юм, үүнийг хэн ч харж болно.

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх