Автор Тема: Отново рутиране  (Прочетена 3914 пъти)

Robert_

  • Напреднали
  • *****
  • Публикации: 52
    • Профил
Отново рутиране
« -: Dec 04, 2006, 11:24 »
Въпреки че вече има такава тема искам и аз да поставя моята, защото проблемът, който ме интересува не е засегнат напълно и чета само общи неща в нета. Използвам Дебиан с ядро 2.6.8-2-686 за връзка с доставчика чрез ПППоЕ. Използвам и следния скрипт за споделяне на връзката с още 2 компютъра, който съм взел от http://www.aboutdebian.com:

#!/bin/sh

#  IPTABLES  PROXY  script for the Linux 2.4 kernel.
#  This script is a derivitive of the script presented in
#  the IP Masquerade HOWTO page at:
#  www.tldp.org/HOWTO/IP-Masquerade-HOWTO/firewall-examples.html
#  It was simplified to coincide with the configuration of
#  the sample system presented in the Guides section of
#  www.aboutdebian.com
#
#  This script is presented as an example for testing ONLY
#  and should not be used on a production proxy server.
#
#    PLEASE SET THE USER VARIABLES
#    IN SECTIONS A AND B OR C

echo -e "\n\nSETTING UP IPTABLES PROXY..."


# === SECTION A
# -----------   FOR EVERYONE

# SET THE INTERFACE DESIGNATION FOR THE NIC CONNECTED TO YOUR INTERNAL NETWORK
#   The default value below is for "eth0".  This value
#   could also be "eth1" if you have TWO NICs in your system.
#   You can use the ifconfig command to list the interfaces
#   on your system.  The internal interface will likely have
#   have an address that is in one of the private IP address
#   ranges.
#       Note that this is an interface DESIGNATION - not
#       the IP address of the interface.
#   Enter the internal interface's designation for the
#   INTIF variable:

INTIF="eth1"


# SET THE INTERFACE DESIGNATION FOR YOUR "EXTERNAL" (INTERNET) CONNECTION
#   The default value below is "ppp0" which is appropriate
#   for a MODEM connection.
#   If you have two NICs in your system change this value
#   to "eth0" or "eth1" (whichever is opposite of the value
#   set for INTIF above).  This would be the NIC connected
#   to your cable or DSL modem (WITHOUT a cable/DSL router).
#       Note that this is an interface DESIGNATION - not
#       the IP address of the interface.
#   Enter the external interface's designation for the
#   EXTIF variable:

EXTIF="ppp0"


# ! ! ! ! !  Use ONLY Section B  *OR*  Section C depending on
#  ! ! ! !   the type of Internet connection you have.


# === SECTION B
# -----------   FOR THOSE WITH STATIC PUBLIC IP ADDRESSES

   # SET YOUR EXTERNAL IP ADDRESS
   #   If you specified a NIC (i.e. "eth0" or "eth1" for
   #   the external interface (EXTIF) variable above,
   #   AND if that external NIC is configured with a
   #   static, public IP address (assigned by your ISP),
   #   UNCOMMENT the following EXTIP line and enter the
   #   IP address for the EXTIP variable:

#EXTIP="your.static.IP.address"



# === SECTION C
# ----------   DIAL-UP MODEM, AND RESIDENTIAL CABLE-MODEM/DSL (Dynamic IP) USERS


# SET YOUR EXTERNAL INTERFACE FOR DYNAMIC IP ADDRESSING
#   If you get your IP address dynamically from SLIP, PPP,
#   BOOTP, or DHCP, UNCOMMENT the command below.
#   (No values have to be entered.)
#         Note that if you are uncommenting these lines then
#         the EXTIP line in Section B must be commented out.

EXTIP="`/sbin/ifconfig ppp0 | grep 'inet addr' | awk '{print $2}' | sed -e 's/.*://'`"


# --------  No more variable setting beyond this point  --------


echo "Loading required stateful/NAT kernel modules..."

