How to Disable SIP ALG on a Mikrotik Posted by Yoel Gutierrez on 08 April 2014 11:56 AM

SIP ALG Explained Many of today's commercial routers implement SIP ALG (Application-level gateway), coming with this feature enabled by default. While ALG could help in solving NAT related problems, the fact is that many routers' ALG implementations are wrong and break SIP. There are various solutions for SIP clients behind NAT, some of them in client side (STUN, TURN, ICE), others in server side (Proxy RTP as RtpProxy,MediaProxy). ALG works typically in the client LAN router or gateway. In some scenarios some client side solutions are not valid, for example STUN with symmetrical NAT router. If the SIP proxy doesn't provide a server side NAT solution, then an ALG solution could have a place. An ALG understands the protocol used by the specific applications that it supports (in this case SIP) and does a protocol packet-inspection of traffic through it. A NAT router with a built-in SIP ALG can re-write information within the SIP messages (SIP headers and SDP body) making signaling and audio traffic between the client behind NAT and the SIP endpoint possible. SIP ALG problems The main problem is the poor implementation at SIP protocol level of most commercial routers and the fact that this technology is just useful for outgoing calls, but not for incoming calls: Lack of incoming calls: When a UA is switched on it sends a REGISTER to the proxy in order to be localizable and receive incoming calls. This REGISTER is modified by the ALG feature (if not the user wouldn't be reachable by the proxy since it indicated a private IP in REGISTER "Contact" header). Common routers just mantain the UDP "conntection" open for a while (30-60 seconds) so after that time the port forwarding is ended and incoming packets are discarded by the router. Many SIP proxies mantain the UDP keepalive by sending OPTIONS or NOTIFY messages to the UA, but they just do it when the UA has been detected as natted during the registration. A SIP ALG router rewrites the REGISTER request so the proxy doesn't detect the NAT and doesn't mantain the keepalive (so incoming calls will be not possible). Breaking SIP signalling: Many of the actual common routers with inbuilt SIP ALG modify SIP headers and the SDP body incorrectly, breaking SIP and making communication just impossible. Some of them do a whole replacing by searching a private address in all SIP headers and body and replacing them with the router public mapped address (for example, replacing the private address if it appears in "Call-ID" header, which makes no sense at all). Many SIP ALG routers corrupt the SIP message when writting into it (i.e. missed semi-colon ";" in header parameters). Writting incorrect port values greater than 65536 is also common in many of these routers. Dissallows server side solutions: Even if you don't need a client side NAT solution (your SIP proxy gives you a server NAT solution), if your router has SIP ALG enabled that breaks SIP signalling, it will make communication with your proxy impossible. Mikrotik SIP ALG is called a SIP Helper and is located under /IP>Firewall>Service ports To disable, run this command from the terminal: /ip firewall service-port disable sip Or from winbox just navigate to IP>Firewall and then click on the Service Ports tab and disable it through the GUI.

Запуск MAC после смерти одного винта на котором была домашняя директория пользователя

Запуск в однопользовательском режиме или в режиме подробного протоколирования

