Планирование топологии вашей сети

Для различных форматов сети могут быть приведены свои аргументы за и против. Однако запросы большинства организаций могут быть удовлетворены установкой рабочих станций и серверов для внутреннего пользования в частную замаскированную подсеть, а серверов общего пользования - на корректные внешние IP адреса. Машины на корректных внешних IP адресах в этом документе будут называться "незащищенными хостами". Все вышесказанное приводит к следующей топологии (пример):

+--------------+ | | +---------------+ | Шлюз |---------------| Сервер FTP | | ISP | | +---------------+ | | | +--------------+ | +---------------+ |------| Сервер WWW #1 | | +---------------+ | | +---------------+ |------| Сервер WWW #2 | | +---------------+ | ~ ~ | | +---------------+ |------| Шлюз в | | частную | | сеть | +---------------+ | | | | +--------------------+ | +----------------------+ | Рабочая станция #1 |-----------|-------------| Внутренний сервер #1 | +--------------------+ | +----------------------+ | . -----------|------------- . . | . . -----------|------------- . | +--------------------+ | +----------------------+ | Рабочая станция #N |-----------|-------------| Внутренний сервер #N | +--------------------+ +----------------------+

В этом примере шлюз ISP (Internet Service Provider (поставщик услуг Интернет)), сервер FTP, сервера WWW и "шлюз в частную сеть" имеют видимые снаружи IP адреса, а рабочие станции и внутренние сервера - IP адреса, выделенные в соответствие с RFC 1918 (зарезервированные для использования во внутренних сетях). IP адреса в вашей внутренней подсети (все, что ниже шлюза в частную сеть) должны быть уникальными не только для вашей подсети, но и для подобных подсетей ваших партнеров, с которыми вы, возможно, планируете в будущем организовать виртуальную частную сеть (virtual private network). Этому правилу стоит следовать во избежание путаницы и необходимости перенастройки сети в будущем. В соответствие с RFC, вы можете выбрать любую подсеть класса C из диапазона 192.168.0.* - 192.168.255.*, или любую подсеть класса B из 172.16.*.* - 172.31.*.*, или подсеть класса A 10.*.*.*. В этом документе я буду считать, что ваша частная сеть (если вы решили создать таковую) основана на подсети класса C 192.168.1.*, шлюз в частную сеть имеет IP адрес 10.1.1.9 - один из адресов, выделенных вам вашим провайдером (примечание: этот адрес не является корректным внешним IP адресом и используется мной лишь в качестве примера). Кроме того, я буду считать, что имеется машина betty.example.com с адресом 10.1.1.10, обслуживающая WWW и FTP запросы.

Подсчитайте количество внешних IP адресов, необходимых для ваших машин. Оно должно быть равно количеству машин вне частной сети плюс один IP адрес для шлюза в частную сеть. В это число не входят IP адреса, используемые маршрутизаторами, широковещательные IP адреса и т. п. Попросите своего провайдера выделить вам диапазон IP адресов, достаточно большой для включения в него этого числа машин. Например, в сети моего офиса из 8 IP адресов, выделенных провайдером, три не могли быть использованы моими компьютерами, что оставляло четыре IP адреса для работы вне частной сети плюс один IP адрес для шлюза.

Хотя эта топология сети подходит не для всех, она является разумной отправной точкой для многих конфигураций, не требующих решения специфических задач. Преимущества этой конфигурации:

• Масштабируемость. Если вам внезапно понадобится увеличить вдвое количество рабочих станций, то не придется беспокоиться о получении нового диапазона IP адресов от провайдера и о перенастройке сетевых интерфейсов ваших машин.

• Управление локальной сетью. Добавление рабочей станции в вашу частную сеть не требует общения с вашим провайдером, в отличие от незащищенных хостов, требующих, в случае предоставления ими специфических услуг, коррекции прямых и обратных записей DNS (domain name service (служба имен доменов)) - например ssh и ftpd могут "жаловаться" на отсутствие корректных DNS записей. Обратная DNS запись - это запись, описывающая имя хоста по его IP адресу.

• Централизованная система безопасности. Шлюз частной сети может фильтровать пакеты и вести журнал внешних атак, принудительно обеспечивая общую систему безопасности для всей внутренней (частной) сети. В этом случае нет необходимости настраивать систему безопасности отдельно на каждой рабочей станции и сервере внутренней сети. Кроме того, фильтры могут выставляться не только на входящие, но и на исходящие пакеты, так что неправильно настроенная рабочая станция не сможет неумышленно передавать во внешний мир не предназначенные для этого данные.

• Переносимость. Так как IP адреса, используемые во внутренней сети, останутся вашими до тех пор, пока вы этого хотите, то в случае перехода всей сети на новый диапазон IP адресов (например, при смене провайдера) вам не придется менять конфигурацию внутренней сети. Незащищенные хосты, в этом случае, естественно, нуждаются в перенастройке.

• Прозрачный доступ в Интернет. Машины из внутренней сети по-прежнему могут использовать FTP, telnet, WWW и другие услуги, с небольшими ограничениями. Пользователи могут даже не задумываться о том, имеется ли у их машин видимый снаружи адрес IP.

Некоторые из потенциальных недостатков этой конфигурации:

• Некоторые услуги не будут доступны напрямую для машин из внутренней сети. Например, синхронизация по NTP с внешним хостом; некоторые услуги, предоставляемые серверами, не имеющими поддержки маскирования в ядре; .shosts аутентификация внешними узлами для ведения журнала весьма затруднительны или невозможны. Однако почти всегда можно найти простые обходные пути.

• Более высокая стоимость сетевого оборудавания. Для шлюза внутренней сети необходимы две сетевые карты. Также требуется, как минимум, два хаба/коммутатора, один для внутренней сети, другой - для видимой снаружи.

• Машины, находящиеся вне внутренней сети, не могут напрямую подсоединяться к машинам, находящимся во внутренней сети. Это можно сделать, зайдя сперва на шлюз внутренней сети, а затем уже с него на машину внутренней сети. Хотя можно пропускать через firewall все пакеты в обе стороны, но не рекомендуется делать этого по соображениям безопасности (см. ниже).

Вы должны взвесить все "за" и "против" и решить, не является ли полностью видимая извне сеть более подходящим решением в вашем случае. Далее в документе я буду предполагать, что ваша сеть построена так, как указано выше. Если вы предпочли полностью видимую снаружи сеть, то некоторые детали будут отличаться. Я попытаюсь указать на эти отличия.

В особом случае, если вам не требуются внешние сервера, то шлюз провайдера может быть подключен непосредственно к внешнему интерфейсу шлюза внутренней сети, а не к хабу.