Қонақ желіге арналған VLAN схемасы қалай жұмыс істейді

Қонақ желі мен IP-камераларды екі VLAN-ға бөліп, жұмысты аяқталды деуге болмайды. Дұрыс схемаға бөлек кеңтаратылым домендері, әдепкі тыйым саясаты бар желіаралық экран, қатынау деңгейіндегі клиенттерді оқшаулау және шекараның екі жағынан жасалатын тексерістер кіреді. Осы бөліктердің бірі болмаса, сызбадағы түрлі түсті төртбұрыштар жалған қауіпсіздік сезімін береді.

Шағын кеңсе үшін мен әдетте төрт аймақтан бастаймын: қызметкерлер құрылғылары, қонақтар, камералар және басқару. Бейнетіркегішті сервер аймағына орналастырамын немесе ауқымы мен талаптары негіздесе, жазбаға арналған бөлек VLAN бөлемін. Камераларға интернетке еркін шығу қажет емес, қонақтарға жеке мекенжайларға баратын маршруттар қажет емес, ал қарапайым жұмыс станциясы әр камераның веб-интерфейсіне тікелей кірмеуі керек.

Төмендегі схеманы кез келген өндірушінің маршрутизаторына, желіаралық экранына, басқарылатын коммутаторлары мен қатынау нүктелеріне бейімдеуге болады. VLAN нөмірлері мен ішкі желілер мысал ретінде берілген. Схеманың мәнін ағын бағыттары, нақты алушылар және ережелер реті анықтайды.

VLAN кадрларды бөледі, ал саясатты желіаралық экран белгілейді

VLAN екінші деңгейде шекара жасайды, бірақ ол шекарадан кім өте алатынын өзі шешпейді. Маршрутизаторда немесе үшінші деңгейлі коммутаторда барлық VLAN интерфейстері пайда болған сәттен бастап, ол олардың арасында трафик бағыттай алады. Қатынау тізімдері немесе желіаралық экран ережелері болмаса, қонақ серверге қызметкер сияқты оңай жете алады.

NIST SP 800-215 дәстүрлі сегменттеуді бірге қолданылатын екі тетік деп сипаттайды: талаптары ұқсас ресурстар VLAN идентификаторлары сияқты құралдармен сегменттерге бөлінеді, ал шлюздер IP-мекенжайлар мен порттар бойынша ережелерді қолданады. Бұл айырманы нақты түсіну керек. 802.1Q тегі «кадр қай сегментке жатады?» деген сұраққа жауап береді, ал желіаралық экран «осы сеансқа рұқсат бар ма?» деген сұрақты шешеді.

NAT туралы да жиі шатасады. Мекенжайларды түрлендіру бірнеше жеке түйінге бір сыртқы мекенжай арқылы шығуға көмектеседі, бірақ сүзуді алмастырмайды. NIST SP 800-41 NAT-ты желіаралық экран технологиясына емес, маршрутизацияға жатқызады. Шлюзде NAT қосылып, сегменттер арасында бағыттауға рұқсат берілсе, ішкі желілер бір-біріне әлі де қол жеткізе алады.

Саясат қосылым күйін бақылайтын сүзуді қолдануы керек. Сайттан қонақтың телефонына келген жауап телефон өзі ашқан сеанстың бөлігі ретінде өтеді. Интернеттен сол телефонға бағытталған жаңа сеанс бұғатталады. Қосылым күйін есепке алу бейнетіркегішке камерадан ағын сұрауға және жауап алуға мүмкіндік береді, бұл үшін камераларға бүкіл сервер желісіне шығатын кең рұқсат қажет емес.

Мен «бірнеше тыйымнан басқа барлық VLAN бір-біріне шыға алады» деген ережені қолданбаймын. Ол монтаж жасалған күні ғана ыңғайлы. Бір жылдан кейін жаңа ішкі желілердің қайсысы ерекшеліктер тізіміне кірмей қалғанын ешкім есіне түсірмейді. Қажетті ағындарға нақты рұқсат беріп, қалғанының бәрін журналға жазылатын тыйым ережесімен аяқтаған қауіпсіз.

Төрт аймақ адрестеуді түсінікті етеді