/sbin/depmod -a
/sbin/modprobe ip_tables
/sbin/modprobe ip_conntrack
/sbin/modprobe ip_conntrack_ftp
/sbin/modprobe ip_conntrack_irc
/sbin/modprobe iptable_nat
/sbin/modprobe ip_nat_ftp
/sbin/modprobe ip_nat_irc

echo "    Enabling IP forwarding..."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv4/ip_dynaddr

echo "    External interface: $EXTIF"
echo "       External interface IP address is: $EXTIP"

echo "    Loading proxy server rules..."

# Clearing any existing rules and setting default policy
iptables -P INPUT ACCEPT
iptables -F INPUT
iptables -P OUTPUT ACCEPT
iptables -F OUTPUT
iptables -P FORWARD DROP
iptables -F FORWARD
iptables -t nat -F

# FWD: Allow all connections OUT and only existing and related ones IN
iptables -A FORWARD -i $EXTIF -o $INTIF -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT

# Enabling SNAT (MASQUERADE) functionality on $EXTIF
iptables -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE


в края на краищата клиентът, който е на уиндоус ХП получава пинг да речем до http://www.google.bg, но когато тръгна да зареждам страницата в браузър не се зарежда. Просто зареждането спира след няколко секунди.
Въпросът ми е дали имам някаква грешка в скрипта или пък уиндоусът изпрашта пакети с голям размер MTU.
Благодаря за помощта предварително.
Впрочем този същия скрипт, само че редактиран за статичен адрес както е дадено там работеше безупречно преди да ми сменят връзката...
Активен

gat3way

  • Напреднали
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Отново рутиране
« Отговор #1 -: Dec 04, 2006, 12:10 »
Отговори: "не", "не".
Активен

"Knowledge is power" - France is Bacon

Hapkoc

  • Напреднали
  • *****
  • Публикации: 2117
    • Профил
Отново рутиране
« Отговор #2 -: Dec 04, 2006, 12:13 »
gat3way, я се обоснови за второто "не"
Активен

Robert_

  • Напреднали
  • *****
  • Публикации: 52
    • Профил
Отново рутиране
« Отговор #3 -: Dec 04, 2006, 12:25 »
Не мога да схвана отговора, gat3way, искаш да кажеш, че няма грешка в скрипта и уиндоус ХП изпраща пакети с по-малък размер от 1500?
Действително когато изпълня
ping http://www.google.bg
всичко изглежда наред, но когато изпълня:
ping http://www.google.bg -l 1500 тогава
Request timed out...
Активен

cenata

  • Напреднали
  • *****
  • Публикации: 116
  • Distribution: Fedora
  • Window Manager: Gnome
    • Профил
Отново рутиране
« Отговор #4 -: Dec 04, 2006, 12:39 »
Да си променял някъде по машините MAC адресите, понеже при мен беше подобн проблем и докато не ги оправих беше същото - има пинг, но след 30сек спираше. Нямаше пинг и в моята си "мрежа"
Активен

gat3way

  • Напреднали
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Отново рутиране
« Отговор #5 -: Dec 04, 2006, 12:45 »
Ми аз не примерно не мога да разбера какъв ще е проблема ако MTU-то е по-ниско от 1500. Вие мислите ли че ще има проблем?

От друга страна един типичен HTTP GET request в повечето случаи е много по-малък от 1500 байта. 2-та пакета, които хоста трябва да изпрати за да иницира и завърши TCP handshake-a са също доста малки.

Естествено, човек може да се замисли дали отговорът няма да достатъчно голям за да се събере в един "наднормен" фрейм да речем. Само че отговорът идва отвън, рутерът знае че средата е с MTU 1500 и ще го разбие или (ако има DF) ще върне съответното ICMP съобщение. Виж, ако рутера има други (и грешни) виждания за MTU...тогава е възможно да се сговни, макар че преминавайки по пътя, пакетът твърде вероятно вече някъде е нацелил етернет сегмент с по-ниско МТУ и се е "нацепил" на фрагменти.

