Linux iptables проброс портов

Проброс и перенаправление портов в iptables

Проброс трафика за NAT или проброс трафика на другой сервер

Чаще всего проброс трафика используется, если мы находимся в локальной сети и от внешнего мира отделены шлюзом. Для того, чтобы открыть доступ для локальных служб (ssh, web, ftp), нам необходимо пробросить порты. Поскольку в качестве шлюза мы будем использовать сервер на Linux, то осуществлять данные действия будем с помощью iptables.

Определимся с переменными, которые будут использоваться в статье:

$EXT_IP — внешний, реальный IP-адрес шлюза;
$INT_IP — внутренний IP-адрес шлюза, в локальной сети;
$LAN_IP — внутренний IP-адрес сервера, предоставляющего службы внешнему миру;
$SRV_PORT — порт службы. Для веб-сервера равен 80, для SMTP — 25 и т.д.;
eth0 — внешний интерфейс шлюза. Именно ему присвоен сетевой адрес $EXT_IP;
eth1 — внутренний интерфейс шлюза, с адресом $INT_IP;

Проброс портов

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

Рассмотрим пример

Если входящий пакет пришёл извне на шлюз (1.2.3.4), но предназначен веб-серверу (порт 80), то адрес назначения подменяется на локальный адрес 192.168.1.50. И впоследствии маршрутизатор передаст пакет в локальную сеть.

Дальше принимается решение о маршрутизации. В результате пакет пойдёт по цепочке FORWARD таблицы filter, поэтому в неё надо добавить разрешающее правило. Оно может выглядеть, например, так:

Рассмотрим пример

Пропустить пакет, который пришёл на внешний интерфейс, уходит с внутреннего интерфейса и предназначен веб-серверу (192.168.1.50:80) локальной сети.

С одной стороны, этих двух правил уже достаточно для того, чтобы любые клиенты за пределами локальной сети успешно подключались к внутреннему серверу. С другой — а что будет, если попытается подключиться клиент из локальной сети? Подключение просто не состоится: стороны не поймут друг друга.

Допустим, 192.168.1.31 — ip-адрес клиента внутри локальной сети.

1. Пользователь вводит в адресную строку браузера адрес example.com;
2. Сервер обращается к DNS и разрешает имя example.com в адрес 1.2.3.4;
3. Маршрутизатор понимает, что это внешний адрес и отправляет пакет на шлюз;
4. Шлюз, в соответствии с нашим правилом, подменяет в пакете адрес 1.2.3.4 на 192.168.1.50, после чего отправляет пакет серверу;
5. Веб-сервер видит, что клиент находится в этой же локальной сети (обратный адрес пакета — 192.168.1.31) и пытается передать данные напрямую клиенту, в обход шлюза;
6. Клиент игнорирует ответ, потому что он приходит не с 1.2.3.4, а с 192.168.1.50;
7. Клиент и сервер ждут, но связи и обмена данными нет.

Есть два способа избежать данной ситуации.

Первый — разграничивать обращения к серверу изнутри и извне, для этого создать на локальном DNS-сервере А-запись для example.com указывающую на 192.168.1.50

Второй — с помощью того же iptables заменить обратный адрес пакета.
Правило должно быть добавлено после принятия решения о маршрутизации и перед непосредственной отсылкой пакета. То есть — в цепочке POSTROUTING таблицы nat.

Рассмотрим пример

Если пакет предназначен веб-серверу, то обратный адрес клиента заменяется на внутренний адрес шлюза.
Этим мы гарантируем, что ответный пакет пойдёт через шлюз.

Надо дополнительно отметить, что это правило важно только для внутренних клиентов. Ответ внешним клиентам пойдёт через шлюз в любом случае.

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

Рассмотрим пример

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

rules.sh

Теперь, чтобы обеспечить доступ извне к локальному FTP по адресу 192.168.1.52, достаточно набрать в консоли от имени супер-пользователя:

Перенаправление портов