Күрделі филиалдық құрылымы жоқ кеңсеге мақсаты үшінші октеттен көрінетін адрестеу жоспары жеткілікті. VLAN нөмірін жұмыс орындарының санына немесе коммутатор портының нөміріне байламаңыз. Бұл мәндер өзгереді, ал сегменттің міндеті сол күйінде қалады.

• Қызметкерлер желісі: VLAN 20, ішкі желі 10.20.0.0/23, шлюз 10.20.0.1. Мұнда компьютерлер, ұйым басқаратын ноутбуктер және бөлек ережелер арқылы қолжетімді сервер қызметтері орналасады.
• Қонақтар: VLAN 40, ішкі желі 10.40.0.0/23, шлюз 10.40.0.1. Мұнда келушілердің жеке телефондары мен ноутбуктері қосылады.
• Камералар: VLAN 50, ішкі желі 10.50.0.0/24, шлюз 10.50.0.1. Мұнда IP-камералар мен бейне кодерлер орналасады.
• Басқару: VLAN 60, ішкі желі 10.60.0.0/24, шлюз 10.60.0.1. Мұнда коммутаторлар, қатынау нүктелері, контроллерлер және әкімшілендіру интерфейстері орналасады.

Бұл ауқымдар RFC 1918 құжатындағы үш жеке блоктың бірі, 10.0.0.0/8 ауқымынан алынған. Жеке мекенжайдың өзі қорғаныс бермейді: RFC 1918 адрестеуді реттейді және қауіпсіздік мәселелері құжатта қарастырылмайтынын бөлек айтады. Қорғанысты сүзгілер мен қажетсіз маршруттардың болмауы жасайды.

Қонақтарға арналған /23 ішкі желісі тым үлкен кеңтаратылым доменін құрмай, өсуге орын қалдырады, ал камераларға арналған /24 ауқымын түгендеу оңай. Дегенмен өлшемді нақты клиент санына, DHCP жалдау мерзіміне және күтілетін өсуге қарап есептеу керек. Конференция орталығында бір мезетте қосылған адам аз болса да, ескі жалдаулар босамағандықтан қонақ мекенжайларының қоры сағат сайын таусылуы мүмкін. Мұндай жағдайда ауқымды бірден /16-ға дейін кеңейткеннен гөрі жалдау мерзімін қысқарту пайдалы.

Бейнетіркегіш камералармен бір VLAN-да тұруға міндетті емес. Мен 10.20.10.15 сияқты мекенжайды серверлік ішкі желіде немесе жазбаға арналған бөлек VLAN-да ұстағанды жөн көремін. Сонда «бейнетіркегіш камераларға қосылады» ережесінде бір белгілі бастамашы болады. Тіркегіш камералар VLAN-ында тұрса, жұмыс орындары оның интерфейсіне бәрібір бөлек ереже арқылы кіреді, ал қолға түскен тіркегіш бірден барлық камерамен екінші деңгейде көрші болады.

DHCP қонақтарға тек өз шлюзін және сәйкес DNS қызметін беруі керек. Камераларға DHCP резервтеулерін тағайындаған немесе тұрақты мекенжайларды түгендеу жүйесінде тіркеген дұрыс, бірақ тізілімсіз екі әдісті араластырмаңыз. camera-12 деп белгіленген мекенжай құрылғы ауыстырылғаннан кейін басқа жабдыққа берілсе, дәл ереже кездейсоқ рұқсатқа айналады.

Қатынау порты күтпеген жерден транк болмауы керек

Желі шетінде әр порттың бір анық міндеті болады. Камера порты VLAN 50-дегі access-порт ретінде жұмыс істейді, ал қатынау нүктесіне баратын желі бүкіл ауқымды емес, тек нақты көрсетілген VLAN-дарды тасымалдайды. Қолданылмайтын порттар өшіріліп, жұмыс істемейтін VLAN-ға ауыстырылады. Қажет емес жерде транкты автоматты келісу өшіріледі.

