
- •Список vlan
- •План подключения оборудования по портам
- •Схемы сети
- •Порты доступа (access)
- •Транковые порты (trunk)
- •Сеть управления
- •Виды acl
- •Входящий и исходящий трафик
- •Практика
- •А) Доступ на web-сервер
- •Б)Доступ на файловый сервер
- •В) Доступ на почтовый сервер
- •Е) Права пользователей из сети Other
- •Ё) Сеть управления
- •Ж) Более никаких ограничений
- •Маска и обратная маска
- •Типы nat Статический
- •Динамический
- •Перенаправление портов
- •Слабости и силости nat
- •Практика nat
- •1) Сеть управления
- •2) Хосты из сети пто
- •3)Бухгалтерия
- •6) Филиалы в Санкт-Петербурге и Кемерово
- •7) Cервера
- •Б) Файловый сервер
- •В) Почтовый сервер
- •8) Доступ по rdp к компьютерам админа и нашему
- •Безопасность
- •Физика и логика процесса межвланной маршрутизации
- •Планирование расширения
- •Настройка
- •Москва. Арбат
- •Провайдер
- •Санкт-Петербург. Васильевский остров
- •Санкт-Петербург. Озерки
- •Кемерово. Красная горка
- •Дополнительно
- •Широковещательный шторм
- •Состояния портов
- •Виды stp
- •Агрегация каналов
- •Практика
Е) Права пользователей из сети Other
До сих пор нам нужно было не впускать кого-то куда-то, поэтому мы обращали внимание на адрес назначения и список доступа вешали на исходящий с интерфейса трафик. Теперь нам нужно не выпускать: никакие запросы от компьютеров из сети Other не должны выходить за пределы. Ну, конечно, кроме тех, которые мы специально разрешим.
msk-arbat-gw1(config)# ip access-list extended Other-in msk-arbat-gw1(config-ext-nacl)# remark IAM msk-arbat-gw1(config-ext-nacl)# permit ip host 172.16.6.61 any msk-arbat-gw1(config-ext-nacl)# remark ADMIN msk-arbat-gw1(config-ext-nacl)# permit ip host 172.16.6.66 any
Тут мы не могли сначала запретить всем, а потом разрешить избранным, потому что абсолютно все пакеты попадали бы под правило deny ip any any и permit не срабатывал бы вообще. Применяем на интерфейс. На этот раз на вход:
msk-arbat-gw1(config)#int fa0/0.104 msk-arbat-gw1(config-subif)#ip access-group Other-in in
то есть все IP-пакеты от хоста с адресом 172.16.6.61 или 172.16.6.66 разрешено передавать куда бы они ни были предназначены. Почему мы тут используем тоже расширенный список доступа? Ведь, казалось бы, мы проверяем только адрес отправителя. Потому что админу мы дали полный доступ, а вот гостю компании “Лифт ми Ап”, например, который попадёт в эту же сеть совсем ни к чему доступ куда-либо, кроме как в Интернет.
Ё) Сеть управления
Ничего сложного. Правило будет выглядеть так:
msk-arbat-gw1(config)# ip access-list extended Management-out msk-arbat-gw1(config-ext-nacl)# remark IAM msk-arbat-gw1(config-ext-nacl)# permit ip host 172.16.6.61 172.16.1.0 0.0.0.255 msk-arbat-gw1(config-ext-nacl)# remark ADMIN msk-arbat-gw1(config-ext-nacl)# permit ip host 172.16.6.66 172.16.1.0 0.0.0.255
Данный ACL применяем на out на интерфейс FE 0/0.2:
msk-arbat-gw1(config)# int fa0/0.2 msk-arbat-gw1(config-subif)#ip access-group Management-out out
Ж) Более никаких ограничений
Готово
Маска и обратная маска
До сих пор мы без объяснения давали странный параметр вида 0.0.255.255, подозрительно напоминающий маску подсети. Немного сложная для понимания, но именно она — обратная маска — используется для определения хостов, которые подпадут под правило. Чтобы понять что такое обратная маска, вы должны знать, что такое обычная. Начнём с самого простого примера. Обычная сеть на 256 адресов: 172.16.5.0/24, например. Что означает эта запись? А означает она ровно следующее
IP-адрес. Десятичная запись |
172 |
16 |
5 |
0 |
IP-адрес. Двоичная запись |
10101100 |
00010000 |
00000101 |
00000000 |
Маска подсети. Двоичная запись |
11111111 |
11111111 |
11111111 |
00000000 |
Маска подсети. Десятичная запись |
255 |
255 |
255 |
0 |
IP-адрес — это параметр длиною 32 бита, поделенный на 4 части, который вы привыкли видеть в десятичной форме. Маска подсети также имеет длину 32 бита — она фактически шаблон, трафарет, по которому определяется принадлежность адреса подсети. Там, где в маске стоят единицы, значение меняться не может, то есть часть 172.16.5 совершенно неизменна и она будет одинакова для всех хостов этой подсети, а вот та, где нули — варьируется. То есть во взятом нами примере 172.16.5.0/24 — это адрес сети, а хосты будут 172.16.5.1-172.16.5.254 (последний 255 — широковещательный), потому что 00000001 — это 1, а 11111110 — 254 (речь о последнем октете адреса). /24 означает, что длина маски 24 бита, то есть у нас идёт 24 единицы — неизменная часть и 8 нулей. Другой случай, когда маска у нас, например, 30 бит, а не 24. К примеру 172.16.2.4/30. Распишем это так:
IP-адрес. Десятичная запись |
172 |
16 |
2 |
4 |
IP-адрес. Двоичная запись |
10101100 |
00010000 |
00000010 |
00000100 |
Маска подсети. Двоичная запись |
11111111 |
11111111 |
11111111 |
11111100 |
Маска подсети. Десятичная запись |
255 |
255 |
255 |
252 |
Как видите, для этой подсети могут меняться только последние два бита. Последний октет может принимать следующие 4 значения: 00000100 — адрес подсети (4 в десятичной системе) 00000101 — адрес узла (5) 00000110 — адрес узла (6) 00000111 — широковещательный (7) Всё, что за пределами этого — уже другая подсеть То есть теперь вам должно быть чуть-чуть понятно, что маска подсети — это последовательность 32-х бит, где сначала идут единицы, означающие адрес подсети, потом идут нули, означающие адрес хоста. При этом чередоваться нули и единицы в маске не могут чередоваться. То есть маска 11111111.11100000.11110111.00000000 невозможна А что же такое обратная маска (wildcard)? Для подавляющего большинства админов и некоторых инженеров — это не более, чем инверсия обычной маски. То есть нули вначале задают адрес части, которая должна совпадать обязательно, а единицы наоборот свободную часть. То есть на взятом нами первом примере, если вы хотите отфильтровать все хосты из подсети 172.16.5.0/24, то вы зададите правило в Access-листе: …. 172.16.5.0 0.0.0.255 Потому что обратная маска будет выглядеть так: 00000000.00000000.00000000.11111111 Во втором примере с сетью 172.16.2.4/30 обратная маска будет выглядеть так: 30 нулей и две единицы:
Обратная маска. Двоичная запись |
00000000 |
00000000 |
00000000 |
00000011 |
Обратная маска. Десятичная запись |
0 |
0 |
0 |
3 |
Соответственно параметр в access-листе будет выглядеть так: …. 172.16.2.4 0.0.0.3 Позже, когда вы съедите собаку на просчётах масок и обратных масок, вы запомните самые употребляемые цифры, количество хостов в той или иной маске, поймёте, что в описанных ситуациях последний октет обратной маски получается вычитанием из 255 цифры последнего октета обычной маски (255-252=3) и т.д. А пока нужно много трудиться и считать) Но на самом деле обратная маска — это несколько более богатый инструмент, здесь вы можете объединять адреса внутри одной подсети или даже объединять подсети, но самое главное отличие, вы можете чередовать нули и единицы. Это позволяет вам, например, отфильтровать определённый узел (или группу) в нескольких подсетях одной строкой.
Пример 1
Дано: сеть 172.16.16.0/24 Надо: отфильтровать первые 64 адреса (172.16.16.0-172.16.16.63) Решение: 172.16.16.0 0.0.0.63
Пример 2
Дано: сети 172.16.16.0/24 и 172.16.17.0/24 Надо: отфильтровать адреса из обеих сетей Решение: 172.16.16.0 0.0.1.255
Пример 3
Дано: Сети 172.16.0.0-172.16.255.0 Надо: отфильтровать хост с адресом 4 из всех подсетей Решение: 172.16.16.0 0.0.255.4 Признаться ни разу в жизни не приходилось встречаться с последним сценарием применения. Это какие-то жутко специфические должны быть задачи. Более подробно об обратных масках можно прочитать тут: http://habrahabr.ru/post/131712/
Работа ACL в картинках
Гипотетическая
сеть:
1)
На маршрутизаторе RT1 на интерфейсе FE0/1
на вход у нас разрешено всё, кроме ICMP.
2)
На маршрутизаторе RT2 на интерфейсе FE0/1
на выход запрещены SSH и
TELNET
Тесты
кликабельны
1)
Пинг с компьютера ПК1 на Сервер1
2)
TELNET с компьютера ПК1 на Сервер1
3)
SSH с компьютера ПК1 на Сервер2
4)
Пинг с Сервера2 на ПК1
Дополнения
1) Правила, действующие на исходящий трафик (out) не будут фильтровать трафик самого устройства. То есть, если нужно запретить самой циске доступ куда-либо, то вам придётся на этом интерфейсе фильтровать входящий трафик (ответный оттуда, куда надо запретить доступ). 2) C ACL надо быть аккуратнее. При небольшой ошибке в правиле, неправильном порядке настройки или вообще плохо продуманном списке вы можете остаться без доступа к устройству. Например, вы хотите закрыть доступ куда угодно для сети 172.16.6.0/24, кроме своего адреса 172.16.6.61 и задаёте правила так:
deny ip 172.16.6.0 0.0.0.255 any permit ip host 172.16.6.61 any
Как только вы примените ACL на интерфейс, вы сразу потеряете доступ к маршрутизатору, потому что вы попадаете под первое правило и второе даже не проверяется. Вторая неприятная ситуация, которая может с вами приключиться: под ACL попадёт трафик, который не должен был попасть. Вообразите такую ситуацию: у нас в серверной есть FTP-сервер в пассивном режиме. Для доступа к нему вы открыли 21-й порт в ACL Servers-out. После первичного установления соединения FTP-сервер сообщает клиенту порт, по которому он готов передавать/принимать файлы, например, 1523-й. Клиент пытается установить TCP-соединение на этот порт, но натыкается на ACL Servers-out, где такого разрешения нету — так и кончается сказка про успешный трансфер. В нашем примере выше, где мы настраивали доступ на файловый сервер, мы открыли доступ только по 20 и 21-му, потому что для примера этого достаточно. В реальной жизни придётся повозиться. Немного примеров конфигурации ACL для распространенных случаев. 3) Из 2-го пункта вытекает очень похожая и интересная проблема. Вздумалось вам, например повесить на интерфейс в интернет такие вот ACL:
access-list out permit tcp host 1.1.1.1 host 2.2.2.2 eq 80 access-list in permit tcp host 2.2.2.2 any eq 80
Казалось бы: хосту с адресом 1.1.1.1 разрешён доступ по 80-му порту на сервер 2.2.2.2 (первое правило). И обратно от сервера 2.2.2.2 разрешены соединения внутрь. Но нюанс тут в том, что компьютер 1.1.1.1 устанавливает соединение НА 80-й порт, но С какого-то другого, например, 1054, то есть ответный пакет от сервера приходит на сокет 1.1.1.1:1054, не подпадает под правило в ACL на IN и отбрасывается ввиду неявного deny ip any any. Чтобы избежать такой ситуации, и не открывать всем пучком порты, можно прибегнуть к такой хитрости в ACL на in:
permit tcp host 2.2.2.2 any established.
Подробности такого решения в одной из следующих статей. 4) Говоря про современный мир, нельзя обойти такой инструмент, как объектные группы (Object-group). Допустим, надо составить ACL, выпускающий три определенных адреса в интернет по трем одинаковым портам c перспективой расширения количества адресов и портов. Как это выглядит без знания объектных групп:
ip access-list extended TO-INTERNET permit tcp host 172.16.6.66 any eq 80 permit tcp host 172.16.6.66 any eq 8080 permit tcp host 172.16.6.66 any eq 443 permit tcp host 172.16.6.67 any eq 80 permit tcp host 172.16.6.67 any eq 8080 permit tcp host 172.16.6.67 any eq 443 permit tcp host 172.16.6.68 any eq 80 permit tcp host 172.16.6.68 any eq 8080 permit tcp host 172.16.6.68 any eq 443
При увеличении количества параметров сопровождать такой ACL становится всё труднее и труднее, легко ошибиться при настройке. Зато, если обратиться к объектным группам, то это приобретает следующий вид:
object-group service INET-PORTS description Ports allowed for some hosts tcp eq www tcp eq 8080 tcp eq 443 object-group network HOSTS-TO-INET description Hosts allowed to browse the net host 172.16.6.66 host 172.16.6.67 host 172.16.6.68 ip access-list extended INET-OUT permit object-group INET-PORTS object-group HOSTS-TO-INET any
на первый взгляд несколько угрожающе выглядит, но если разобраться, то это очень удобно. 4) Очень полезную для траблшутинга информацию можно получить из вывода команды show ip access-lists %имя ACL%. Кроме собственно списка правил указанного ACL, эта команда показывает количество совпадений по каждому правилу.
msk-arbat-gw1#sh ip access-lists nat-inet Extended IP access list nat-inet permit tcp 172.16.3.0 0.0.0.255 host 192.0.2.2 eq www permit ip 172.16.5.0 0.0.0.255 host 192.0.2.3 permit ip 172.16.5.0 0.0.0.255 host 192.0.2.4 permit ip host 172.16.4.123 any permit ip host 172.16.6.61 any permit ip host 172.16.6.66 any (4 match(es)) permit ip host 172.16.16.222 any permit ip host 172.16.17.222 any permit ip host 172.16.24.222 any
А дописав в конце любого правила log, мы сможем получать сообщения о каждом совпадении в консоль. (последнее не работает в PT)
NAT
Network Address Translation — механизм в хозяйстве совершенно необходимый уже с 1994-го года. Много сессий об него сломано и пакетов потеряно. Нужен он чаще всего для подключения вашей локальной сети к Интернету. Дело в том, что теоретически существует 255*255*255*255=4 228 250 625. 4 миллиарда адресов. Даже если бы у каждого жителя планеты был всего один компьютер, адресов бы уже не хватало. А тут разве что утюги к Интернету не подключаются. Умные люди сообразили это ещё в начале 90-х и как временное решение предложили разделить пространство адресов на публичные (белые) и приватные (частные, серые). К последним относятся три диапазона: 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 Их вы свободно можете использовать в своей частной сети, и поэтому, разумеется, они будут повторяться. Как же быть с уникальностью? Кому будет отвечать WEB-сервер, которому пришёл запрос с обратным адресом 192.168.1.1? Ростелекому? Компании Татнефть? Или вашему комнатному Длинку? В большом интернете никто ничего не знает о приватных сетях — они не маршрутизируются. Тут и выходит на сцену NAT. По большому счёту, это обман, подстава. На натирующем устройстве ваш приватный адрес, грубо говоря, просто подменяется на белый адрес, который и будет фигурировать далее в пакете, пока он путешествует до WEB-сервера. А вот белые адреса очень даже хорошо маршрутизируются, и пакет точно вернётся обратно на натирующее устройство. Но как оно в свою очередь поймёт, что с ним делать дальше? Вот с этим и разберёмся.