Перенаправление портов нужно в том случае, если мы хотим «замаскировать» внутреннюю службу, обеспечив к ней доступ извне не по стандартному, а совсем по другому порту.

Пусть $FAKE_PORT — обманный порт на внешнем интерфейсе шлюза, подключившись к которому мы должны попасть на адрес $LAN_IP и порт $SRV_PORT .

Набор правил для iptables будет отличаться несущественно, поэтому приведу сразу пример итогового скрипта для ленивых.

Источник

Проброс портов iptables в Linux

С увеличением количества компьютеров, необходимое количество IP адресов увеличивалось и диапазона IPv4 начало не хватать. Тогда была разработана технология NAT, которая позволяет нескольким компьютерам объединяться в локальную сеть и быть доступными из внешней сети по IP адресу маршрутизатора.

Когда пакет приходит на маршрутизатор, выполняется выяснение какому устройству он был адресован и замена ip адресата на нужный. Кроме переопределения IP получателя и отправителя, NAT может изменять порты. Это называется проброс портов и может быть полезно если вы создали частную сеть, но все же хотите пропускать некоторые виды трафика. Всем этим можно управлять с помощью iptables. В этой статье мы рассмотрим как выполняется проброс портов iptables в Linux.

Как работает NAT?

Чтобы иметь возможность общаться с другими компьютерами в сети компьютер должен иметь уникальный ip адрес. Но поскольку количество адресов уменьшалось нужно было придумать технологию, которая позволяла бы давать один адрес нескольким машинам. И была придумана технология NAT или Network Address Translation.

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

Недостаток в том, что инициировать подключение извне нельзя, потому что маршрутизатор просто еще не знает к кому обращаются. Тут на помощь приходит проброс портов. Мы можем сказать роутеру: при поступлении пакетов на порт 80 перенаправлять их на порт 80 компьютера 192.168.1.2. Теперь адрес отправителя и порт будет заменяться на указанный нами и пакет будет передан туда, куда нужно. Если на маршрутизаторе установлен Linux, то все это можно настроить с помощью iptables.

Проброс портов в iptables

Первое что нужно сделать, это включить переадресацию трафика на уровне ядра, если это еще не сделано. Для этого выполните:

echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward

Чтобы настройка сохранялась после перезагрузки используйте такую команду:

sudo sysctl -w net.ipv4.ip_forward=1

Мы не будем здесь подробно рассматривать правила iptables и значение каждой опции, поэтому перед тем, как читать дальше вам лучше ознакомиться со статьей iptables для начинающих. Дальше рассмотрим проброс портов iptables nat.

Настройка прохождения пакетов

Сначала мы рассмотрим как разрешить прохождение пакетов через маршрутизатор. Для этого в брандмауэре есть цепочка FORWARD. По умолчанию для всех пакетов применяется правило DROP, которое означает что все нужно отбросить. Сначала разрешим инициализацию новых соединений, проходящих от eth0 до eth1. Они имеют тип contrack и представлены пакетом SYN:

sudo iptables -A FORWARD -i eth0 -o eth1 -p tcp —syn —dport 80 -m conntrack —ctstate NEW -j ACCEPT

Действие ACCEPT означает, что мы разрешаем это соединение. Но это правило разрешает только первый пакет, а нам нужно пропускать любой следующий трафик в обоих направлениях для этого порта (80). поэтому добавим правила для ESTABLIHED и RLEATED:

sudo iptables -A FORWARD -i eth0 -o eth1 -m conntrack —ctstate ESTABLISHED,RELATED -j ACCEPT
$ sudo iptables -A FORWARD -i eth1 -o eth0 -m conntrack —ctstate ESTABLISHED,RELATED -j ACCEPT

Дальше явно установим что наша политика по умолчанию — DROP:

sudo iptables -P FORWARD DROP

Это еще не проброс портов, мы только разрешили определенному трафику, а именно на порт 80, проходить через маршрутизатор на другие машины локальной сети. Теперь настроим правила, которые будут отвечать за перенаправление трафика.