Қатынау нүктесіне әдетте басқару VLAN-ы мен қонақ SSID-і, кейде қызметкерлер SSID-і де қажет. Тегсіз native трафик желінің екі шетінде бірдей анықталуы керек. Native VLAN сәйкессіздігі жағымсыз ақау туғызады: қатынау нүктесін басқару пайдаланушы сегментіне түсіп кетуі мүмкін, ал пакеттердің бір бөлігі жұмыс істеп тұрғандай көрінеді. Жабдық қолдаса, барлық жұмыс VLAN-ын тегтегенді және басқаруға VLAN 1-ді қолданбағанды жөн көремін.

Қонақ SSID-і тек VLAN 40-пен байланысады. «Клиенттерді оқшаулау», «peer blocking» немесе соған ұқсас баптау екі сымсыз қонақтың тікелей сөйлесуіне жол бермейді. Бір VLAN ішіндегі клиенттер арасындағы алмасуды желіаралық экран көрмейді, өйткені қатынау нүктесі немесе коммутатор кадрларды жергілікті түрде жібереді. Сондықтан GUEST -> INTERNAL тыйымы бір қонақтың жанындағы телефонды сканерлеуін тоқтатпайды.

Сымды қонақ порттары мен камераларға да осы қағида жүреді. Камералар бір-біріне хабарласпауы керек болса, қорғалған порттарды, private VLAN, порт ACL-дерін немесе бөлек шағын сегменттерді қолданыңыз. Толық оқшаулау бір камера екіншісіне оқиға жіберетін схеманы бұзуы мүмкін, сондықтан алдымен ағындарды тіркеп, шектеуді содан кейін қосады.

Жалған DHCP сервері мен ARP алмастыруынан қорғау да қатынау деңгейінде іске асады. Коммутатор қолдаса және команда байланыстарды сүйемелдей алса, DHCP snooping, Dynamic ARP Inspection және IPv6 Router Advertisement қорғанысы көмектеседі. Бұл функцияларды тексермей қосу қауіпті: сенімді uplink қате белгіленсе, тұтас қабат мекенжайсыз қалуы мүмкін. Әуелі DHCP жолын тексеріп, қорғанысты порттардың бір түріне кезекпен қолданыңыз.

Қонақтарға кеңсенің іші емес, интернет беріледі

Қонақ саясаты үш талапты орындауы керек: клиент желі параметрлерін алады, ашық ресурстарға шығады және ұйым мекенжайларына сеанс бастай алмайды. Ережелердің реті маңызды. Алдымен DHCP мен DNS-ке тағайындалған қызметтерге рұқсат беріледі, кейін ішкі ауқымдарға тыйым салынады, содан соң WAN-ға шығуға рұқсат беріледі. «Қонақтардан интернетке» деген кең ереже жеке желілерге тыйымнан жоғары тұрса, нәтиже нақты өндірушінің WAN аймағын қалай түсіндіретініне тәуелді болады.

Төмендегі мысал белгілі бір өнімнің синтаксисі емес, тексеруге болатын сипаттама. Оны конфигурациямен бірге сақтап, басқа желіаралық экранға көшкенде салыстыруға ыңғайлы.

objects:
  GUEST_NET = 10.40.0.0/23
  CAMERA_NET = 10.50.0.0/24
  NVR = 10.20.10.15
  ADMIN_NET = 10.60.10.0/24
  INTERNAL_V4 = 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
  INTERNAL_V6 = fc00::/7
  DNS = 10.20.0.53
  NTP = 10.20.0.123

policy, ordered:
  allow GUEST_NET -> gateway : DHCP
  allow GUEST_NET -> DNS : DNS
  deny  GUEST_NET -> INTERNAL_V4 : any, log
  deny  GUEST_NET -> INTERNAL_V6 : any, log
  allow GUEST_NET -> WAN_PUBLIC : any, stateful

  allow CAMERA_NET -> DNS : DNS
  allow CAMERA_NET -> NTP : NTP
  allow NVR -> CAMERA_NET : INVENTORIED_CAMERA_PORTS, stateful
  allow ADMIN_NET -> CAMERA_NET : HTTPS, SSH, stateful
  deny  CAMERA_NET -> WAN : any, log
  deny  CAMERA_NET -> INTERNAL : any, log

  deny any -> any : any, log

