Здравствуйте, уважаемые коллеги!

С вами снова Павел Медников, и сегодня мы с вами продолжим наш разговор об основах IP-адресации и рассмотрим такие понятия как «реальные» и «серые» IP-адреса, а также поговорим о технологии NAT. Статья будет длинной, поэтому рекомендую запастись терпением. Понимание принципа работы NAT очень пригодится вам в дальнейшем, поэтому я настаиваю на внимательном прочтении данного выпуска. Если вы не читали предыдущий выпуск рассылки, где рассматривались основы IP-адресации, вы можете найти его в архиве рассылки

Как вы понимаете, любой хост, находящийся в сети Интернет должен иметь свой собственный IP-адрес для того, чтобы обмениваться данными с другими хостами. Если мы владеем каким-то ресурсом, которым пользуются сотни тысяч пользователей (например, web-сервер, почтовый сервер, сервер онлайновой платежной системы, игровой сервер идр), этот адрес должен быть неизменным на протяжение как можно большего количества времени. При этом нужно понимать, что количество IP-адресов конечно, и рано или поздно сложится такая ситуация, когда количество устройств, подключенных к Интернет, превысит количество адресов, которое может быть описано при помощи 32 битной последовательности. Как только будет использован последний из доступных адресов, Сеть перестанет развиваться, что станет началом ее конца.
Сегодня проблему количества IP-адресов пытаются решить при помощи внедрения протокола адресации IPv6, о котором мы говорили в прошлый раз. Это довольно сложный протокол, который разрабатывался много лет, реализован чуть ли не десять лет назад, но пока мало кем используется, т.к обеспечить маршрутизацию из сети, адресуемой по IPv6 в сеть с IPv4-адресацией без шаманского бубна довольно затруднительно. Тем не менее, проблему ограниченности IPv4-адресации предвидели очень давно и придумали ей пусть и временное, но довольно изящное решение.
Суть в том, что из всего набора адресов, которые могут быть закодированы в виде xxx.xxx.xxx.xxx, было решено выделить несколько специальных подсетей (проще говоря, несколько диапазонов адресов), с которыми невозможно организовать обмен данными без неких ухищрений (об этом – ниже). Проще говоря, разработчики договорились, что существует несколько особых групп адресов (сетей), на которые невозможно доставить данные с обычных адресов. При этом внутри таких сетей данные передаются стандартным образом и без ограничений. Такие группы адресов назвали «частными сетями», т.к. они были предназначены для использования всеми желающими без согласования с какими-либо официальными инстанциями, и все, что происходит внутри таких сетей – частное дело владельца. В противовес частным сетям, адреса, доступные всем пользователям Интернет, называют «публичными». В русской терминологии частные сети иногда называют «серыми» по той причине, что к ним невозможен доступ из сети Интернет без применения специальных технических приемов (сравните с «серой» бухгалтерией :) ). В свою очередь, публичные адреса также называют «белыми».

К частным адресам относятся следующие диапазоны (подробности – в документе RFC1918):
10.0.0.0 – 10.255.255.255 (сеть класса A, маска 255.0.0.0, количество допустимых адресов 2²⁴)
172.16.0.0 – 172.31.255.255 (16 сетей класса B, маска 255.255.0.0, количество допустимых адресов 2¹⁶)
192.168.0.0 – 192.168.255.255 (256 сетей класса C, маска 255.255.255.0, количество допустимых адресов 2⁸)
Естественно, все эти сети можно делить на подсети, как это было описано в предыдущем выпуске и получить, например, частную сеть вида 10.10.1.0 / 28. В этом нет ничего противоестественного. 

