Настройка port forwarding в Cisco

Задачей будет настроить трансляцию с внешних адресов 200.100.50.56, 200.100.50.57 на адреса 192.168.1.1 — ftp сервис, 192.168.1.2 — веб сервис, 172.18.9.202 — все порты с адреса 200.100.50.57.

Схема подключения наших серверов:

Для проброса портов в Cisco PIX / ASA добавим в конфигурацию NAT-трансляцию:

FTP

static (inside,outside) tcp 200.100.50.56 ftp-data 192.168.1.1 ftp-data netmask 255.255.255.255
static (inside,outside) tcp 200.100.50.56 ftp 192.168.1.1 ftp netmask 255.255.255.255

WEB

static (inside,outside) tcp 200.100.50.56 www 192.168.1.2 www netmask 255.255.255.255 

Пробросим все порты на адрес в DMZ-зоне

static (dmz,outside) 200.100.50.57 172.18.9.202 netmask 255.255.255.255
static (dmz,inside) 200.100.50.57 172.18.9.202 netmask 255.255.255.255 

Тоже самое в IOS будет выглядеть примерно так:

ip nat inside source static tcp 192.168.1.1 21 200.100.50.56 21
ip nat inside source static tcp 192.168.1.2 80 200.100.50.56 80
ip nat inside source static tcp 172.18.9.202 200.100.50.57 extendable

Источник: http://sysadminblog.ru/cisco/2010/05/25/nastroyka-probrosa-portov-port-forwarding-v-cisco-2.html

Разные варианты NAT на Cisco ASA

* One-to-One (aka two-way) NAT (ASA 5510, ASAOS 7.2.1)

The syntax for this can be confusing. Here is a generic example:
static (outside interface name, inside interface name) inside ip, outside ip netmask 255.255.255.255

static (internet,office) 192.168.77.101 216.142.200.221 netmask 255.255.255.255
static (internet,office) 192.168.77.102 216.142.200.222 netmask 255.255.255.255
static (internet,office) 192.168.77.103 216.142.200.223 netmask 255.255.255.255
static (test,office) 192.168.77.104 172.30.11.14 netmask 255.255.255.255
static (test,office) 192.168.77.105 172.30.11.15 netmask 255.255.255.255

* Simple Many-to-One (aka one-way) NAT (ASA 5510, ASAOS 7.2.1)

global (outside) 1 216.142.200.220 netmask 255.255.255.255
nat (inside) 1 192.168.77.0 255.255.255.0 0 0

* Complex Many-to-One (aka one-way) NAT (ASA 5510, ASAOS 7.2.1)

access-list skip-nat-inside permit ip any host 192.168.6.11
access-list skip-nat-inside permit ip any host 192.168.6.12
access-list skip-nat-inside permit ip any 192.168.222.0 255.255.255.0

global (outside) 1 216.142.200.220 netmask 255.255.255.255
global (outside) 2 216.142.200.221 netmask 255.255.255.255
nat (inside) 0 access-list skip-nat-inside
nat (inside) 1 10.1.1.0 255.255.255.0 0 0
nat (inside) 1 172.66.3.0 255.255.255.0 0 0
nat (inside) 1 192.168.5.0 255.255.255.0 0 0
nat (inside) 2 192.168.77.0 255.255.255.0 0 0

Решение проблем при размещении Cisco 7942G за NAT’ом

Весьма проблематично заставить работать телефон Cisco 7942 или Cisco 7962, если он находится за NAT-ом. Телефон не может выполнить регистрацию, а без этого не получится ни звонить, ни принимать звонки.

Проблема вызвана некоторыми особенностями в реализации SIP-стека на телефонах, которые интеграторы телефонии на Asterisk называют багами, а сами Cisco-разработчики называют фичей. Речь идет о инициирующих SIP-портах, которые начинаются с 49000.

При подключении из-за NAT, сервер Asterisk считает пир nat=yes устройством, из-за чего использует симметричный SIP/RTP и шлет ответы ровно на тот порт, с которого пришло соединение. Но на деле сама Cisco 7942 ждет ответа не на порту отправления, а на порту 5060, а точнее, на порту, указанном в <voipControlPort>. Из-за различия портов связь установить не удается, а сама Cisco 7942 упорно отвечает сообщениями типа ICMP Port Unreachable.

Решение проблемы:

1. (Опционально) Указать в теге <voipControlPort> порт, отличный от 5060. Например, 5091. Это связано с тем. что в дальнейшем мы этот порт будем пробрасывать на роутере.

2. Закрепить Cisco 7942 на статическом IP-адресе, либо присвоить статическую аренду на DHCP-сервере.

3. Прописать секцию
<natEnabled>false</natEnabled>
<natAddress></natAddress>

4. На сервере Asterisk в настройках экстеншена прописать опцию nat=no

5. На роутере, который пускает телефон в Интернет, прописать статический проброс UDP порта, который у вас указан в <voipControlPort> на внутренний IP телефона Cisco 7942G. Как правило, эта секция в веб-интерфейсе роутера называется «Virtual Server» или «NAT 1:1».