WAN_PUBLIC нысаны жай ғана сыртқы физикалық интерфейсті емес, ашық мекенжайларға баратын маршруттарды білдіруі керек. Қонақ VPN, екінші провайдер арнасы немесе филиал маршруты арқылы ішкі мекенжайға жете алады. RFC 1918 ауқымын бұғаттау әдеттегі жеке IPv4 желілерін жабады, бірақ ұйым ішінде ашық бағытталатын ауқым қолданылуы мүмкін. Оны да ішкі ресурстар нысанына қосыңыз. Шлюздің жергілікті қызметтері басқа ережелер тізбегінде өңделсе, оның басқару мекенжайларын бөлек бұғаттаңыз.

Қонақтарға тек TCP 80 және 443 порттарын ашу жинақы көрінеді, бірақ VPN, дауыстық қолданбалар, ойындар және диагностикалық ICMP жиі істемей қалады. Қонақ қызметі қалыпты интернетті уәде етсе, ашық мекенжайларға шығатын трафикке рұқсат беріп, теріс пайдалануды жылдамдық, сеанс саны және DNS саясаты арқылы шектеген дұрыс. Қонақтар мен ішкі желілер арасындағы сүзгі дәл әрі қатаң қалуы керек.

DNS тағы бір шекара жасайды. Сервер аттарын ашып көрсететін немесе шектеусіз рекурсивті сұраулар қабылдайтын ішкі DNS қонақтарға қажет емес. Ұйым саясатына қарай шлюздегі жеке аймақ көрінісі бар резолверді немесе ашық резолверлерді қолдануға болады. DNS сұрауларын өз қызметіңізге мәжбүрлі түрде бағыттасаңыз, сыртқы TCP және UDP 53 портына тікелей сұрауларды бұғаттаңыз. Шифрланған DNS үшін басқа саясат қажет, оны бір портпен ғана шектеу мүмкін емес.

Камера тек белгілі алушылармен сөйлесуі керек

Камераның ішкі желіге немесе интернетке еркін қосылым ашуына қызметтік себеп жоқ. Оған бейнетіркегіш, нақты уақыт көзі, кейде DNS және бақыланатын жаңарту жолы қажет. Басқа трафикке нақты модельдің құжаттамасын қарап, трафикті ұстап тексергеннен кейін ғана рұқсат беріңіз.

Бейне ағынының бағытын жиі қате түсінеді. Көп жүйеде бейнетіркегіш камераның RTSP немесе ONVIF қызметіне қосылып, ағынды өзі алады. Мұнда бастамашы камера емес, NVR болады. Басқа жүйелерде камера ағынды немесе оқиғаларды серверге өзі жібереді. Ережені таныстырылымдағы жебеге емес, байқалған сеансқа қарап құрыңыз. Қосылым күйі деректің көп бөлігін қай жақ жіберетініне қарамастан жауап пакеттерін өткізеді.

Интернеттен табылған тізімге сүйеніп, бүкіл VLAN үшін «камералардың стандартты порттарын» ашпаңыз. RTSP жиі TCP 554 портын қолданады, ONVIF қызметтері өндіруші белгілеген порттарда HTTP немесе HTTPS арқылы жұмыс істеуі мүмкін, ал медиа келісілген динамикалық UDP порттарымен берілуі ықтимал. Алдымен камераны зертханалық сегментке қосып, жазуды, тікелей көріністі, уақытты теңестіруді, оқиғалар мен жаңартуды іске қосыңыз. Шлюздегі ағындарды ұстап, «көз, алушы, хаттама, порт, міндет» түріндегі тізім жасаңыз. Тек сол тізім рұқсаттарға айналуы керек.

Камераларға интернетті толық жабу саналы шешім болуы керек. Бұлттағы мобильді қолданба, push-хабарламалар, лицензияны тексеру немесе микробағдарламаны жүктеу тоқтауы мүмкін. Бұл еркін сыртқы қатынауға себеп емес. Функция қажет пе, соны шешіп, оған делдал беріңіз: ішкі NTP, ішкі DNS, жергілікті жаңарту сервері немесе қызмет көрсету уақытына ашылатын уақытша ереже. Өндіруші үнемі өзгеретін бұлт мекенжайларына тұрақты қосылым талап етсе, тәуекел мен пайдалану шығынын сатып алу шешіміне қосыңыз.