Маршрутизация пакетов с данными из «белых» (публичных) сетей в данные сети без применения шаманского бубна невозможна.
Что это дает системным администраторам мира? В первую очередь - возможность строить огромные сети на много сотен хостов, не согласовывая свои действия ни с какими инстанциями, и не беспокоясь о том, что будет, если где-то рядом кто-то построит такую же сеть с такими же адресами. Даже если обе эти сети буду иметь выходв публичную сеть Интернет, это никак не скажется на их работоспособности – данные между «серыми» и «белыми» сетями не маршрутизируются и конфликтов из-за того, что в разных частных сетях существует, например, два компьютера с адресом 192.168.1.100, не возникнет. Во-вторых, мы имеем изрядную экономию «белых» IP-адресов и можем ограничиться одним-двумя публичными IP-адресами, чтобы подключить к Интернету частную сеть из сотни-другой компьютеров.

А теперь вы мне, конечно же, зададите вопрос – КАК можно соединить частную сеть с публичной, если маршрутизация между «серыми» и «белыми» сетями не осуществляется? Для решения этой задачи существует две технологии: прокси-сервер и трансляция сетевых адресов (NAT).
Прокси-сервер – это посредник между публичной сетью и конечным потребителем. Потребитель подключается к прокси-серверу и запрашивает его на предмет получения тех или иных данных из  публичной сети. В свою очередь, прокси-сервер направляет этот запрос в сеть уже от своего имени, а полученный результат «отдает» конечному потребителю. Эта технология имеет свои достоинства и недостатки, самый большой из которых заключается в том, что через прокси-сервер, как правило, нельзя установить соединение, требующее постоянного двустороннего обмена данными. Например, при помощи прокси-сервера нельзя подключиться ко многим службам, подразумевающим интерактивное взаимодействие с пользователями (сетевые игры, видеоконференции, IP-телефония и др.)

ВАЖНАЯ ДЕТАЛЬ: часто словом «прокси-сервер» называют решение, имеющее помимо классического прокси еще и функцию NAT (например, MS ISA, UserGate, Winroute и др), пожалуйста, избегайте путаницы! Прокси-сервер не всегда может иметь прямое подключение к Интернет!

Другая технология – NAT или трансляция сетевых адресов (network address translation), использует иной принцип работы. Для ее реализации нужно устройство с двумя сетевыми интерфейсами, один из которых имеет «белый» адрес и соединен с публичной сетью, а второй соединен с «серой» сетью и ему назначен соответствующий IP. Таким устройством может быть специализированный маршрутизатор, межсетевой экран (firewall, брандмауэр) или обычный компьютер с двумя сетевыми платами и соответствующим программным обеспечением.
Как известно, данные в Интернет (как и в любой сети, где используются протоколы TCP/IP) передаются фрагментами, которые называют словом «пакет». Каждый пакет с данными, будь то запрос или ответ, помимо значащей информации снабжен служебным заголовком, в котором хранятся данные об IP-адресе отправителя пакета и IP-адресе получателя. Анализируя эти заголовки, маршрутизаторы, как регулировщики на перекрестке, направляют пакеты в нужные подсети. Получив пакет с данными, хост всегда «знает», от какого хоста пакет был отправлен, т.к. эта информация содержится в его заголовке. Ответный пакет будет отправлен именно на этот адрес. Так хосты будут «переговариваться» до тех пор, пока сессия связи не будет окончена из-за обрыва соединения или по взаимному согласию.

Содержимое заголовков, естественно, можно модифицировать. Представим себе, что есть хосты А и В, между которыми находится хост С (А -> С -> В), и хост А, отправляет пакет на хост В (в заголовке пакета IP отправителя будет адресом хоста А, а IP получателя – адресом хоста В). Если этот пакет будет перехвачен в дороге хостом С, который модифицирует заголовок и заменит в нем адрес отправителя на свой IP, то хост В, получив такой пакет отправит ответ… Правильно - на хост С.
Это произойдет потому, что хост В ориентируется на содержание заголовков пакета и в действительности не имеет понятия о том, кто же все-таки настоящий «папа» пакета (подмену адресов, кстати, часто используют хакеры для того, чтобы перенаправить интересующий их трафик в нужную им сторону). Сессия между хостами А и В не состоится, зато хост В будет «общаться» со встрявшим в разговор хостом С, который с самого начала был вроде бы как и не при чем.
А теперь представьте, что хост С, получив ответный пакет от хоста В, не станет «присваивать» его, а отправит дальше – на хост А, предварительно поправив адрес получателя, и сохранив в качестве IP отправителя адрес хоста В. В итоге хосты А и В будут "общаться", совершенно не подозревая, что между ними находится кто-то третий (А!? КТО ЗДЕСЬ?!). Дальше – больше: представьте, что хост А находится в «серой» сети, а хост В – в «белой». Если хост С, который занимается описанными выше «играми» с IP-адресами отправителя-получателя будет иметь две сетевых платы, встанет на границе «серой» и «белой» сетей (т.е. превратится в маршрутизатор) и будет объявлен основным шлюзом для хоста А (про основной шлюз мы говорили в прошлом выпуске нашей рассылки), то мы получим устройство, которое соединит частную и публичную сеть и позволять пакетам данных перемещаться из одной сети в другую, несмотря на то, что маршрутизация между «белыми» и «серыми» сетями не предусмотрена.