Можете да си поиграете с tcpdump или нещо от сорта за да видите колко големи са HTTP заявките. Пакетите дето правят хендшейк-а са по 60-ина байта, пакета с GET заявката е между 100 и 300-400 байта. Ако ще MTU да ти е 11000 (някъде оттам насетне CRC сумата почва да става хм.. "неефективна")...тези пакети ще минат спокойно върху един 100base-tx сегмент, независимо какво ти е MTU-to. Гаранция '<img'>
Активен

"Knowledge is power" - France is Bacon

Hapkoc

  • Напреднали
  • *****
  • Публикации: 2117
    • Профил
Отново рутиране
« Отговор #6 -: Dec 04, 2006, 13:11 »
Проблема е ако има някакво "стесняване" по пътя (примерно ако има тунел) и същевременно някъде по пътя е орязан ICMP, така че машината, която праща твърде големите пакети да не може да разбере, че това се случва (a.k.a. path mtu discovery problem).

Проблема обикновено е именно при получаване на отговор на HTTP заявки (ако говорим за HTTP естествено, за останалите протоколи също важи проблема, но понеже стана дума за HTTP). Ако отоговора е достатъчно малък, той се получава, ако не е връзката изглежда че зацикля, а всъщност сървъра се опитва да прати пакет, който има нужда от фрагментация, но той (сървъра) не знае това. Самата фрагментация обикновено не се случва по пътя, т.к. пакетите са с DF флаг.

Най-лесно е да се установи дали проблема е в MTU като се намали стойността му на машина зад маршрутизатора и се види дали в този момент се "отпушва" връзката.

Също за TCP връзки проблема може да се заобиколи с правило, указващо MSS параметъра на връзката да се договори на по-ниска стойност (-j TCPMSS --set-mss <value>).
Активен

Robert_

  • Напреднали
  • *****
  • Публикации: 52
    • Профил
Отново рутиране
« Отговор #7 -: Dec 04, 2006, 13:14 »
Не съм правил никакви промени в MAC адреса. Обяснявам си го с това, че клиентът ми праща пакети към рутера с големина 1500 байта, а ПППоЕ-то на рутера също трябва да праща пакети с такава големина към ИСП-то и информацията някъде се губи между eth0 и клиента на уиндоус...
Все пак не знам защо става така. Пробвах с пинг и към други сайтове - има и резултатът пак същия - не се отварят...
Активен

Hapkoc

  • Напреднали
  • *****
  • Публикации: 2117
    • Профил
Отново рутиране
« Отговор #8 -: Dec 04, 2006, 13:24 »
Еми PPPoE-то добавя още (не знам колко) байта към пакета, който отива по жицата, и бидейки този пакет вече с размер (1500 - ethernet header length) той става твърде голям, а ако му е вдигнат DF флага той не може и да се фрагментира.

Проблема е по-скоро в посока интернет -> теб, отколкото от теб към интернет.

Пробвай да намалиш MTU стойността на Windows (някъде по регистрите се пипаше, имаше и tool-че за целта).
Активен

gat3way

  • Напреднали
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Отново рутиране
« Отговор #9 -: Dec 04, 2006, 13:59 »
Въпросът всъщност може да се разреши единствено за TCP връзки, поради естеството на протокола (MSS е част от хедъра).

Това става защото по време на хендшейка, двете страни се договарят за MSS, което има пряко отношение към максималната големина на пакета, която се праща и от двете страни (т.е отсрещният хост знае колко максимално да праща). Така, дори да се сговни PMTU, ако си смъкнеш MTU и иницираш нова връзка все пак ще получиш коректно отговор.

За други протоколи като UDP или ICMP това обаче няма да сработи (не че е болка за умиране в повечето случаи де). Примерно ако си намалиш MTU и пратиш един голям ICMP echo пакет отговорът няма да пристигне, дори ако MTU-то ти е ниско (това само към "проблемен" хост).

Както и да е, мисля че игричките с MSS са най-добрият вариант в този случай. Най-евтини откъм процесорно време на рутера, макар че само с  една машинка зад нат-а няма да усетиш нищо.
Активен

"Knowledge is power" - France is Bacon

Hapkoc

  • Напреднали
  • *****
  • Публикации: 2117
    • Профил