Интернеттен камераға немесе бейнетіркегішке порт бағыттауды қате деп санаймын. Қашықтан көру үшін пайдаланушы есептік жазбалары мен қатынау журналы бар басқарылатын VPN қолданыңыз немесе архитектурада қарастырылса, қорғалған жариялау шлюзін таңдаңыз. Сыртқы портты ауыстыру ашық веб-интерфейсті қауіпсіз етпейді.

Оқшаулау құрылғының негізгі қауіпсіздігін алмастырмайды. Әр камераға бірегей құпиясөз, қажетсіз қызметтерді өшіру, өзекті микробағдарлама және дұрыс уақыт қажет. Сегменттеу залал аумағын азайтады, бірақ ортақ құпиясөзі бар камера онымен заңды түрде сөйлесе алатын кез келген түйін үшін оңай нысана болып қала береді.

Құрылғыны табу шекарадан тек арнайы шешіммен өтеді

Камераларды автоматты іздеу әдетте VLAN арасынан өтпейді, бұл сегменттеудің қалыпты салдары. ONVIF Core Client Test Specification құжаты WS-Discovery жұмысын сипаттайды: клиент 239.255.255.250 multicast мекенжайы мен UDP 3702 портына Probe жібереді, содан кейін құрылғы клиентке тікелей жауап береді. Маршрутизатор әдетте мұндай жергілікті multicast трафигін басқа сегментке өткізбейді.

Бұл жұмыс станциялары мен камераларды бір желіге біріктіру керек деген сөз емес. Алғашқы баптау үшін әкімші станциясын камералар VLAN-ына уақытша қосып, мекенжайлар мен тіркелгі деректерін орнатыңыз, кейін белгілі IP-мекенжайларды дәл ереже арқылы басқарыңыз. Екінші нұсқа ретінде нақты VLAN-дар арасында тек керекті хаттаманы тасымалдайтын іздеу проксиін немесе reflector қолдануға болады. Мұндай қызмет қатынау аумағын кеңейтеді, сондықтан оны қонақ желіге бағыттамаңыз.

mDNS те ұқсас жұмыс істейді. RFC 6762 IPv4 үшін link-local multicast 224.0.0.251 мекенжайы мен UDP 5353 портын, ал IPv6 үшін FF02::FB мекенжайын белгілейді. Принтер немесе экран қызметкерлер желісінен табылуы керек болса, қызметкерлер сегменттері арасында тек қажетті қызмет түрлерін көрсетіңіз. Бір құрылғының ыңғайы үшін қонақтар, басқару және камералар арасында жалпы mDNS-reflector қоспаңыз.

Қолданба «камераны тек бір VLAN ішінде көреді» деген жағдай маршрутизация ақауын дәлелдемейді. Оның белгілі unicast мекенжайын ашуға тырысатынын немесе тек жергілікті іздеуге сүйенетінін тексеріңіз. Бірінші жағдайда ереже мен маршрутты түзетеді, екінші жағдайда іске қосу тәртібін өзгертеді немесе тар ауқымды прокси қосады.

IPv6 мен басқару айналып өтетін жолдарды жабады

Тек IPv4 үшін жасалған саясат қатынау нүктелері, клиенттер және шлюз IPv6 қолданып тұрған кезде екінші желі жолын ашық қалдырады. Құрылғы Router Advertisement арқылы ғаламдық IPv6-мекенжай алып, IPv4 NAT-сыз интернетке шыға алады. 10.0.0.0/8 ауқымына жасалған сынақ тыйымды дұрыс көрсетсе де, қонақ ішкі ғаламдық немесе ULA мекенжайына қол жеткізуі мүмкін.

Екі нұсқаның бірін таңдаңыз. IPv6-ны әр VLAN үшін жаңа кіріс сеанстарына қойылатын дәл сол шекаралармен, журналдармен және тыйымдармен толық баптаңыз немесе команда оны әлі бақылай алмайтын сегменттерде IPv6 мен RA таратуды өшіріңіз. IPv6 «қолданылмай тұрған сияқты» болатын жартылай шешім әдетте оны ешкім бақыламайтынын білдіреді.