6. Перезагрузить телефон нажатием Settings-> **#**.
Убедиться, что телефон работает. Если чуда не случилось, то поможет разобраться в проблеме tcpdump. Возможно, будет иметь смысл игра с опиями nat=no и nat=never

* — Надо заметить, что IP может быть и динамическим. В этом случае нужно будет настроить роутер так, чтобы он обновлял динамическую DNS-запись, например, на сервисе DynDNS. Тогда в это поле вписывается FQDN-запись вида <natAddress>somename.dyndns.org</natAddress>. При этом нужно учитывать, что телефон резолвит это имя в IP всего один раз, при старте телефона. Если внешний IP изменится, телефон об этом не узнает, из-за чего будут наблюдаться проблемы односторонней слышимости или отсутствия регистрации.

 

Восстановление IP-фона Cisco 7942G

Cisco 7942G мне подарили товарищи по работе, за что им огромное спасибо и уважение! Угораздило же меня прошивать телефон на SIP-прошивку именно в тот момент, как скакнуло напряжение в офисе.. 8(( Телефон сдох.

После различных попыток восстановления телефона, он замолчал и уже не подавал никаких признаков жизни — на экране по появлялось никаких сообщений. Ни по команде 123456789*0#, ни по 3491672850*# восстановить телефон, с помощью местного TFTP-сервера и прошивок на нем, не удалось. (((

Пришлось менять стратегию.

Был запущен отдельный TFTP-сервер на DHCP с раздачей файла по протоколу BOOTP на Debian 5.0.6. Использовалось редкое в России устройство Synertron CV860A, с процессором VIA C3:

  • CPU VIA Eden/C3 376 PIN 1GHz,
  • PLE133 chipset, PC133 SDRAM memory,
  • 3x LANs, 2x Serial ports, 3x USB ports,
  • 50-pin bootable Compact Flash Disk Socket,
  • 1x DOC,
  • 1x 44-pin IDE,
  • and 1x 40-pin IDE.

 

Крайние правые порты (по порядку): eth0 и eth2.

Решение нашел благодаря статье на официальном сайте — http://www.cisco.com/en/US/ts/fn/620/fn62949.html

Вот содержание статьи:

Workaround:

Cisco recommends that customers stage their Cisco Unified IP Phones before deploying them to users. This allows Network Administrators to ensure:

— Each phone is upgraded to appropriate firmware releases.

— Properly configure the phone prior to deploying each phone

— The phone is assembled with the appropriate cables, handsets and optional headsets.

While staging the Network Administrator can perform additional activities such as factory resets, apply Dial Numbers and spot check phone functions.

Solution:

Cisco recommends the use of Firmware release 8.2(2)SR1 or later releases. This release and later versions are free of this defect. Registered users may obtain this release from the Cisco Unified IP Phone Firmware downloads (registered customers only) page. Select the proper load for your model of IP Phone.

Recovery of the IP Phone:

  1. Make sure your phones are on a network with a valid DHCP server.
  2. Make sure the DHCP server on this network has a valid Option 150 setting pointing to a valid Cisco TFTP server.
  3. Make sure you have a valid term11.default.loads file from load 8.2(2)SR1 or higher on the TFTP server that is referenced in Option 150.
  4. Make sure you have all other needed image files present on this same TFTP server. * See note below.
  5. Change the timing on the network — the problem is related to timing. Toggle switch port settings between «Auto» and «100Mbps.» On a Cisco switch the command to toggle the switch port switch:
    interface range fastethernet
    set speed 100
    set duplex full
    

    Wait 10 minutes, or until all the phones have been updated, then issue the following command if desired to return to original configuration:

    interface range fastethernet
    set speed auto
    set duplex auto
    

    Ensure that items 1 through 5 have been completed. If performing these five steps does not resolve the issue, continue with the remaining steps.

  6. Pull power on the phone (even if power is PoE).
  7. Hold down the # key on the phone.
  8. Continue holding down the # key and re-apply power.
  9. While still holding the # key wait for the Message Waiting Indicator (MWI) light on the handset to start flashing.
  10. Once the MWI light is flashing, release the # key and enter the following sequence exactly on the keypad:3491672850*#Once this sequence has been entered on the IP Phone, if all the network criteria above have been met, it should begin its recovery process. This process can take up to 15 minutes to finish. The phone may appear to be doing nothing during this time. However, if the phone does not recover after 20 minutes then it is possible that the recovery is stuck. In this case, re-examine your network and verify that steps 1-4 are in place, then re-issue the factory reset sequence.

* Note: The factory reset sequence is a way for a phone to clear flash and still upload to a valid firmware image. This is facilitated by the termxx.default.loads file, but requires that the image files listed in the termxx.default.loads file are available in TFTP for the phone to download. Open the termxx.default.loads file in any text editor. This loads file is essentially just a packing list showing all the OS and application files the phone needs to function. The files include a cnu, cvm, dsp, app and jar files. Please make sure that these files as listed in the termxx.default.loads file are in TFTP. («xx» will be either «06» for the CP-7906G model, or «11» for the CP-7911G model.)

Additional Diagnostic Steps:

— Try a hard-coded IP address as a test to see if this resolves the upgrade failures. If it does, and the number of failing IP Phones is relatively few, this procedure may be the most expedient. After the IP Phone upgrades successfully, reconfigure the IP Phone to use DHCP.

— Try putting the phone on a hub or a different switch and see if this helps change the startup timing enough so that the upgrade completes successfully.

***

Основная проблема возникла в пунктах 1-4, — не сразу удалось подобрать подходящую конфигурацию и заставить ее работать, ниже описываю положительный опыт создания такой конфигурации.

Первоначально пытался прописать DHCP option 150 на сервере Windows 2003 Server (позже подготовлю статью по этой теме), однако сразу не завелось, потому перешел на Debian.

IP-фон с помощью порта 10/100SW был подключен к свитчу, свитч подключен к серверу в порт eth0 (192.168.100.0/24), порт eth2 сервера (192.168.0.0/24) через еще один роутер, был подключен к интернету.

Итак, после установки операционной системы, был установлен TFTP-сервер:

apt-get install tftpd-hpa tftp-hpa
mcedit /etc/inetd.conf
#:BOOT: TFTP service is provided primarily for booting.  Most sites
#       run this only on machines acting as "boot servers."
tftp           dgram   udp     wait    root  /usr/sbin/in.tftpd /usr/sbin/in.tftpd -s /var/lib/tftpboot
invoke-rc.d openbsd-inetd restart
chmod 777 /var/lib/tftpboot
echo TEST > /var/lib/tftpboot/test0
echo get test0 | tftp 127.0.0.1

Устанавливаем DHCP-сервер:

apt-get install dhcp3-server
mcedit /etc/dhcp3/dhcpd.conf

ddns-update-style none;

option option-150 code 150 = ip-address;

default-lease-time 3600;
max-lease-time 7200;

# eth2
subnet 192.168.0.0 netmask 255.255.255.0 {
}

# eth0
subnet 192.168.100.0 netmask 255.255.255.0 {
    range dynamic-bootp 192.168.100.2 192.168.100.99;
    option subnet-mask 255.255.255.0;
    option broadcast-address 192.168.100.255;
    option domain-name-servers 8.8.8.8, 8.8.4.4;
    option routers 192.168.100.1;
    option option-150 192.168.100.1;
}

host cisco7942 {
    hardware ethernet b8:be:bf:22:be:05;
#    filename "SEPB8BEBF22BE05.cnf.xml";
    filename "term42.default.loads";
}

log-facility local7;

 

Настройки DHCP-клиента:

option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;

send host-name "dhcp-server";
send dhcp-client-identifier 00:40:48:b1:7c:59;
send dhcp-lease-time 3600;

request subnet-mask, broadcast-address, time-offset, routers,
	domain-name, domain-name-servers, domain-search, host-name,
	netbios-name-servers, netbios-scope, interface-mtu,
	rfc3442-classless-static-routes;

timeout 360;

Файл /etc/defaults/dhcp3-server:

INTERFACES="eth0"

Настройки сети:

auto lo
iface lo inet loopback

iface eth0 inet static
	address 192.168.100.1
	netmask 255.255.255.0
	network 192.168.100.0
	broadcast 192.168.100.255
auto eth0

allow-hotplug eth2
iface eth2 inet static
	address 192.168.0.53
	netmask 255.255.255.0
	network 192.168.0.0
	broadcast 192.168.0.255
	gateway 192.168.0.1
	dns-nameservers 192.168.0.1
auto eth2

Перезапуск сетевых настроек:

/etc/init.d/networking restart

Перезапуск DHCP-сервера:

/etc/init.d/dhcp3-server restart

Для пропуска трафика из подсети 192.168.0.0 в сеть 192.168.100.0, настраиваем NAT на IPtables, делаем скрипт ~/fw.start:

#!/bin/sh

INET="eth2"
INETIP="192.168.0.53"

iptables -F INPUT
iptables -F FORWARD
iptables -F OUTPUT

iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

iptables -t nat -A POSTROUTING -o $INET -j SNAT --to-source $INETIP

echo "1" > /proc/sys/net/ipv4/ip_forward

И запускаем его:

sh ~/fw.start

После этого трафик из сети 192.168.0.0 будет доступен и в 192.168.100.0.

Результаты работы проверяю с помощью tshark:

apt-get install tshark
tshark -i eth0

После всех манипуляций перезагружаем IP-фон, как описано в статье в пункте 10:

1. Зажимаем #.
2. Отключаем питание.
3. После того, как начинают мигать кнопки Line отжимаем #.
4. Набираем комбинацию 3491672850*# и ждем, пока с TFTP-сервера пойдет трафик в телефон.

На TFTP-сервере были размещены файлы одной из ранних прошивок:

# ls /var/lib/tftpboot/

apps42.8-5-2TH1-9.sbn
cnu42.8-5-2TH1-9.sbn
cvm42sip.8-5-2TH1-9.sbn
dsp42.8-5-2TH1-9.sbn
jar42sip.8-5-2TH1-9.sbn
SIP42.8-5-2S.loads
term42.default.loads
term62.default.loads
dialplan.xml
CTLSEPB8BEBF22BE05.tlv
SEPB8BEBF22BE05.cnf.xml
XMLDefault.cnf.xml

dialplan.xml:

<DIALTEMPLATE>
  <TEMPLATE MATCH="*" Timeout="3"/>
</DIALTEMPLATE>

SEPB8BEBF22BE05.cnf.xml (конфиг-файл от более поздней прошивки):

<device>
    <fullConfig>true</fullConfig>
    <deviceProtocol>SIP</deviceProtocol>
    <devicePool>
        <dateTimeSetting>
            <dateTemplate>D.M.Y</dateTemplate>
            <timeZone>Ekaterinburg Standard Time</timeZone>
            <ntps>
                <ntp>
                    <name>10.210.0.87</name>
                    <ntpMode>Unicast</ntpMode>
                </ntp>
            </ntps>
        </dateTimeSetting>
        <callManagerGroup>
            <tftpDefault>true</tftpDefault>
                <members>
                <member priority="0">
                <callManager>
                <name>77.243.103.107</name>
                <description>Asterisk</description>
                <ports>
                  <ethernetPhonePort>2000</ethernetPhonePort>
                  <sipPort>5060</sipPort>
                  <securedSipPort>5061</securedSipPort>
                </ports>
                <processNodeName>77.243.103.107</processNodeName>
                </callManager>
                </member>
                </members>
             </callManagerGroup>
    </devicePool>
    <commonProfile>
        <phonePassword></phonePassword>
        <backgroundImageAccess>true</backgroundImageAccess>
        <callLogBlfEnabled>0</callLogBlfEnabled>
    </commonProfile>
    <loadInformation>SIP42.8-5-4S</loadInformation>
    <loadInformation434  model="Cisco 7942">SIP42.8-5-4S</loadInformation434>
    <vendorConfig>
        <disableSpeaker>false</disableSpeaker>
        <disableSpeakerAndHeadset>false</disableSpeakerAndHeadset>
        <pcPort>0</pcPort>
        <settingsAccess>1</settingsAccess>
        <garp>0</garp>
        <voiceVlanAccess>0</voiceVlanAccess>
        <videoCapability>0</videoCapability>
        <autoSelectLineEnable>0</autoSelectLineEnable>
        <daysDisplayNotActive>1,7</daysDisplayNotActive>
        <displayOnTime>10:30</displayOnTime>
        <displayOnDuration>06:05</displayOnDuration>
        <displayIdleTimeout>00:05</displayIdleTimeout>
        <webAccess>1</webAccess>
        <spanToPCPort>1</spanToPCPort>
        <loggingDisplay>1</loggingDisplay>
        <loadServer></loadServer>
    </vendorConfig>

<userLocale>
   <name>Russian_Russian_Federation</name>
   <uid></uid>
   <langCode>ru_RU</langCode>
   <version>8.4.3.1000-1</version>
   <winCharSet>utf-8</winCharSet> </userLocale>
<networkLocale>Russian_Federation</networkLocale>
 <networkLocaleInfo>
   <name>Russian_Federation</name>
   <uid></uid>
   <version>8.4.3.1000-1</version>
 </networkLocaleInfo>
    <deviceSecurityMode>1</deviceSecurityMode>
    <idleTimeout>0</idleTimeout>
    <directoryURL></directoryURL>
     <servicesURL>77.243.103.107</servicesURL>
     <idleURL></idleURL>
    <messagesURL></messagesURL>
    <proxyServerURL></proxyServerURL>
    <dscpForSCCPPhoneConfig>96</dscpForSCCPPhoneConfig>
    <dscpForSCCPPhoneServices>0</dscpForSCCPPhoneServices>
    <dscpForCm2Dvce>96</dscpForCm2Dvce>
    <transportLayerProtocol>2</transportLayerProtocol>
    <capfAuthMode>0</capfAuthMode>
    <capfList>
        <capf>
            <phonePort>3804</phonePort>
        </capf>
    </capfList>
    <certHash></certHash>
    <encrConfig>false</encrConfig>
    <sipProfile>
        <sipProxies>
            <backupProxy>77.243.103.107</backupProxy>
            <backupProxyPort>5060</backupProxyPort>
            <emergencyProxy>77.243.103.107</emergencyProxy>
            <emergencyProxyPort>5060</emergencyProxyPort>
            <outboundProxy>77.243.103.107</outboundProxy>
            <outboundProxyPort>5060</outboundProxyPort>
            <registerWithProxy>true</registerWithProxy>
        </sipProxies>
     <sipCallFeatures>
        <cnfJoinEnabled>true</cnfJoinEnabled>
        <callForwardURI>x--serviceuri-cfwdall</callForwardURI>
        <callPickupURI>x-cisco-serviceuri-pickup</callPickupURI>
        <callPickupListURI>x-cisco-serviceuri-opickup</callPickupListURI>
        <callPickupGroupURI>x-cisco-serviceuri-gpickup</callPickupGroupURI>
        <meetMeServiceURI>x-cisco-serviceuri-meetme</meetMeServiceURI>
        <abbreviatedDialURI>x-cisco-serviceuri-abbrdial</abbreviatedDialURI>
        <rfc2543Hold>false</rfc2543Hold>
        <callHoldRingback>2</callHoldRingback>
        <localCfwdEnable>true</localCfwdEnable>
        <semiAttendedTransfer>true</semiAttendedTransfer>
        <anonymousCallBlock>2</anonymousCallBlock>
        <callerIdBlocking>2</callerIdBlocking>
        <dndControl>0</dndControl>
        <remoteCcEnable>true</remoteCcEnable>
     </sipCallFeatures>
      <sipStack>
        <sipInviteRetx>6</sipInviteRetx>
        <sipRetx>10</sipRetx>
        <timerInviteExpires>180</timerInviteExpires>
        <timerRegisterExpires>3600</timerRegisterExpires>
        <timerRegisterDelta>5</timerRegisterDelta>
        <timerKeepAliveExpires>120</timerKeepAliveExpires>
        <timerSubscribeExpires>120</timerSubscribeExpires>
        <timerSubscribeDelta>5</timerSubscribeDelta>
        <timerT1>500</timerT1>
        <timerT2>4000</timerT2>
        <maxRedirects>70</maxRedirects>
        <remotePartyID>false</remotePartyID>
        <userInfo>None</userInfo>
     </sipStack>
     <autoAnswerTimer>1</autoAnswerTimer>
     <autoAnswerAltBehavior>false</autoAnswerAltBehavior>
     <autoAnswerOverride>true</autoAnswerOverride>
     <transferOnhookEnabled>false</transferOnhookEnabled>
     <enableVad>false</enableVad>
         <preferredCodec>g711alaw</preferredCodec>
       <dtmfAvtPayload>101</dtmfAvtPayload>
       <dtmfDbLevel>3</dtmfDbLevel>
       <dtmfOutofBand>avt</dtmfOutofBand>
        <alwaysUsePrimeLine>false</alwaysUsePrimeLine>
        <alwaysUsePrimeLineVoiceMail>false</alwaysUsePrimeLineVoiceMail>
        <kpml>3</kpml>
        <stutterMsgWaiting>1</stutterMsgWaiting>
        <callStats>true</callStats>
        <silentPeriodBetweenCallWaitingBursts>10</silentPeriodBetweenCallWaitingBursts>
        <disableLocalSpeedDialConfig>true</disableLocalSpeedDialConfig>
        <startMediaPort>10100</startMediaPort>
        <stopMediaPort>10300</stopMediaPort>
        <voipControlPort>5060</voipControlPort>
        <dscpForAudio>184</dscpForAudio>
        <ringSettingBusyStationPolicy>0</ringSettingBusyStationPolicy>
        <dialTemplate>dialplan.xml</dialTemplate>
         <phoneLabel>Cisco</phoneLabel>
          <natReceivedProcessing>false</natReceivedProcessing>
          <natEnabled>false</natEnabled>
          <natAddress></natAddress>
        <sipLines>
          <line button="1">
            <featureID>9</featureID>
            <featureLabel>672 L1</featureLabel>
            <proxy>77.243.103.107</proxy>
            <port>5060</port>
            <name>672</name>
            <displayName>672</displayName>
            <autoAnswer>
              <autoAnswerEnabled>2</autoAnswerEnabled>
            </autoAnswer>
            <callWaiting>3</callWaiting>
            <authName>672</authName>
            <authPassword>************</authPassword>
            <sharedLine>false</sharedLine>
            <messageWaitingLampPolicy>3</messageWaitingLampPolicy>
            <messagesNumber></messagesNumber>
            <ringSettingIdle>4</ringSettingIdle>
            <ringSettingActive>5</ringSettingActive>
            <contact>$ACCOUNT</contact>
            <forwardCallInfoDisplay>
              <callerName>true</callerName>
              <callerNumber>false</callerNumber>
              <redirectedNumber>false</redirectedNumber>
              <dialedNumber>true</dialedNumber>
            </forwardCallInfoDisplay>
          </line>
          <line button="2">
          <featureID></featureID>
          <featureLabel></featureLabel>
          <speedDialNumber></speedDialNumber>
          </line>
        </sipLines>
    </sipProfile>
</device>

XMLDefault.cnf.xml:

<Default>
    <callManagerGroup>
        <members>
            <member  priority="0">
                <callManager>
                    <ports>
                        <ethernetPhonePort>2000</ethernetPhonePort>
                    </ports>
                    <processNodeName>192.168.100.113</processNodeName>
                </callManager>
            </member>
        </members>
    </callManagerGroup>

 <loadInformation6  model="IP Phone 7910"></loadInformation6>
    <loadInformation124  model="Addon 7914"></loadInformation124>
    <loadInformation9  model="IP Phone 7935"></loadInformation9>
    <loadInformation8  model="IP Phone 7940"></loadInformation8>
    <loadInformation7  model="IP Phone 7960"></loadInformation7>
    <loadInformation20000  model="IP Phone 7905"></loadInformation20000>
    <loadInformation30008  model="IP Phone 7902"></loadInformation30008>
    <loadInformation30007  model="IP Phone 7912"></loadInformation30007>
   <loadInformation434  model="IP Phone 7942">SIP42.8-5-4S</loadInformation434>
</Default>

и пустой файл: CTLSEPB8BEBF22BE05.tlv

 

🙂

После всего этого, телефон восстановился.

Предстоит еще обновить прошивку с 8.5.2 до минимум 8.5.4 (для благополучно работы Cisco 7942 с Asterisk 1.4.39 у нас в конторе). Но это уже другая история.

 

NAT производительность

Решил выяснить сколько трафика сможет занатить один Linux сервер, какая нагрузка будет при этом на CPU.

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

Приведу тестовые данные:

Итак тестовая система:
Однопроцессорный четырехядерный сервер Intel(R) Xeon(R) CPU E5405 2.00GHz
Сетевые адаптеры Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X 64-bit 133MHz
ОС CentOS 5.4

Правила для iptables простые /etc/sysconfig/iptables


*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT DROP [0:0]

COMMIT

*nat

-A POSTROUTING -o eth0 -s 172.16.1.0/24 -j SNAT --to 192.168.0.1
-A POSTROUTING -o eth0 -s 172.16.2.0/24 -j SNAT --to 192.168.0.2
-A POSTROUTING -o eth0 -s 172.16.3.0/24 -j SNAT --to 192.168.0.3
--//--
-A POSTROUTING -o eth0 -s 172.16.254.0/24 -j SNAT --to 192.168.0.254

COMMIT

Пропустим через сервер трафик порядка 100 мегабит:

Входящий 90-100 мбит/с
Исходящий 50-60 мбит/с

Посмотрим количество пакетов:

vnstat -tr 15 -i eth0
409452 packets sampled in 15 seconds
Traffic average for eth0

rx 11291.52 kB/s 14072 packets/s
tx 5771.39 kB/s 13223 packets/s

Нагрузка на процессоры:

Cpu0 : 0.0%us, 0.0%sy, 0.0%ni, 91.0%id, 0.0%wa, 1.7%hi, 7.3%si, 0.0%st
Cpu1 : 0.0%us, 0.0%sy, 0.0%ni, 88.3%id, 0.0%wa, 3.7%hi, 8.0%si, 0.0%st

Количество соединений:

sysctl -a | grep ip_conntrack_count
net.ipv4.netfilter.ip_conntrack_count = 65405

Как видим нагрузка на каждый из процессоров всего в районе 7-8 процентов.

Увеличим трафик проходящий через сервер трафик до 200 мбит/с посмотрим как изменится картина

Трафик на обоих сетевых интерфейсах:
Входящий 200-230 мбит/с
Исходящий 130-150 мбит/с


vnstat -tr 15 -i eth0
873819 packets sampled in 15 seconds
Traffic average for eth0

rx 22922.61 kB/s 29719 packets/s
tx 14199.36 kB/s 28535 packets/s

Нагрузка на CPU

Cpu0 : 0.0%us, 0.0%sy, 0.0%ni, 68.0%id, 0.0%wa, 2.3%hi, 29.7%si, 0.0%st
Cpu1 : 0.0%us, 0.0%sy, 0.0%ni, 60.0%id, 0.0%wa, 4.7%hi, 35.0%si, 0.0%st

Увеличим трафик проходящий через сервер трафик до 350 мбит/с посмотрим как изменится картина

Трафик на обоих сетевых интерфейсах:
Входящий 350-370 мбит/с
Исходящий 190-210 мбит/с


vnstat -tr 15 -i eth0
1475987 packets sampled in 15 seconds
Traffic average for eth0

rx 37181.86 kB/s 49891 packets/s
tx 20991.49 kB/s 48507 packets/s

Нагрузка на CPU

Cpu0 : 0.0%us, 0.0%sy, 0.0%ni, 37.9%id, 0.0%wa, 1.7%hi, 60.5%si, 0.0%st
Cpu1 : 0.0%us, 0.0%sy, 0.0%ni, 19.5%id, 0.0%wa, 5.3%hi, 75.2%si, 0.0%st

Количество сетевых соединений

sysctl -a | grep ip_conntrack_count
net.ipv4.netfilter.ip_conntrack_count = 215402

Ну вот в принципе и все, как видим, даже обычный сервер в состоянии «заNATить» порядка 400 мегабит трафика.

Пример подключения локальной сети к Интернет через NAT, с организацией QoS

Меня зовут Педро Ларрой (Pedro Larroy) <piotr%member.fsf.org>. Здесь я расскажу об общих принципах настройки соединения локальной сети, в которой имеется большое число пользователей, к Интернет через маршрутизатор, работающий под управлением Linux. Маршрутизатор имеет реальный IP-адрес и производит Трансляцию Сетевых Адресов (NAT). Я живу в университетском общежитии, где проложена локальная сеть на 198 пользователей. Эта сеть соединена с Интернет через маршрутизатор, который я администрирую. Пользователи очень интенсивно работают в пиринговых сетях, что требует соответствующего управления трафиком. Надеюсь, что этот пример будет интересен читателям lartc.

Прежде всего я опишу процесс настройки своего маршрутизатора шаг за шагом, и в заключение расскажу, как сделать этот процесс автоматическим, выполняющимся в процессе загрузки системы. Сеть, к которой относится этот пример, является локальной (LAN). Она подключена к Интернет через маршрутизатор, который имеет единственный реальный IP-адрес. Разделение единственного реального IP-адреса между всеми пользователями в локальной сети осуществляется с помощью нескольких правил iptables. Для этого необходимо:

Ядро Linux 2.4.18 или выше
На ядро нужно наложить заплату, для поддержки HTB.
iproute
Убедитесь, что tc поддерживает HTB. Скомпилированная версия распространяется вместе с HTB.
iptables

Начнем с оптимизации пропускной способности.

Для начала создадим несколько дисциплин (qdiscs), которые будут обслуживать трафик. Первой создается htb qdisc с 6-ю классами и различными приоритетами. Каждому классу назначена определенная пропускная способность, но при этом они могут задействовать неиспользуемую пропускную способность, если она не занята другими классами. Напомню, что классы с более высоким приоритетом (т.е. с более низким числом prio) будут получать «излишек» канала первыми. Подключение к Интернет осуществляется через модем ADSL, с пропускной способностью для входящего трафика 2 Мбит/сек, исходящего — 300 Кбит/сек. Я ограничиваю исходящую пропускную способность величиной в 240 Кбит/сек по той простой причине, что это максимальное значение, при котором время ожидания отклика остается минимальным. Величина этот параметра может быть определена экспериментально, путем наблюдения за изменением времени отклика при изменении величины пропускной способности.

Для начала, присвойте переменной CEIL величину, составляющую 75% от общей пропускной способности для исходящего трафика. Там, где я использую eth0 — назначьте свой интерфейс, который «смотрит» в Интернет. Сценарий (на языке командной оболочки), выполняющий настройку, начинается со следующих строк:

CEIL=240
tc qdisc add dev eth0 root handle 1: htb default 15
tc class add dev eth0 parent 1: classid 1:1 htb rate ${CEIL}kbit ceil ${CEIL}kbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 80kbit ceil 80kbit prio 0
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 80kbit ceil ${CEIL}kbit prio 1
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 20kbit ceil ${CEIL}kbit prio 2
tc class add dev eth0 parent 1:1 classid 1:13 htb rate 20kbit ceil ${CEIL}kbit prio 2
tc class add dev eth0 parent 1:1 classid 1:14 htb rate 10kbit ceil ${CEIL}kbit prio 3
tc class add dev eth0 parent 1:1 classid 1:15 htb rate 30kbit ceil ${CEIL}kbit prio 3
tc qdisc add dev eth0 parent 1:12 handle 120: sfq perturb 10
tc qdisc add dev eth0 parent 1:13 handle 130: sfq perturb 10
tc qdisc add dev eth0 parent 1:14 handle 140: sfq perturb 10
tc qdisc add dev eth0 parent 1:15 handle 150: sfq perturb 10

Эти строки создают одноярусное дерево HTB:

+---------+
| root 1: |
+---------+
     |
+---------------------------------------+
| class 1:1                             |
+---------------------------------------+
  |      |      |      |      |      |
+----+ +----+ +----+ +----+ +----+ +----+
|1:10| |1:11| |1:12| |1:13| |1:14| |1:15|
+----+ +----+ +----+ +----+ +----+ +----+
classid 1:10 htb rate 80kbit ceil 80kbit prio 0
Это класс с наивысшим приоритетом. Пакеты, попадающие в этот класс, будут иметь самую низкую задержку и получат избыток канала в первую очередь. Сюда будет направляться интерактивный трафик: sshtelnetdnsquake3irc, а так же пакеты с установленным флагом SYN.
classid 1:11 htb rate 80kbit ceil ${CEIL}kbit prio 1
Это первый класс, через который будет проходить довольно объемный трафик. В моем случае — это трафик от локального WEB-сервера и запросы к внешним WEB-серверам, исходящий порт 80 и порт назначения 80, соответственно.
classid 1:12 htb rate 20kbit ceil ${CEIL}kbit prio 2
В этот класс помещаются пакеты, с установленным битом Maximize-Throughput в поле TOS, а так же иной трафик, который генерируется локальными процессами на маршрутизаторе, отправляемый в Интернет. Таким образом, все последующие классы будут иметь дело только с перенаправляемым трафиком.
classid 1:13 htb rate 20kbit ceil ${CEIL}kbit prio 2
Высокоприоритетный класс, обслуживающий объемный трафик, поступающий от компьютеров из локальной сети.
classid 1:14 htb rate 10kbit ceil ${CEIL}kbit prio 3
Этот класс обслуживает почтовый трафик (SMTP,pop3…) и пакеты, с установленным битом Minimize-Cost в поле TOS.
classid 1:15 htb rate 30kbit ceil ${CEIL}kbit prio 3
Последний класс. Он обслуживает прочий трафик, поступающий от компьютеров из локальной сети. Сюда попадает все, что относится к работе в пиринговых сетях, т.е. kazaa, edonkey и пр.

Классификация пакетов.

Мы создали различные классы обработки трафика, но классификация пока отсутствует, поэтому, к настоящему моменту, весь трафик пойдет через класс 1:15 ( который назначен классом по-умолчанию: tc qdisc add dev eth0 root handle 1: htb default 15 ). Теперь самое главное — нужно распределить трафик по имеющимся классам.

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

tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle 1 fw classid 1:10
tc filter add dev eth0 parent 1:0 protocol ip prio 2 handle 2 fw classid 1:11
tc filter add dev eth0 parent 1:0 protocol ip prio 3 handle 3 fw classid 1:12
tc filter add dev eth0 parent 1:0 protocol ip prio 4 handle 4 fw classid 1:13
tc filter add dev eth0 parent 1:0 protocol ip prio 5 handle 5 fw classid 1:14
tc filter add dev eth0 parent 1:0 protocol ip prio 6 handle 6 fw classid 1:15

Здесь задаются соответствия между специфическими значениями FWMARK ( handle x fw ) и классами (classid x:x). Теперь рассмотрим процесс установки меток на пакеты.

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

        +------------+   принятие     +---------+               +-------------+
Вход ---| PREROUTING |--- решения о --| FORWARD |-------+-------| POSTROUTING |- Выход
        +------------+  маршрутизации +---------+       |       +-------------+
                             |                          |
                        +-------+                    +--------+
                        | INPUT |-Локальные процессы-| OUTPUT |
                        +-------+                    +--------+

Далее я буду исходить из предположения, что всем таблицам назначена политика по-умолчанию -P ACCEPT. Наша локальная сеть относится к классу B, с адресами 172.17.0.0/16. Реальный IP-адрес — 212.170.21.172

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

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 172.17.0.0/255.255.0.0 -o eth0 -j SNAT --to-source 212.170.21.172

Проверим, что пакеты уходят через класс 1:15:

tc -s class show dev eth0

Добавим в цепочку PREROUTING, таблицы mangle, правила для установки меток на пакеты:

iptables -t mangle -A PREROUTING -p icmp -j MARK --set-mark 0x1
iptables -t mangle -A PREROUTING -p icmp -j RETURN

Теперь вы должны наблюдать увеличение значения счетчика пакетов в классе 1:10, при попытке ping-ануть из локальной сети какой-нибудь сайт в Интернете.

tc-s класс показывают dev eth0

Действие -j RETURN предотвращает движение пакетов по всем правилам. Поэтому все ICMP-пакеты будут проходить только это правило. Добавим еще ряд правил, которые будут изменять биты в поле TOS:

iptables -t mangle -A PREROUTING -m tos --tos Minimize-Delay -j MARK --set-mark 0x1
iptables -t mangle -A PREROUTING -m tos --tos Minimize-Delay -j RETURN
iptables -t mangle -A PREROUTING -m tos --tos Minimize-Cost -j MARK --set-mark 0x5
iptables -t mangle -A PREROUTING -m tos --tos Minimize-Cost -j RETURN
iptables -t mangle -A PREROUTING -m tos --tos Maximize-Throughput -j MARK --set-mark 0x6
iptables -t mangle -A PREROUTING -m tos --tos Maximize-Throughput -j RETURN

Поднимем приоритет для ssh-пакетов:

iptables -t mangle -A PREROUTING -p tcp -m tcp --sport 22 -j MARK --set-mark 0x1
iptables -t mangle -A PREROUTING -p tcp -m tcp --sport 22 -j RETURN

а так же для пакетов, с которых начинается TCP-соединение, т.е. SYN-пакетов:

iptables -t mangle -I PREROUTING -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j MARK --set-mark 0x1
iptables -t mangle -I PREROUTING -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j RETURN

И так далее. После того, как в цепочку PREROUTING, таблицы mangle, будут внесены все необходимые правила, закончим ее правилом:

iptables -t mangle -A PREROUTING -j MARK --set-mark 0x6

Это заключительное правило отправит оставшиеся немаркированные пакеты в класс 1:15. Фактически, это правило можно опустить, так как класс 1:15 был задан по-умолчанию, но тем не менее, я оставляю его, чтобы сохранить единство настроек и кроме того, иногда бывает полезно увидеть счетчик пакетов для этого правила.

Нелишним будет добавить те же правила в цепочку OUTPUT, заменив имя цепочки PREROUTING на OUTPUT (s/PREROUTING/OUTPUT/). Тогда трафик, сгенерированный локальными процессами на маршрутизаторе, также будет классифицирован по категориям. Но, в отличие от вышеприведенных правил, в цепочке OUTPUT, я устанавливаю метку -j MARK —set-mark 0x3, таким образом трафик от маршрутизатора получает более высокий приоритет.

Дополнительная оптимизация

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

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

tc qdisc add dev eth0 parent 1:13 handle 130: sfq perturb 10
tc qdisc add dev eth0 parent 1:14 handle 140: sfq perturb 10
tc qdisc add dev eth0 parent 1:15 handle 150: sfq perturb 10

Выполнение настроек во время загрузки системы.

Уверен, что можно найти множество способов, чтобы произвести настройку маршрутизатора во время загрузки. Для себя я создал скрипт /etc/init.d/packetfilter, который принимает команды [start | stop | stop-tables | start-tables | reload-tables]. Он конфигурирует дисциплины (qdiscs) и загружает необходимые модули ядра. Этот же сценарий загружает правила iptables из файла /etc/network/iptables-rules, которые предварительно могут быть сохранены утилитой iptables-save и восстановлены —iptables-restore.

http://docstore.mik.ua/manuals/ru/LARTC/x2755.html