Модификация пакетов в iptables

Далее мы настроим правила, которые будут указывать как и куда нужно перенаправить пакеты, приходящие на порт 80. Сейчас маршрутизатор может их пропускать в сеть, но он еще не знает куда. Для этого нам нужно будет настроить две вещи — модификацию адреса назначения (Destination) DNAT и модификацию адреса отправителя (Source) SNAT.

Правила DNAT настраиваются в цепочке PREROUTING, в таблице NAT. Эта операция изменяет адрес назначения пакета чтобы он достиг нужной нам цели, когда проходит между сетями. Клиенты будут отправлять пакеты нашему маршрутизатору, и им не нужно знать топологию внутренней сети. Пакет автоматически будет приходить нашему веб-серверу (192.168.1.2).

С помощью этого правила мы перенаправляем все пакеты, пришедшие на порт 80, к 192.168.1.2 опять же на порт 80:

sudo iptables -t nat -A PREROUTING -i eth0 -p tcp —dport 80 -j DNAT —to-destination 192.168.1.2

Но это только половина работы. Пакет будет иметь исходный адрес клиента, а значит будет пытаться отправить ответ ему. Так как клиент ожидает получить ответ от маршрутизатора, то нормального TCP соединения не получиться. Чтобы решить эту проблему нужно модифицировать адрес источника и заменить его на адрес маршрутизатора 192.168.1.1. Тогда ответ придет маршрутизатору, а тот уже от своего имени передаст его в сеть.

sudo iptables -t nat -A POSTROUTING -o eth1 -p tcp —dport 80 -d 192.168.1.2 -j SNAT —to-source 192.168.1.1

Если вы хотите перенаправить трафик на порт 8080, то нужно указать его после ip адреса:

sudo iptables -t nat -A POSTROUTING -o eth1 -p tcp —dport 80 -d 192.168.1.2 -j SNAT —to-source 192.168.1.1:8080

Также может понадобиться выполнить проброс диапазона портов iptables, для этого просто укажите диапазон, например, 1000:2000:

sudo iptables -t nat -A POSTROUTING -o eth1 -p tcp —dport 1000:2000 -d 192.168.1.2 -j SNAT —to-source 192.168.1.1

После добавления этого правила можете проверять работу перенаправление портов iptables будет выполняться и все будет отправляться так, как нужно.

Сохранение настроек iptables

Теперь, когда все настроено, нужно сохранить этот набор правил, чтобы он загружался автоматически при каждом старте. Для этого выполните:

sudo service iptables-persistent save

Готово. Теперь проброс портов iptables ubuntu будет работать так, как нужно.

Выводы

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

На завершение, видео о том, что такое NAT:

Источник

Проброс портов (port forwarding) в Linux используя iptables

В этой статье поговорим о том, как можно перенаправить трафик с IP адреса (белого) на другой IP адрес (серый) использую утилиту iptables.

Начальные данные

У нас имеется компьютер под управлением linux, выступающий в роли маршрутизатора с одним внешним интерфейсом enp0s3 для доступа в Интернет (80.81.82.83) и внутренним enp0s8 интерфейсом Локальной сети (10.0.7.1). Требуется пробросить tcp порт (2222) с белого ip-адреса на серый ip-адрес Локальной сети порт (22).

Чаще всего проброс трафика используется, если мы находимся в локальной сети и от внешнего мира отделены шлюзом. Для того, чтобы открыть доступ для локальных служб (ssh, web, ftp и т.д.), нам необходимо пробросить порты. Поскольку в качестве шлюза мы будем использовать сервер на Linux, то осуществлять данные действия будем с помощью утилиты iptables.

Алгоритм проброса портов в iptables.

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

Для автоматического включения открываем файл /etc/sysctl.conf и ищем там строку #net.ipv4.ip_forward=1 , убираем знак комментария.

Настройка port forwarding на Linux