RFC 4193 fc00::/7 ауқымын ғаламдық маршрутизацияда қолданылмайтын, бірақ бір нысан ішінде бағытталатын бірегей жергілікті IPv6 мекенжайлар кеңістігі деп анықтайды. Сондықтан қонақтарға арналған тыйымдағы ішкі желілер нысанына ULA ауқымын қосыңыз. Link-local fe80::/10 қалыпты маршрутизатордан өтпейді, бірақ сол VLAN ішіндегі көршілерге қолжетімді болып қалады. Клиенттерді оқшаулау IPv6-ны да қамтуы керек.

Басқару жазықтығы пайдаланушы трафигінен бөлек болуы керек. Коммутаторлардың, қатынау нүктелерінің, желіаралық экрандардың және камералардың веб-интерфейстеріне тек әкімшілік ішкі желіден немесе jump host арқылы кіреді. Қонақ SSID-інде және қызметкерлердің қарапайым порттарында басқаруға тыйым салыңыз. Жабдық HTTPS пен SSH қолдаса, ескі HTTP мен Telnet-ті өшіріп, SNMP қатынауын мониторинг жүйесінің мекенжайларымен шектеңіз.

Әкімші күнделікті пошта ашатын және кездейсоқ файлдарды іске қосатын ноутбуктен қосылса, бөлек басқару желісінің пайдасы аз. Шағын кеңседе VPN немесе jump host-қа екі факторлы қатынауы бар арнайы әкімшілік түйін жарайды. Үлкен нысанға рөлдерге бөлінген есептік жазбалар, командалар журналы және негізгі желіден тыс резервтік қатынау қажет. Бұл шаралар VLAN кестесін өзгертпейді, бірақ оның ережелерін кім өзгерте алатынын анықтайды.

Тексеру рұқсатты да, тыйымды да дәлелдеуі керек

Схема қонақ желісінен, камералар VLAN-ынан, әкімшілік желіден және сыртқы нүктеден сынақ өткеннен кейін ғана дайын саналады. Тек әкімшінің ноутбугінен жасалған тексеріс әкімшінің бәрін көретінін дәлелдейді. Ол қонақтың не көретіні туралы ештеңе айтпайды.

Сынаққа дейін конфигурацияны сақтап, ережелер есептегіштерін тазалаңыз немесе бастапқы мәнін жазып алыңыз, содан кейін сынақ клиентінің мекенжайын белгілеңіз. Төмендегі ретті орындаңыз. Командалар Linux үшін берілген; басқа жүйеде сол мекенжайлар мен хаттамаларды тексеретін баламаларды қолданыңыз.

1. Қонақ SSID-іне қосылып, мекенжай, маршрут және DNS VLAN 40-қа жататынын растаңыз.
2. Ашық сайт пен DNS жұмысын тексеріңіз. Содан кейін шлюздерді, серверді, бейнетіркегішті және бірнеше басқару мекенжайын ашып көріңіз.
3. Сынақ камерасын VLAN 50-ге қосыңыз. Жазбаны, уақыт пен оқиғаларды тексеріп, қандай сыртқы әрекеттер тыйым ережесіне түскенін қараңыз.
4. Әкімшілік түйіннен рұқсат етілген камера интерфейсін ашыңыз. Қарапайым жұмыс станциясынан сұрауды қайталап, оның өтпейтініне көз жеткізіңіз.
5. Сыртқы желіден арнайы бекітілген VPN-шлюзден басқа камера немесе NVR порттары жарияланбағанын тексеріңіз.

$ ip -br address
wlan0    UP    10.40.0.27/23

$ ip route
default via 10.40.0.1 dev wlan0
10.40.0.0/23 dev wlan0 proto kernel scope link src 10.40.0.27

$ dig @10.40.0.1 example.net +short
203.0.113.20

$ curl -I -m 5 https://example.net
HTTP/2 200

$ nc -vz -w 3 10.20.10.15 443
nc: connect to 10.20.10.15 port 443 (tcp) timed out

$ nmap -Pn -p 22,80,443,445,3389 10.20.0.10
PORT     STATE    SERVICE
22/tcp   filtered ssh
80/tcp   filtered http
443/tcp  filtered https
445/tcp  filtered microsoft-ds
3389/tcp filtered ms-wbt-server

