Целта на защитната стена да дефинирана от администратора потребителя да ограничи трафика в мрежата, така че всяка защитна стена правило определя конкретен тип мрежа за пакети, които ще бъдат изпратени по мрежата. Това е възможно да се посочат редица причини, но това е излиза извън обхвата на тази статия. Въпреки това, даваме подробности за трудната ситуация, в която бях направил, и аз се надявам, че и други ще намерят това описание нещо полезно. Надявам се, че този скрипт и различните начини, по които да използват функционалността на защитната стена, ще послужат като пример, от което читателят ще бъде в състояние да доведат до решаване на собствените си нужди.
предупреждение:
При конфигуриране на защитната стена има определено ниво на риск. Ти случайно да определите правила за защитни стени, които ще направят предавателя недостъпна, както и защитна стена, от своя страна, изисква да отидете на този предавател, а дори и да се наложи да рестартирате просто да се възстанови достъпа до него. Винаги се уверете, че каквото и да ти предложи защитна стена преди да го прилагат на практика. Вземете предпазни мерки: не забравяйте да създадете резервно копие на конфигурацията, преди да промените защитна стена и да бъдат подготвени за най-лошото.
За улесняване на използването на стандартни документи на защитната стена е доста прости и дават ясна представа за работата си. Web-базиран интерфейс за конфигуриране на защитната стена е доста лесно. А някои сложност, са описани по-долу.
Фърмуерът v5.6.2 AirMax (Бен)
Важни подробности за защитната стена пропуснато в AirOS Документи
AirOS защитна стена за документи не се покаже, че следва да бъдат уточнени части «МАСКА» CIDR, например 192.168.1.0/24 (в контраст с пунктирана четириядрени 192.168.1.0/255.255.255.0. Използван по-ранни версии AirOS.) При източника или предназначението се отнася до хост (не на мрежа), вие трябва да изберете правилната маска CIDR който е равен на хост / 32. Ако направите грешка, интерфейсът ще отчита стойността, но това няма да има ефект, трафикът няма да бъде блокиран.
Има ли примери, когато прилагат прости настройки? Ако няма създадени мрежи, модифицирани, поддържана, отговорът е "малко", винаги има смес от подмрежи, всяка с различни връзки и изисквания за сигурност. Ето един пример на мрежата (всъщност съществуваща):
описание Пример мрежа
DOCSIS 2.0 кабелен модем (8 Мб / с получават 2 Mb / и изход) рутер свързва към Интернет. Един от Интернет порта (кабел) се свързва Bullet2HP (AP WDS / режим рутер) към LAN / интранет (и по този начин до Интернет чрез NAT.) Друг Bullet2HP (WDS / мост станция) 3 мили, е свързан чрез безжична мрежа на първия - двупосочна връзка "далечни разстояния" връзка чрез транспортна мрежа. Интернет предавател порт в режим мост свързва друга Bullet2 (режим AP / рутер) и се свързва безжично към третия Bullet2. има няколко други CPE предаватели с различни начини. (Вж. Фигура).
Преди да се опише как и къде да се прилага по-горе изисквания, важно е да се отбележи, че е налице следният феномен: може би ще се срещна документи или доклади, че работата на защитната стена е невъзможно да предаватели, работещи в режим на мост. Въпреки, че е присъствал в по-ранните версии на AirOS. Аз не съм сигурен какво е сега. правилата на защитната стена може да се използва в режим на мост, който да предотврати изпращането на трафик през нея, тя ще бъде използвана само на трафика, който минава през моста (това означава, че трафикът ще преминава само това, което е предназначено за една и съща подмрежа).
Изискване # 2
Това изискване се отнася до гара / WDS мост над защитна стена правило:
Това правило блокове трафик от всеки гостоприемник, различна от AP рутер мрежа 192.168.4.1 192.168.4.0/24, по този начин предотвратяване на проникване на мрежата 192.168.5.0/24 (който определя 192.168.4.10 като шлюз).
Изискване # 3
Това изискване се прилага към рутера чрез правилото за точка за достъп защитна стена:
Това правило не позволява предаването на ICMP трафика към конкретна рутер (който трябва да има статичен IP) към хоста в мрежата. Маршрутизаторът изпраща ICMP домакин пренасочи към други хостове, защото погрешно смята, че те са по-близо до Интернет от своята врата. Тези фалшиви рамки са досадни и разрушителни към други домакини; Това правило прави тези рамки премахнати. Това правило може да е била изпълнена на абоната, CPE, но остави домакините в мрежата не може да пинг точката за достъп / маршрутизатора (може изведнъж да се изисква по всяко време за отстраняване на проблеми).
Изискване # 4
Това изискване може да се установи само в един свързан CPE. Блокове ARP трафик между домакини свързани точка рутер достъп. ARP предаване наблюдаван в рамките на абонатните мрежи са почти безполезни в най-добрия и разрушителен в най-лошия случай теоретично:
Това правило предотвратява предаването от безжичен рутер ARP точката за достъп от пресечната точка с СРЕ моста. Това не засяга AR P трафик между Силите на абонатната мрежа, това се отразява само на трафика, който преминава по моста.
Имайте предвид, че това изискване може да се приложи, принуждавайки използването на режима на рутера CPE. Налагане на прекомерни NAT слой е прекалено, така че CPE мостовете са разрешени, стига предаване ARP случва зад тях, се съхраняват там.
Освен това, няма нищо, за да ви предпази от именуване на права, които ще направят предавателя недостъпна. Един път, когато случайно намерена правило в AP / WDS рутер с 192.168.4.0/24 идентифицирани като източник и дестинация! Това е довело до невъзможност за комуникация с предавателя чрез своя IP 192.168.4.1 (и забраните връзката между него и станцията / WDS мост.) Грешката би ми струва едно пътуване до предавателя, но за щастие успях да се свържа с него през друг IP 192.168.1.10.