Итак, приступим. Для выполнения поставленной задачи, перенаправление порта 2222 на порт 22 другой машины, необходимо добавить следующие правила iptables:

Это правило разрешает прохождение входящих пакетов внутрь сети.

Теперь опишем форвардинг (forwarding) пакетов:

• Первая строка подменяет IP адрес приемника (белый IP) на внутренний (серый IP)
• Вторая адрес отправителя (серый IP) на внешний (белый IP).
• 10.0.7.2 — IP адрес машины в локальной сети, на который перенаправляет трафик.
• 80.81.82.83 — внешний IP адрес нашего сервера.
• 22 — внутренний порт локальной машины
• 2222 — внешний порт для подключения.

Перенаправления всего трафика

Если есть необходимость проброса всего трафика, то выполним следующее правило.

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

содержимое файла по первому примеру:

Далее открываем файл interfaces

И добавляем в конце следующую строчку:

Данное выражение подгрузить правила iptables после перезагрузки системы.

Как посмотреть правила iptables

Посмотреть текущие правила iptables можно с помощью команды:

Вот и все, на этом рассмотрение проброса портов в операционных системах под управлением Linux с помощью iptables завершено.

Если есть вопросы, то пишем в комментариях.

Также можете вступить в Телеграм канал, ВК или подписаться на Twitter. Ссылки в шапки страницы.
Заранее всем спасибо.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

Linux iptables проброс портов

GNU без Linux

К 1990 году в рамках проекта GNU, основанного Ричардом Столлманом, были разработаны и постоянно развивались свободные программы, составляющие основной инструментарий для разработки программ на языке Си: текстовый редактор Emacs, компилятор языка Си gcc, отладчик программ gdb, командная оболочка bash, библиотека важнейших функций для программ на Си libc. Все эти программы были написаны для операционных систем, похожих на UNIX. Поэтому в них использовались стандартные для UNIX системные вызовы — POSIX. При помощи системных вызовов программы получают доступ к оперативной памяти, файловой системе, устройствам ввода и вывода. Благодаря тому, что системные вызовы выглядели более-менее стандартно во всех реализациях UNIX, программы GNU могли работать (с минимальными изменениями или вообще без изменений) в любой UNIX-подобной операционной системе.

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

Linux — ядро

В 1991 году Линус Торвальдс, финский студент, чрезвычайно увлёкся идеей написать совместимое с UNIX ядро операционной системы для своего персонального компьютера с процессором ставшей очень широко распространённой архитектуры Intel 80386. Прототипом для будущего ядра стала операционная система MINIX: совместимая с UNIX операционная система для персональных компьютеров, которая загружалась с дискет и умещалась в очень ограниченной в те времена памяти персонального компьютера. MINIX был создан Эндрю Таненбаумом в качестве учебной операционной системы, демонстрирующей архитектуру и возможности UNIX, но непригодной для полноценной работы с точки зрения программиста. Именно полноценное ядро для своего ПК и хотел сделать Линус Торвальдс. Название своему ядру он дал freax, но позже оно было изменено хозяином ftp сервера на Linux — гибрид имени создателя и слова UNIX.

Совместимость с UNIX в этот момент означала, что операционная система должна поддерживать стандарт POSIX. POSIX — это функциональная модель совместимой с UNIX операционной системы, в которой описано, как должна вести себя система в той или иной ситуации, но не приводится никаких указаний, как это следует реализовать программными средствами. POSIX описывал те свойства UNIX-совместимых систем, которые были общими для разных реализаций UNIX на момент создания этого стандарта. В частности, в POSIX описаны системные вызовы, которые должна обрабатывать операционная система, совместимая с этим стандартом.