Мысалдағы 203.0.113.20 мекенжайы TEST-NET-3 ауқымына жатады және нақты сайтты емес, нәтиже пішінін ғана көрсетеді. Нақты сынаққа рұқсат етілген сыртқы ресурсты қолданыңыз. filtered күйі сканер жауап алмағанын және сүзу бар деп болжағанын білдіреді. Ол пакетті нақты қай құрылғы тастағанын дәлелдемейді. Әрекетті тиісті deny ережесі есептегішінің өсуімен және 10.40.0.27 мекенжайы бойынша журнал жазбасымен салыстырыңыз.

Күту уақытының аяқталуы ішкі топологияны жасыруға көмектеседі, бірақ ақауды анықтауды қиындатады. Сезімтал ақпаратты ашпайтын жерде ICMP administrative prohibited жауабына рұқсат беріп, нәтижені журналдан тексеремін. Шығыстағы нақты сөзден гөрі төрт дәлелдің сәйкес келуі маңызды: клиент дұрыс VLAN алды, рұқсат етілген ағын өтті, тыйым салынған ағын өтпеді, күтілген ереженің есептегіші өзгерді.

IPv6-ны ip -6 address, ip -6 route командаларымен және белгілі ішкі IPv6-мекенжайына қосылу арқылы бөлек тексеріңіз. Көрші қонақты да тексеріңіз, өйткені бұл трафик шлюзге жетпеуі мүмкін. Соңында камера мен қатынау нүктесін қайта іске қосыңыз: кейбір қателер жаңа DHCP сеансынан немесе портты қайта келісуден кейін ғана көрінеді.

Келісілген уақыт аралығы болмаса, өндірістік желіде кең сканерлеу жүргізбеңіз. Қабылдау үшін алдын ала таңдалған аз ғана мекенжай мен порт жеткілікті. Сынақтың мақсаты ескі камераларға жүктеме түсіру емес, шекараны дәлелдеу.

Әр ереженің иесі барда схема қауіпсіз қалады

Сегменттеу ескіргеннен емес, мерзімі көрсетілмеген уақытша рұқсаттардан бұзылады. Монтаждаушы камераларға интернетті «екі сағатқа» ашуды сұрайды, қолданба бүкіл қызметкерлер VLAN-ынан қатынауды талап етеді, ал жаңа ереже тыйымдардың үстіне қосылады. Алты айдан кейін уақытша жазба жүйенің қалыпты бөлігі саналады.

Әр рұқсаттың иесі, мақсаты, көзі, алушысы, қызметі және қайта қарау күні болуы керек. Ережелер экспорты, мекенжайлар тізілімі, порттар картасы және конфигурацияның сақтық көшірмесі бірге сақталады. Камера, бейнетіркегіш, қатынау нүктесі немесе желіаралық экран ауысқаннан кейін тек суреттің шығуын емес, тыйым салынған ағындарды да қайта тексеріңіз.

Іске қосқаннан кейін тыйым журналдарын қарап отыру керек. Камераның белгісіз сыртқы мекенжайға қайталанатын қосылымдары бұлт функциясын, қате DNS-ті, жаңартуды тексеруді немесе құрылғының қолға түсуін білдіруі мүмкін. Мекенжайды бірден рұқсат тізіміне қоспаңыз. Алдымен оны құжаттамамен және ұсталған трафикпен салыстырып, функцияның қажет екенін шешіңіз.

Нысанды жобалағанда GSE серверлік және желілік инфрақұрылымды пайдалану мен қолдау талаптарымен байланыстырып, схеманы бір өндірушіге байламай құра алады. Жақсы жиналған жабдықтың өзі allow any ережесін түзетпейді: ағындардың қабылдау матрицасы жоба тапсырыс берушіге өткеннен кейін де сақталуы керек.

Схемадан өндірушілердің барлық атауын алып тастағанда да мағынасы анық оқылуы тиіс: қонақтар тек ашық ресурстарға шығады, бейнетіркегіш белгілі камералардан бейне алады, әкімшілер құрылғыларды бөлек аймақтан басқарады, ал сипатталмаған кез келген ағын бұғатталады. Мұндай схеманы бүгін тексеруге және екі жылдан кейін болжамсыз қалпына келтіруге болады.