Отново рутиране
« Отговор #10 -: Dec 04, 2006, 14:39 »
Цитат
за TCP връзки проблема може да се заобиколи с правило, указващо MSS


Цитат
Въпросът всъщност може да се разреши единствено за TCP връзки, поради естеството на протокола (MSS е част от хедъра)




Цитат
ако си смъкнеш MTU и иницираш нова връзка все пак ще получиш коректно отговор

...

За други протоколи като UDP или ICMP това обаче няма да сработи


Ако си смъкнеш MTU ще работи за всички протоколи, но пък ако имаш 100 работни станции зад маршрутизатора не е много удобно да го сменяш на 100 места.
Активен

gat3way

  • Напреднали
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Отново рутиране
« Отговор #11 -: Dec 04, 2006, 15:11 »
Тц, няма. Отсрещният сървър, който е имал неблагоразумието да реже ICMP-та, няма откъде да знае колко е максимално големият пакет, който можеш да получиш. Няма да може и да се възползва от PMTUD. Ако неговото MTU е по-голямо от това на тунела, нито един oversize-нат пакет няма да пристигне. Докато TCP протокола му предоставя тази информация (MSS стойността от инициращият пакет), в случая просто няма откъде да знае.

Друг е въпросът колко 'често' се срещат по-големи UDP пакети - тези за voip приложенията са по принцип малки. При някои streaming media изпълнения обаче е по-вероятно да се случи.

Големи ICMP пакети...не мога да се сетя при какво обстоятелство се генерират освен съвсем нарочно. Пък и ако отсреща ги режат така или иначе няма да получиш отговор



Активен

"Knowledge is power" - France is Bacon

Hapkoc

  • Напреднали
  • *****
  • Публикации: 2117
    • Профил
Отново рутиране
« Отговор #12 -: Dec 04, 2006, 15:18 »
Прав си.

М/у другото, сървъра който праща пакетите не е задължително да е същата машина, която реже ICMP-тата.
Активен

gat3way

  • Напреднали
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Отново рутиране
« Отговор #13 -: Dec 04, 2006, 15:36 »
Уф да, някои рутери имат лошия навик да ги режат. Въпреки всичко, все пак pppoe е добър вариант. Разни dialup-и, особено по-бавни такива имат много по-ниско MTU - напълно е възможно примерно 512. Ако там се случат такива неща, предполагам става забавно '<img'>

И понеже се сещам за един хмм голям нашенски провайдър дето има навика да си слага частни IP адреси на рутери, които размотават  трафика им (че май и транзитния през тях), та ми е интересно...примерно ако един от тези рутери реши да върне ICMP fragmentation needed и източника му е нещо от сорта на 10.0.0.5...интересно дали такива пакети не се филтрират, принципно не е много прието между доставчиците да се рутира и да не се реже трафик, оригиниращ или отиващ към такива адреси...просто ми е интересно де, но вероятно настъпват разни мотики свързани с това, знам ли ги '<img'>

Предполагам сте виждали чат-пат някой traceroute свързан с маршрути минаващи през такива мрежи...много е забавно да гледаш как поредния хоп е 10.0.0.5. Всъщност най-интересното е че го виждаш, защото това означава че никой не филтрира трафика идващ от такива адреси.

Абе забавно, хвърлих се в размисъл '<img'>

Наскоро даже с чудехме с едни колеги какво ли ще стане ако BGP рутера им вземе погрешка да advertise-не някаква такава мрежа, например 10.0.0.0/8. Нямам много идея, но при всички положения ще е забавно. Простата логика показва, че ще започнат да колекционират странни трафици от цял свят с объркан destination. Дали става така обаче не знам, който разбира повече да каже '<img'>



Активен

"Knowledge is power" - France is Bacon

Hapkoc

  • Напреднали
  • *****
  • Публикации: 2117
    • Профил
Отново рутиране
« Отговор #14 -: Dec 04, 2006, 15:45 »
ICMP-тата ако се не лъжа се маршрутизират и за адреси от RFC1918, затова се вижда в traceroute-а (и аз се чудех, тука някой от форума ме светна скоро, май zeridon беше).
Активен