Важнейшую роль в развитии Linux сыграли глобальные компьютерные сети Usenet и Internet. На самых ранних стадиях Линус Торвальдс обсуждал свою работу и возникающие трудности с другими разработчиками в телеконференции comp.os.minix в сети Usenet, посвящённой операционной системе MINIX. Ключевым решением Линуса стала публикация исходных текстов ещё малоработоспособной первой версии ядра под свободной лицензией GNU GPL. Благодаря этому и получавшей всё большее распространение сети Internet очень многие получили возможность самостоятельно компилировать и тестировать это ядро, участвовать в обсуждении и исправлении ошибок, а также присылать исправления и дополнения к исходным текстам Линуса. Теперь над ядром работал уже не один человек, разработка пошла быстрее и эффективнее.

В 1992 году версия ядра Linux достигла 0.95, а в 1994 году вышла версия 1.0, что свидетельствовало о том, что разработчики наконец сочли, что ядро в целом закончено и все ошибки (теоретически) исправлены. В настоящее время разработка ядра Linux — дело уже гораздо большего сообщества, чем во времена до версии 1.0. Изменилась и роль самого Линуса Торвальдса: теперь он не главный разработчик, а наиболее авторитетный член сообщества, по традиции оценивающий качество исходных текстов, которые должны быть включены в ядро, и дающий своё добро на их включение. Тем не менее, общая модель свободной разработки сообществом сохраняется.

GNU и Linux

Однако как нельзя сделать операционную систему без ядра, так и ядро будет бесполезно без утилит, которые использовали бы его возможности. Благодаря проекту GNU Линус Торвальдс сразу получил возможность использовать с Linux свободные утилиты: bash, компилятор gcc, tar, gzip и многие другие уже известные и широко используемые приложения, которые могли работать с его UNIX-совместимым ядром. Так Linux сразу попал в хорошее окружение и в сочетании с утилитами GNU представлял собой очень интересную среду для разработчиков программного обеспечения даже на самой ранней стадии своего развития.

Принципиальным шагом вперёд было именно то, что из ядра Linux и утилит и приложений GNU впервые стало возможно сделать полностью свободную операционную систему, то есть работать с компьютером и, более того, разрабатывать новое программное обеспечение, пользуясь только свободным программным обеспечением. Идеал полностью некоммерческой разработки, сформулированный Столлманом, теперь мог быть воплощён в жизнь.

Вскоре появлялись теоретические возможности воплощения идеала, но это не означало его немедленной практической реализации. Совместимость Linux и утилит GNU была обусловлена тем, что и то, и другое писалось с ориентацией на одни и те же стандарты и практику. Однако в рамках этой практики (то есть при наличии множества различных UNIX-систем) оставался большой простор для несовместимости и различных решений. Поэтому на начальном этапе разработки ядра каждое заработавшее на Linux приложение GNU было для Линуса очередным достижением. Первыми стали bash и gcc. Таким образом, сочетание GNU и Linux давало возможность создать свободную операционную систему, но само по себе ещё не составляло такой системы, потому что Linux и различные утилиты GNU оставались разрозненными программными продуктами, написанными разными людьми, не всегда принимавшими в расчёт то, что делали другие. Основным же свойством любой системы является согласованность её компонентов.

Возникновение дистрибутивов

После определённого периода разработки на Linux уже стабильно работал ряд важнейших утилит GNU. Скомпилированное ядро Linux с небольшим комплектом скомпилированных уже на Linux утилит GNU составляло набор инструментов для разработчика программного обеспечения, желающего использовать свободную операционную систему на своём персональном компьютере. В таком виде Linux уже не только годился для разработки Linux, но и представлял собой операционную систему, в которой можно было уже выполнять какие-то прикладные задачи. Конечно, первое, чем можно было заниматься в Linux — писать программы на Си.

Когда задача получить компьютер с постоянно работающей на нём системой Linux стала востребованной и довольно распространённой, разработчики в хельсинкском и техасском университетах создают собственные наборы дискет, с которых скомпилированное ядро и основные утилиты можно записать на жёсткий диск, после чего загружать операционную систему прямо с него. Эти наборы дискет стали первыми прототипами современных дистрибутивов Linux — комплектов программного обеспечения, на основе которых можно получить работающую операционную систему на своём компьютере. Нужно отметить, что в дистрибутив Linux с самого начала входили программные продукты GNU. На самом деле, всякий раз, когда говорится «операционная система Linux», подразумевается «ядро Linux и утилиты GNU». Фонд свободного ПО рекомендует называть это операционной системой Linux.