Технология модификации адресов отправителя и получателя в заголовках IP-пакетов в момент прохождения их через маршрутизатор получила название NAT – network address translation (трансляция сетевых адресов). В процессе работы маршрутизатор строит в своей памяти таблицу, где запомнит, какой из хостов с «серым» IP и куда обращался, чтобы направить пришедшие из публичной сети ответные пакеты именно тому, кто их «ждет». Применяя эту технологию, мы можем использовать единственный адрес (причем, не важно, частный или публичный), предоставленный провайдером при подключении к Интернет, чтобы дать доступ к ресурсам Сети нескольким десяткам и даже сотням пользователей - лишь бы хватило пропускной способности канала. Все что нужно для счастья – поставить маршрутизатор, реализующий NAT (а сейчас это все умеют, кажется), и подключить его одним «хвостом» к порту, предоставленному провайдером, а другим – в коммутатор вашей локальной сети. Компьютеры локальной сети должны быть настроены на использование машрутизатора с NAT в качестве шлюза по умолчанию, т.е. параметр «основной шлюз» в настройках сетевой платы каждого из ваших компьютеров должен содержать IP-адрес, присвоенный интерфейсу маршрутизатора, подключенного в локальную сеть.

К СВЕДЕНИЮ: Неважно, какой адрес для подключения к Интернет вам выдал провайдер – «серый» или «белый». Маршрутизатору с NAT все равно, какой адрес в какой преобразовывать!

Технология NAT лишена недостатков прокси-сервера и позволяет пользователям частной сети пользоваться интерактивными сетевыми приложениями (IP-телефонией, конференциями, онлайновыми играми, терминальными серверами и др).

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

Подведем итог:

• IP-адреса условно поделены на публичные и частные. Передача данных между публичными и частными сетями невозможна без особых ухищрений.
• Вы можете свободно распоряжаться адресами, входящими в пул частных сетей, не советуясь ни с кем. Вы сами вольны назначать адреса, маски подсетей, делить сети под ваши нужды и др. Что бы вы ни делали, это никак не отразится, ни на Интернет, ни на сетях других организаций.
• Частную сеть можно подключить к Интернет при помощи прокси-сервера и технологии NAT. Первый способ не дает возможности полноценно использовать интерактивные Интернет-службы, зато NATне имеет такого ограничения.
• Иногда прокси-сервер объединяют в одном софтверном решении с NAT, однако следует помнить, что это разные технологии.
• NATдает «прячет» вашу сеть, подключенную к Интернет, от  других пользователей публичных сетей. Вы можете публиковать отдельные ресурсы по вашему желанию (об этом – чуть позже). Это дает дополнительную защиту от атак, осуществляемых из Интернета всевозможными червями и иным вредоносным ПО, эксплуатирующим «дыры» в Windows (ведь именно эта ОС стоит на большинстве офисных компьютеров).

На сегодня это все. В следующей статье мы рассмотрим вопросы статической и динамической адресации, а также дополнительные бонусы, которые дает нам грамотное использование особенностей протокола DHCP.

С уважением,
Павел Медников