1. Выключите компьютер Mac, если он включен.
2. Включите компьютер, нажав кнопку питания.
3. Сразу нажмите и удерживайте клавишу Command (Apple) и одну из следующих:
• клавишу S для однопользовательского режима.  (Command-S)
• клавишу V для режима подробного протоколирования.  (Command-

В однопользовательском режиме (ключ загрузчика -s) вводим следующие команды:
#fsck -fy
Проверяем раздел на целостность
#mount -uw /
Перемонтируем корневой раздел с возможностью записи
#launchctl load /System/Library/LaunchDaemons/com.apple.opendirectoryd.plist
Запускаем демона Open Directory, чтобы утилита dscl могла вносить в нее изменения
#dscl . -create /Users/denromanoff
Создаем новую запись в локальном разделе (/) в категории /Users. Пока создается только запись в Open Directory, так что, не надо пугаться, что не создался каталог на диске, - до него очередь дойдёт.
#dscl . -create /Users/denromanoff UserShell /bin/bash
Задаём свежесозданному юзеру параметр шелла
#dscl . -create /Users/denromanoff RealName «Den Romanoff»
Указываем полное имя
#dscl . -create /Users/denromanoff UniqueID 502
Задаем ID пользователя
#dscl . -create /Users/denromanoff PrimaryGroupID 1000
Указываем ID основной группы пользователя
#dscl . -create /Users/denromanoff NFSHomeDirectory /Local/Users/denromanoff
Создаем домашнюю папку пользователя
#passwd denromanoff
Задаём пароль (нужно ввести два раза)
#dscl . -append /Groups/admin GroupMembership denromanoff
Делаем юзера админом
Обращаю внимание, что эта падла после каждого вызова dscl нещадно ругается на отсутствие файла com.apple.DirectoryServices.plist, что поначалу и ввело меня в некоторую блудню. Можно смело забивать на её проявления недовольства, т. к. все наши требования она выполняет сполна.
Ну, а дальше - happy end. Я зашел под свежесозданной учёткой и поправил пути к домашней директории основного пользователя, после чего перезагрузился и успешно залогинился.

Виртуальный полигон: Управляем фермой виртуальных серверов легко и непринужденно

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

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

Систему QEMU+KVM следует рассматривать только как ядро комплексной системы виртуализации, поверх которого должна быть построена более сложная инфраструктура для управления многими инстанциями QEMU.

Уровнем выше

Существует огромное количество самых разных систем управления парками виртуальных машин, использующих QEMU+KVM. Начиная от самопальных скриптов, в спешке набросанных сисадминами и выложенными в Сеть, и заканчивая серьезными коммерческими программными комплексами уровня предприятия. Однако наше внимание заслуживают только те из них, которые в своей работе используют библиотеку libvirt.

Libvirt — это отлаженная и со всех сторон протестированная библиотека, с помощью которой любое приложение может быть легко обучено управлению виртуальными серверами. Поэтому система, основанная на libvirt, будет, во-первых, априори стабильнее и предсказуемее разработок, использующих свой собственный интерфейс управления. Во-вторых, libvirt поддерживает кучу различных систем виртуализации, начиная с KVM и Xen и заканчивая VMware и OpenVZ. Это очевидный плюс, потому как если в будущем планируется переезд на другую систему, менять придется не много (более того, инструменты, входящие в состав пакета libvirt, позволяют произвести миграцию между системами без проблем).

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

virsh

Команда virsh — один из главных инструментов управления libvirt. Она входит в стандартную поставку самой библиотеки, поэтому из коробки доступна практически в любом дистрибутиве. Кроме того, это единственный инструмент, который умеет задействовать все возможности libvirt, поэтому если с другими системами возникнут проблемы, virsh всегда придет на выручку.

Для установки virsh следует инсталлировать в систему пакет libvirt, а также все необходимые для работы с виртуальными машинами пакеты (в нашем случае это kvm, qemu, dnsmasq и bridge-utils).

Эти пакеты доступны в репозитории любого дистрибутива, поэтому для их установки необходимо выполнить всего одну команду (пример для Ubuntu):

$ sudo apt-get install bridge-utils dnsmasq kvm \
qemu libvirt libvirt-bin

Также нам пригодится инструмент под названием virt-install, он нужен для создания файлов-описаний виртуальных окружений, которые понадобятся при работе с virsh, но не могут быть созданы ей (предполагается, что приложения, использующие libvirt, будут генерировать их сами):

$ sudo apt-get install virtinst

Чтобы команда virsh и другие инструменты работали правильно, должен быть запущен демон libvirtd. Обычно пакетные менеджеры запускают его самостоятельно при установке пакета, но в некоторых системах (например, ArchLinux) этого не происходит. Поэтому убедимся, что libvirtd запущен:

$ ps ax | grep libvirtd

Если он не работает, запустим его (в некоторых системах вместо
init.d следует указать rc.d):

$ sudo /etc/init.d/libvirtd start

Для проверки работоспособности всей системы выполним следующие команды:

$ sudo virsh --connect qemu:///system version
$ sudo virsh --connect qemu:///system list

Если все в порядке, первая команда должна вывести нечто вроде этого:

• Скомпилировано на базе библиотеки: libvir 0.9.0
• Используется библиотека: libvir 0.9.0
• Используется API: QEMU 0.9.0
• Выполняется гипервизор: QEMU 0.14.0

А вторая — пустой список виртуальных машин. Стоит попробовать запустить virsh без аргумента ‘–connect’ (sudo virsh version), чтобы libvirt попыталась сама найти предпочтительную систему виртуализации. Если вывод будет совпадать, в дальнейшем можно не утруждать себя указанием опции ‘–connect’. Сразу скажу что libvirt позволяет управлять системой виртулизации удаленной стороны с помощью SSH-туннеля. Делается это примерно так (здесь опция ‘-c’ — это сокращение ‘–connect’):

$ virsh -c \
qemu+ssh://root@host.com/system команда

Все приведенные далее команды могут быть выполнены таким же образом. Более того, «команду» можно вообще не указывать, тогда откроется шелл virsh. Он хорош, в частности, тем, что поддерживает автодополнение команд и имеет встроенную справку.

Для создания первой виртуальной машины запустим virt-install следующим образом:

$ sudo virt-install --connect qemu:///system \
--name vm1 \
--ram 512 \
--vnc \
--os-type linux
--os-variant ubuntumaverick \
--accelerate \
--network=network:default \
--disk \
path=/var/lib/libvirt/images/vm1.img,size=5 \
--cdrom /tmp/ubuntu-10.10-server-i386.iso \
--noautoconsole

Команда сгенерирует образ новой виртуальной машины и запустит его с помощью эмулятора QEMU. Машина будет иметь имя vm1 (опция ‘–name’), 512 Мб памяти (‘–ram’), вывод ее дисплея будет транслироваться по сети с помощью VNC-сервера (позже мы рассмотрим, как к нему подключиться). Конфигурация виртуальной машины будет подобрана в расчете на оптимальную работу операционной системы Linux (‘–os-type linux’) и конкретно дистрибутива Ubuntu 10.10 (‘–os-variant ubuntumaverick’), по возможности будут задействованы средства аппаратной виртуализации (‘–accelerate’).

Опция ‘––network’ предназначена для указания способа подключения виртуального окружения к сети. Всего существует три возможных варианта этой опции:

1. bridge:имя_моста — подключение к внешней сети через виртуальный сетевой мост. Виртуальная машина сможет принимать и инициировать соединения. Это идеальный вариант, но он требует дополнительной настройки.

2. network:имя_сети — подключение к внутренней виртуальной сети. Машина будет помещена в изолированную виртуальную сеть, но сможет получить доступ к внешней сети, используя NAT. Совершенно неприемлемый с практической точки зрения вариант, который удобен тем, что не требует какой-либо настройки. Опция «имя_сети» должна совпадать с именем файла в каталоге /var/lib/ libvirt/network, плюс расширение «xml».

Список имеющихся сетей можно получить, используя следующую команду:

# virsh net-list --all

3. user — подключение к сети, используя SLIRP. Удобен только в тех случаях, когда гостевая система должна быть запущена от имени непривилегированного пользователя.

С помощью опции ‘–disk’ мы заставляем libvirt создать новый образ диска, указывая путь до файла и его размер. Если бы мы хотели использовать уже существующий образ диска, то могли бы просто опустить опцию ‘size’. Из других опций внимания заслуживает ‘sparse’, с помощью которой можно указать, должен ли образ быть динамически расширяемым (sparse=true, по умолчанию) или иметь фиксированный размер (sparse=false).

В первом случае образ будет расти по мере его наполнения, но только до тех пор, пока его размер не достигнет указанного в опции ‘size’. Во втором случае образ сразу будет иметь запрошенный размер. Это предпочтительный вариант для боевых серверов, так как, во-первых, на динамическое расширение тратятся ресурсы системы, а во-вторых, постоянный рост дисков может привести к израсходованию ресурсов в самый неподходящий момент.

Также рекомендую сразу позаботиться о переносе каталога /var/ lib/libvirt/images на LVM-том или другой сервер (с помощью NFS или POHMELFS, например). Так ты решишь многие проблемы, которые могут возникнуть в будущем.

С помощью опции ‘–cdrom’ мы указали путь к установочному ISO-образу. Это плохой пример, потому как хранить установочные образы в каталоге /tmp боевого сервера опрометчиво. Гораздо удобнее использовать для этой цели другую машину, просто указав ее адрес и каталог с предпочтительным ISO-образом:

--cdrom ftp://host.com/images/ubuntu/

А еще лучше указать адрес, содержащий образы ядра и initrd, которые произведут сетевую установку дистрибутива из официальных источников:

--location http://ftp.us.debian.org/debian/dists/etch/main/installer-amd64/

Но это, как говорится, в какой конфигурации что удобнее. По следняя опция (‘–noautoconsole’) отключает автоматическое открытие консоли сразу после создания виртуальной машины. Также доступны опции ‘––vcpus’ и ‘––cpuset’, которые позволяют управлять количеством ядер процессора внутри виртуальной машины и количеством доступных ей ядер физической машины (через запятую, начиная с нуля).

Команда создаст описание виртуальной машины, поместит его в файл /etc/libvirt/qemu/vm1.xml и запустит виртуальную машину. Проверить ее работоспособность можно с помощью уже упоминавшейся ранее команды ‘virsh list’. Сам файл описания можно открыть в текстовом редакторе, чтобы просмотреть или изменить. Он имеет вполне читаемый и логичный формат.

Если виртуальная машина запустилась, к ней можно подключиться с помощью инструмента virt-viewer, который можно найти в одноименном пакете:

$ sudo apt-get install
$ virt-viewer -c qemu:///system test

Естественно, запускать virt-install лучше с удаленной машины. Если все пошло хорошо, должно открыться окно, содержащее экран виртуальной машины и, соответственно, инсталлятор выбранной ОС.

После окончания установки виртуальная машина будет полностью готова к использованию, в нее можно будет войти с помощью команды ‘console vm1′, запросить информацию с помощью команды ‘dominfo vm1′, добавить в список авто-запуска (который происходит во время запуска демона libvirtd) командой ‘autostart vm1′, заморозить (команда ‘save’), разморозить (‘resume ‘), завершить (‘shutdown’), запустить (‘start’), уничтожить (‘destroy’), добавить или удалить сетевые интерфейсы (‘attach-device’), добавить новые диски и многое другое, но самое главное — теперь виртуальную машину можно клонировать:

$ sudo virt-clone \
--connect=qemu:///system -o vm1 -n vm2

В результате будет создана новая виртуальная машина vm2, конфигурация которой будет полностью повторять конфигурацию vm1, но жесткий диск у нее будет свой. С помощью ‘virt-clone’ можно создать столько виртуальных машин, сколько нужно, в полностью автоматическом режиме. Если же одной физической машины будет недостаточно для обслуживания всех имеющихся ВМ, можно поднять новый libvirt-сервер и переселить особо прожорливых на него:

$ sudo virsh migrate --live vm136 \
qemu+ssh://host2.com/system

Не забыв проверить результат:

$ sudo virsh qemu+ssh://host2.com/system list

С помощью virsh управлять виртуальными серверами просто и удобно, но для людей, привыкших к GUI и web-системам, такой интерфейс может показаться слишком ограниченным и не наглядным. Поэтому существует инструмент под названием virt-manager, который позволяет делать почти все то же самое с помощью удобного графического интерфейса.

virt-manager

Программа virt-manager (virt-manager.org) развивается в рамках проекта, который включает в себя не только саму программу, но и описанные выше инструменты virt-install, virt-clone и virt-viewer.

Более того, весь проект находится под покровительством компании Red Hat, которая и была инициатором рождения библиотеки libvirt. Поэтому, если говорить о каком-либо стандарте, то им можно считать именно этот набор инструментов.

С практической точки зрения virt-manager представляет собой простую (на вид) графическую программу, в верхней части которой находятся инструменты управления виртуальными машинами, а в нижней — список доступных эмуляторов (гипервизоров, в нашем случае там должен быть только QEMU) и виртуальных машин.

Для создания новой виртуальной машины достаточно нажать кнопку «Новая», дать название машине, выбрать вариант установки, установочный образ, указать тип ОС и ее версию, указать количество ОЗУ и ядер процессора. Все то же самое, что и при использовании утилиты virt-install. Поставив галочку напротив пункта «Настроить конфигурацию перед установкой» можно сделать более конкретную настройку машины, включая выбор эмулируемых устройств и возможностей эмулятора, подключить дополнительные диски, произвести подстройку под ОС (например, отключить ACPI для NetBSD) и сделать многое другое.

После этого в списке виртуальных машин появится новая ВМ. С помощью правого клика мышью виртуальную машину легко клонировать, перенести на другую машину, приостановить или выключить. Рабочий стол машины в любой момент доступен с помощью кнопки «Открыть» в верней панели инструментов.

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

С помощью пункта «Добавить соединение» в меню «Файл» можно создать подключение к другому гипервизору (хоть удаленному, хоть локальному) и все его виртуальные машины будут отображены в общем списке.

Другие инструменты

Набор доступных инструментов управления виртуальными машинами не ограничивается только перечисленными выше программами. На странице libvirt.org/apps.html перечислены приложения, способные использовать libvirt в своей работе. Настоящих жемчужин среди них немного, но они есть:

• virt-top (people.redhat.com/~rjones/virt-top) — TOP-подобная утилита для отображения списка самых «прожорливых» виртуальных машин. Поддерживает почти все опции командной строки оригинального top.
• virt-df (people.redhat.com/~rjones/virt-df) — аналог команды df, показывающий процент занятости пространства на виртуальных жестких дисках.
• virt-p2v (people.redhat.com/~rjones/virt-p2v) — инструмент для преобразования физических машин в виртуальные и обратно.
• virt-v2v (git.fedorahosted.org/git/?p=virt-v2v.git;a=summary) — программа для конвертирования образов, созданных другими системами виртуализации, в формат qemu-kvm.

Web-ориентированные системы управления

Среди Web-ориентированных интерфейсов можно выделить японский Karesansui, который совсем недавно обновился до версии 2.0. Внешне он представляет собой довольно привлекательный на вид Web2.0-интерфейс управления ВМ, поддерживающий массу возможностей и вполне способный заменить собой virt-manager.
Кроме всего прочего, он поддерживает сбор статистики и мониторинг, а также способен выводить на Web-страницу содержимое экрана гостевой ОС.

Внутри Karesansui представляет собой Python-приложение с SQLite в качестве базы данных и Java-плагином tightVNC-java, используемым для вывода изображения, передаваемого с VNCсервера libvirtd. Для построения интерактивного web-интерфейса используется библиотека jQuery.

Кроме того, я бы очень рекомендовал присмотреться к системе под названием Archipel (archipelproject.org), которая представляет собой Jabber-сервис, позволяющий рулить виртуальными окружениями буквально с помощью приказов, отдаваемых через IM-клиент, и, что самое главное, получать от них ответы и отчеты о состоянии и сбоях.

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

Кроме того, полнофункциональные браузеры, нужные для получения доступа к полноценным системам управления виртуальными машинами, доступны далеко не везде и не всегда, а простейший Jabber-клиент будет работать даже на бюджетном телефоне 2000 года выпуска и позволит получить управление над виртуальным сервером даже в той ситуации, в которой все остальные инструменты окажутся недоступны.

Кроме интерфейса, основанного на протоколе XMPP, Archipel может предложить админам и классический Web-интерфейс, который можно использовать тогда, когда под рукой есть нормальный браузер. Возможности этого интерфейса довольно широки и ничуть не уступают описанному выше Karesansui. Их официальный список выглядит так:

• Визуализация состояния и нагрузки на сервер в режиме реального времени;
• Возможность отправки любых команд Archipel;
• Возможность обмена сообщениями с другими пользователями системы;
• Механизм посылки сообщений сразу группе серверов или гипервизоров;
• Безопасность подключения, обеспечиваемая механизмами XMPP S2S.

Многие системы обслуживания облачной инфраструктуры основаны на libvirt. Это, в частности, совместимые с Amazon EC2 системы Eucalyptus (open.eucalyptus.com) и OpenStack (openstack.org), система для быстрого развертывания облачной инфраструктуры OpenNode (opennode.activesys.org) и основанная на технологиях Adobe Flex и Sun/Oracle Java система AbiCloud (community.abiquo.com).

Выводы

За последние годы Linux сделал большой шаг вперед во всем, что так или иначе связано с виртуализацией. QEMU и KVM, которые еще несколько лет назад казались игрушкой для гиков и не воспринимались серьезно, теперь правят балом.

Настройка сетевого моста в Ubuntu

1. Открываем файл /etc/network/interfaces, удаляем текущее содержимое и добавляем следующие строки (указав правильные IP-адреса, маску и так далее):

auto lo
iface lo inet loopback
auto br0
iface br0 inet static
address 192.168.0.10
network 192.168.0.0
netmask 255.255.255.0
broadcast 192.168.0.255
gateway 192.168.0.1
bridge_ports eth0
bridge_fd 9
bridge_hello 2
bridge_maxage 12
bridge_stp off

2. Перезапускаем сеть:

$ sudo /etc/init.d/networking restart

3. Останавливаем и отключаем dhcdbd:

$ sudo /etc/init.d/dhcdbd stop
$ sudo update-rc.d -f dhcdbd remove

Отладка virt-install

Утилита virt-install не всегда работает безупречно. Чтобы разобраться, почему происходит ошибка запуска, используй флаг ‘-d’, который принудит утилиту записывать всю отладочную информацию в файл ~/.virtinst/virt-install.log.

Отключение ACPI

Далеко не каждая операционная система может нормально работать с подсистемой ACPI, реализованной в QEMU. Чтобы отключить ее, просто передай опцию ‘–noacpi’ или ‘–noapic’ (лучше обе) команде virt-install.

Info

• В любой момент к виртуальной машине можно подключить новый диск:

sudo virsh attach-disk
--driver fi le --type
cdrom --mode readonly
/var/lib/libvirt/images/cdrom.iso sdc

• Конфиг существующей виртуальной машины легко просмотреть и исправить:

# virsh dumpxml vm1 >
~/vm1.xml
# vi vm1.xml
# virsh create vm1.xml

CentOS настройка сети

Работаю с разными линухами поэтому все не упомнишь, в общем решил записать как настроить сеть на CentOS

Настройки сетевых интерфейсов в CentOS находятся в:

1	/etc/sysconfig/network-scripts/ifcfg-ethХ

— где X номер вашего интерфеса

Вот пример настройки сети в CentOS:

1	cat /etc/sysconfig/network-scripts/ifcfg-eth0

1 2 3 4 5 6 7 8 9 10 11

DEVICE=eth0 BOOTPROTO=static DHCPCLASS= HWADDR=00:00:17:EA:18:99 ONBOOT=yes TYPE=Ethernet IPADDR=192.168.0.25 NETMASK=255.255.255.0 BROADCAST=192.168.0.255 NETWORK=192.168.0.0 NOZEROCONF=yes

Сеть мы настроили, не хватает только шлюза и dns серверов.
Шлюз в CentOS можно добавить выполнив в консоли следующую команду:

1	route add default gw 192.168.0.1

— где 192.168.0.1 и есть шлюз

Но это до первой перезагрузки 
Что бы шлюз в CentOS и после перезагрузки не сбрасывался, добавляем в файл:

1	/etc/sysconfig/network

следующую строчку:

1	GATEWAY=192.168.0.1

— где 192.168.0.1 наш шлюз

После этого наша сеть в CentOS полностью настроена. Ах, да, нужно же еще днс сервера прописать. Делается это как и в любой nix системе:

1 2 3

cat /etc/resolv.conf nameserver 127.0.0.1 nameserver 192.168.0.1

Ну все, вот теперь точно все будет работать. На этом настройка сети в CentOSзаканчивается.