Однако скопировать все нужные программы на жёсткий диск ещё недостаточно, чтобы получить подходящую для нужд пользователя операционную среду (пусть даже это очень профессиональный пользователь). Поэтому первые наборы дискет можно только условно назвать дистрибутивами. Чтобы получить работающую операционную систему, требуются какие-то специальные средства установки и настройки программного обеспечения. Именно наличие таких средств и отличает современные дистрибутивы Linux. Другая важнейшая задача дистрибутива — регулярное обновление. Программное обеспечение, особенно свободное, — одна из самых быстро развивающихся областей, поэтому мало один раз установить Linux, нужно ещё регулярно его обновлять. Первым дистрибутивом в современном понимании, получившим широкое распространение, стал Slackware, созданный Патриком Фолькердингом. Он был широко известен пользователям Linux уже к 1994 году.

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

Всё программное обеспечение для Linux было открытым, поэтому вскоре стало появляться всё больше прикладных программ для Linux, которые использовались всё большим сообществом, отчего становились надёжнее и получали всё новую функциональность. В конце концов возникает идея, что из Linux и GNU-приложений для Linux целенаправленными усилиями небольшой группы разработчиков можно делать целостные операционные системы, подходящие для очень широкого круга пользователей и продавать эти системы пользователям за деньги как аналог и альтернативу существующим патентованным операционным системам.

Выгода операционной системы, целиком состоящей из свободного программного обеспечения, очевидна — собирающие эту систему не должны никому платить за входящие в неё программы. Более того, дальнейшая разработка и обновление имеющихся программ ведётся сообществом разработчиков также совершенно бесплатно, не нужно платить сотрудникам, которые занимались бы этим. В итоге затраты фирмы, собирающей дистрибутив Linux для пользователя, ограничиваются оплатой программистов, интегрирующих разрозненные приложения в систему и пишущих программы для стандартизации процедур установки и настройки системы, чтобы облегчить эти задачи неподготовленному пользователю, а также затратами на самоиздание получившегося дистрибутива. Для конечного покупателя это означает принципиальное снижение цены на операционную систему.

Первой успешной компанией, работающей по такой схеме, стала Red Hat, появившаяся в 1995 году. Red Hat адресовала свои разработки не только программистам профессионалам, но и обыкновенным пользователям и системным администраторам, для которых компьютер — в первую очередь офисное рабочее место или рабочий сервер. Ориентируясь на уже существующие на рынке предложения для такого класса пользователей, Red Hat всегда уделял большое внимание разработке приложений с графическим интерфейсом для выполнения типичных задач по настройке и администрированию системы. Бизнес Red Hat развивался довольно успешно, в 1999 году эта компания акционировалась — сразу после выпуска акции росли в цене очень энергично, однако потом ажиотаж утих. В настоящее время доля Red Hat на рынке серверов и рабочих станций Linux очень велика. Благодаря Red Hat в сообществе пользователей Linux очень широкое распространение получил формат пакетов RPM.

Практически одновременно с Red Hat появился проект Debian. Его задача была примерно той же — сделать целостный дистрибутив Linux и свободного программного обеспечения GNU, однако этот проект был задуман как принципиально некоммерческий, проводимый в жизнь сообществом разработчиков, нормы взаимодействия в котором полностью соответствовали бы идеалам свободного ПО. Сообщество разработчиков Debian — международное, участники которого взаимодействуют через Internet, а нормы взаимодействия между ними определяются специальными документами — полиси (англ. policy).

Сообщество разработчиков не извлекает никакой прибыли от продажи Debian, его версии распространяются свободно, доступны в Интернет, могут распространяться и на твёрдых носителях (CD, DVD), но и в этом случае их цена редко сильно превышает стоимость носителя и наценку, окупающую затраты на издание. Первоначально разработка Debian спонсировалась Фондом свободного программного обеспечения. Адресатами дистрибутивов Debian всегда в первую очередь были профессиональные пользователи, так или иначе связанные с академической разработкой программного обеспечения, которые готовы читать документацию и собственными руками организовать нужный профиль системы, соответствующий именно их задачам. Ориентация на такую аудиторию предопределила некоторые тенденции развития Debian: в нём никогда не было обилия «простых» графических средств настройки среды, всевозможных «мастеров», однако всегда уделялось много внимания средствам последовательной и единообразной интеграции программного обеспечения в единую систему. Именно в Debian появился менеджер пакетов (APT). В настоящее время Debian — самый популярный дистрибутив Linux среди пользователей, являющихся профессионалами в области информационных технологий.

Всякий раз, когда свободное программное обеспечение оказывается востребованным, немедленно возникает множество альтернативных решений — так произошло и с дистрибутивами Linux. После 1995 года возникло (и продолжает возникать) огромное количество коммерческих компаний и свободных сообществ, которые ставят своей задачей подготовку и выпуск дистрибутивов Linux. У каждого из них — свои особенности, своя целевая аудитория, свои приоритеты. К настоящему времени на рынке дистрибутивов выделилось несколько лидеров, которые предлагают более или менее универсальные решения и наиболее широко известны и используются. Помимо уже названных Red Hat и Debian следует назвать в ряду дистрибутивов, ориентированных на рядового пользователя, немецкий SuSE и французский Mandriva (до 2005 года — Mandrake), среди адресованных специалистам — Gentoo. Но помимо «крупных» игроков на рынке дистрибутивов есть гораздо большее количество менее распространённых дистрибутивов. Теперь перед пользователем, желающим установить Linux, встаёт вопрос выбора дистрибутива. Критерии выбора — и задачи, которые предполагается решать с помощью Linux, и уровень подготовки пользователя, и технологии, и предстоящие контакты с тем сообществом, которое занимается разработкой дистрибутива.

История Linux в России

Получилось так, что в международном сообществе разработчиков, начинавших и продолжавших развивать Linux, все в той или иной степени могли объясняться по-английски. Это и неудивительно, поскольку исторически английский оказался языком компьютерной науки и операционной системы UNIX, глобальной сети Internet, программирования. В международном сообществе разработчиков программного обеспечения английский выполнял и выполняет роль, сравнимую с ролью латыни в научном сообществе средневековой Европы. Но если Linux предполагается использовать не только для программирования и общения с программистами, но и для решения повседневных задач, то необходима локализация, то есть возможность общаться с компьютером и при помощи компьютера на языках, отличных от английского.

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

Первой компанией, поставившей своей целью выпуск дистрибутивов Linux для русскоговорящих пользователей, стала УрбанСофт, открытая в Петербурге в 1992 году. Весь её бизнес состоял в выпуске и продаже CD-дисков с дистрибутивами свободного программного обеспечения. В первую очередь это были дистрибутивы Red Hat, а также Debian, в которые включались разработанные силами УрбанСофт пакеты для русификации.

Несколько позже в Москве IPLabs Linux Team выпускает Linux Mandrake Russian Edition — модифицированный (чтобы соответствовать нуждам русского пользователя) вариант дистрибутива Mandrake Linux. Впоследствии эта команда начинает выпускать дистрибутивы, которые отличаются от Mandrake уже не только наличием пакетов для русификации, но и другими принципиальными возможностями. В конце концов команда разработчиков создаёт фирму ALT Linux и начинает выпускать дистрибутивы под маркой ALT Linux.

Целью компании ASPLinux стал выпуск Red Hat с модификациями для поддержки русского языка. Название их продукта совпадает с названием компании.

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

Источник