Титла: Отново рутиране
Публикувано от: Robert_ в Dec 04, 2006, 11:24
Въпреки че вече има такава тема искам и аз да поставя моята, защото проблемът, който ме интересува не е засегнат напълно и чета само общи неща в нета. Използвам Дебиан с ядро 2.6.8-2-686 за връзка с доставчика чрез ПППоЕ. Използвам и следния скрипт за споделяне на връзката с още 2 компютъра, който съм взел от 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
в края на краищата клиентът, който е на уиндоус ХП получава пинг да речем до www.google.bg, но когато тръгна да зареждам страницата в браузър не се зарежда. Просто зареждането спира след няколко секунди.
Въпросът ми е дали имам някаква грешка в скрипта или пък уиндоусът изпрашта пакети с голям размер MTU.
Благодаря за помощта предварително.
Впрочем този същия скрипт, само че редактиран за статичен адрес както е дадено там работеше безупречно преди да ми сменят връзката...
#!/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
в края на краищата клиентът, който е на уиндоус ХП получава пинг да речем до www.google.bg, но когато тръгна да зареждам страницата в браузър не се зарежда. Просто зареждането спира след няколко секунди.
Въпросът ми е дали имам някаква грешка в скрипта или пък уиндоусът изпрашта пакети с голям размер MTU.
Благодаря за помощта предварително.
Впрочем този същия скрипт, само че редактиран за статичен адрес както е дадено там работеше безупречно преди да ми сменят връзката...
Титла: Отново рутиране
Публикувано от: gat3way в Dec 04, 2006, 12:10
Отговори: "не", "не".
Титла: Отново рутиране
Публикувано от: Hapkoc в Dec 04, 2006, 12:13
gat3way, я се обоснови за второто "не"
Титла: Отново рутиране
Публикувано от: Robert_ в Dec 04, 2006, 12:25
Не мога да схвана отговора, gat3way, искаш да кажеш, че няма грешка в скрипта и уиндоус ХП изпраща пакети с по-малък размер от 1500?
Действително когато изпълня
ping www.google.bg
всичко изглежда наред, но когато изпълня:
ping www.google.bg -l 1500 тогава
Request timed out...
Действително когато изпълня
ping www.google.bg
всичко изглежда наред, но когато изпълня:
ping www.google.bg -l 1500 тогава
Request timed out...
Титла: Отново рутиране
Публикувано от: cenata в Dec 04, 2006, 12:39
Да си променял някъде по машините MAC адресите, понеже при мен беше подобн проблем и докато не ги оправих беше същото - има пинг, но след 30сек спираше. Нямаше пинг и в моята си "мрежа"
Титла: Отново рутиране
Публикувано от: gat3way в 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. Гаранция
От друга страна един типичен 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. Гаранция
Титла: Отново рутиране
Публикувано от: Hapkoc в 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>).
Проблема обикновено е именно при получаване на отговор на HTTP заявки (ако говорим за HTTP естествено, за останалите протоколи също важи проблема, но понеже стана дума за HTTP). Ако отоговора е достатъчно малък, той се получава, ако не е връзката изглежда че зацикля, а всъщност сървъра се опитва да прати пакет, който има нужда от фрагментация, но той (сървъра) не знае това. Самата фрагментация обикновено не се случва по пътя, т.к. пакетите са с DF флаг.
Най-лесно е да се установи дали проблема е в MTU като се намали стойността му на машина зад маршрутизатора и се види дали в този момент се "отпушва" връзката.
Също за TCP връзки проблема може да се заобиколи с правило, указващо MSS параметъра на връзката да се договори на по-ниска стойност (-j TCPMSS --set-mss <value>).
Титла: Отново рутиране
Публикувано от: Robert_ в Dec 04, 2006, 13:14
Не съм правил никакви промени в MAC адреса. Обяснявам си го с това, че клиентът ми праща пакети към рутера с големина 1500 байта, а ПППоЕ-то на рутера също трябва да праща пакети с такава големина към ИСП-то и информацията някъде се губи между eth0 и клиента на уиндоус...
Все пак не знам защо става така. Пробвах с пинг и към други сайтове - има и резултатът пак същия - не се отварят...
Все пак не знам защо става така. Пробвах с пинг и към други сайтове - има и резултатът пак същия - не се отварят...
Титла: Отново рутиране
Публикувано от: Hapkoc в Dec 04, 2006, 13:24
Еми PPPoE-то добавя още (не знам колко) байта към пакета, който отива по жицата, и бидейки този пакет вече с размер (1500 - ethernet header length) той става твърде голям, а ако му е вдигнат DF флага той не може и да се фрагментира.
Проблема е по-скоро в посока интернет -> теб, отколкото от теб към интернет.
Пробвай да намалиш MTU стойността на Windows (някъде по регистрите се пипаше, имаше и tool-че за целта).
Проблема е по-скоро в посока интернет -> теб, отколкото от теб към интернет.
Пробвай да намалиш MTU стойността на Windows (някъде по регистрите се пипаше, имаше и tool-че за целта).
Титла: Отново рутиране
Публикувано от: gat3way в Dec 04, 2006, 13:59
Въпросът всъщност може да се разреши единствено за TCP връзки, поради естеството на протокола (MSS е част от хедъра).
Това става защото по време на хендшейка, двете страни се договарят за MSS, което има пряко отношение към максималната големина на пакета, която се праща и от двете страни (т.е отсрещният хост знае колко максимално да праща). Така, дори да се сговни PMTU, ако си смъкнеш MTU и иницираш нова връзка все пак ще получиш коректно отговор.
За други протоколи като UDP или ICMP това обаче няма да сработи (не че е болка за умиране в повечето случаи де). Примерно ако си намалиш MTU и пратиш един голям ICMP echo пакет отговорът няма да пристигне, дори ако MTU-то ти е ниско (това само към "проблемен" хост).
Както и да е, мисля че игричките с MSS са най-добрият вариант в този случай. Най-евтини откъм процесорно време на рутера, макар че само с една машинка зад нат-а няма да усетиш нищо.
Това става защото по време на хендшейка, двете страни се договарят за MSS, което има пряко отношение към максималната големина на пакета, която се праща и от двете страни (т.е отсрещният хост знае колко максимално да праща). Така, дори да се сговни PMTU, ако си смъкнеш MTU и иницираш нова връзка все пак ще получиш коректно отговор.
За други протоколи като UDP или ICMP това обаче няма да сработи (не че е болка за умиране в повечето случаи де). Примерно ако си намалиш MTU и пратиш един голям ICMP echo пакет отговорът няма да пристигне, дори ако MTU-то ти е ниско (това само към "проблемен" хост).
Както и да е, мисля че игричките с MSS са най-добрият вариант в този случай. Най-евтини откъм процесорно време на рутера, макар че само с една машинка зад нат-а няма да усетиш нищо.
Титла: Отново рутиране
Публикувано от: Hapkoc в Dec 04, 2006, 14:39
| Цитат |
| за TCP връзки проблема може да се заобиколи с правило, указващо MSS |
| Цитат |
| Въпросът всъщност може да се разреши единствено за TCP връзки, поради естеството на протокола (MSS е част от хедъра) |
| Цитат |
| ако си смъкнеш MTU и иницираш нова връзка все пак ще получиш коректно отговор ... За други протоколи като UDP или ICMP това обаче няма да сработи |
Ако си смъкнеш MTU ще работи за всички протоколи, но пък ако имаш 100 работни станции зад маршрутизатора не е много удобно да го сменяш на 100 места.
Титла: Отново рутиране
Публикувано от: gat3way в Dec 04, 2006, 15:11
Тц, няма. Отсрещният сървър, който е имал неблагоразумието да реже ICMP-та, няма откъде да знае колко е максимално големият пакет, който можеш да получиш. Няма да може и да се възползва от PMTUD. Ако неговото MTU е по-голямо от това на тунела, нито един oversize-нат пакет няма да пристигне. Докато TCP протокола му предоставя тази информация (MSS стойността от инициращият пакет), в случая просто няма откъде да знае.
Друг е въпросът колко 'често' се срещат по-големи UDP пакети - тези за voip приложенията са по принцип малки. При някои streaming media изпълнения обаче е по-вероятно да се случи.
Големи ICMP пакети...не мога да се сетя при какво обстоятелство се генерират освен съвсем нарочно. Пък и ако отсреща ги режат така или иначе няма да получиш отговор
Друг е въпросът колко 'често' се срещат по-големи UDP пакети - тези за voip приложенията са по принцип малки. При някои streaming media изпълнения обаче е по-вероятно да се случи.
Големи ICMP пакети...не мога да се сетя при какво обстоятелство се генерират освен съвсем нарочно. Пък и ако отсреща ги режат така или иначе няма да получиш отговор
Титла: Отново рутиране
Публикувано от: Hapkoc в Dec 04, 2006, 15:18
Прав си.
М/у другото, сървъра който праща пакетите не е задължително да е същата машина, която реже ICMP-тата.
М/у другото, сървъра който праща пакетите не е задължително да е същата машина, която реже ICMP-тата.
Титла: Отново рутиране
Публикувано от: gat3way в Dec 04, 2006, 15:36
Уф да, някои рутери имат лошия навик да ги режат. Въпреки всичко, все пак pppoe е добър вариант. Разни dialup-и, особено по-бавни такива имат много по-ниско MTU - напълно е възможно примерно 512. Ако там се случат такива неща, предполагам става забавно
И понеже се сещам за един хмм голям нашенски провайдър дето има навика да си слага частни IP адреси на рутери, които размотават трафика им (че май и транзитния през тях), та ми е интересно...примерно ако един от тези рутери реши да върне ICMP fragmentation needed и източника му е нещо от сорта на 10.0.0.5...интересно дали такива пакети не се филтрират, принципно не е много прието между доставчиците да се рутира и да не се реже трафик, оригиниращ или отиващ към такива адреси...просто ми е интересно де, но вероятно настъпват разни мотики свързани с това, знам ли ги
Предполагам сте виждали чат-пат някой traceroute свързан с маршрути минаващи през такива мрежи...много е забавно да гледаш как поредния хоп е 10.0.0.5. Всъщност най-интересното е че го виждаш, защото това означава че никой не филтрира трафика идващ от такива адреси.
Абе забавно, хвърлих се в размисъл
Наскоро даже с чудехме с едни колеги какво ли ще стане ако BGP рутера им вземе погрешка да advertise-не някаква такава мрежа, например 10.0.0.0/8. Нямам много идея, но при всички положения ще е забавно. Простата логика показва, че ще започнат да колекционират странни трафици от цял свят с объркан destination. Дали става така обаче не знам, който разбира повече да каже
И понеже се сещам за един хмм голям нашенски провайдър дето има навика да си слага частни IP адреси на рутери, които размотават трафика им (че май и транзитния през тях), та ми е интересно...примерно ако един от тези рутери реши да върне ICMP fragmentation needed и източника му е нещо от сорта на 10.0.0.5...интересно дали такива пакети не се филтрират, принципно не е много прието между доставчиците да се рутира и да не се реже трафик, оригиниращ или отиващ към такива адреси...просто ми е интересно де, но вероятно настъпват разни мотики свързани с това, знам ли ги
Предполагам сте виждали чат-пат някой traceroute свързан с маршрути минаващи през такива мрежи...много е забавно да гледаш как поредния хоп е 10.0.0.5. Всъщност най-интересното е че го виждаш, защото това означава че никой не филтрира трафика идващ от такива адреси.
Абе забавно, хвърлих се в размисъл
Наскоро даже с чудехме с едни колеги какво ли ще стане ако BGP рутера им вземе погрешка да advertise-не някаква такава мрежа, например 10.0.0.0/8. Нямам много идея, но при всички положения ще е забавно. Простата логика показва, че ще започнат да колекционират странни трафици от цял свят с объркан destination. Дали става така обаче не знам, който разбира повече да каже
Титла: Отново рутиране
Публикувано от: Hapkoc в Dec 04, 2006, 15:45
ICMP-тата ако се не лъжа се маршрутизират и за адреси от RFC1918, затова се вижда в traceroute-а (и аз се чудех, тука някой от форума ме светна скоро, май zeridon беше).
Титла: Отново рутиране
Публикувано от: gat3way в Dec 04, 2006, 16:01
Хм, в това има логика..
Титла: Отново рутиране
Публикувано от: Robert_ в Dec 04, 2006, 20:13
Сега като се замисля - ако смъкна MTU-то на 576 примерно тогава няма и да мога да получавам по-големи пакети от рутера ми. Тогава няма да има смисъл. Мислите ли?
Титла: Отново рутиране
Публикувано от: Hapkoc в Dec 04, 2006, 21:09
Е на 576 няма смисъл да го смъкваш.
Или сложи правило за TCPMSS на маршрутизатора или сложи MTU на клиентската машина със максималната стойност, която минава (трябва да видиш колко байта е PPPoE header-а).
Или сложи правило за TCPMSS на маршрутизатора или сложи MTU на клиентската машина със максималната стойност, която минава (трябва да видиш колко байта е PPPoE header-а).
Титла: Отново рутиране
Публикувано от: Robert_ в Dec 04, 2006, 21:25
Може да прозвучи глупаво, но има ли някакъв инструмент в линукс за преглеждане на свойствата на пакетите?
Титла: Отново рутиране
Публикувано от: cenata в Dec 04, 2006, 22:06
Wireshark
Титла: Отново рутиране
Публикувано от: Hapkoc в Dec 04, 2006, 23:09
също tcpdump
Титла: Отново рутиране
Публикувано от: gat3way в Dec 04, 2006, 23:29
tcpdump...дам wireshark е много удобно и нагледно нещо, но за жалост ужасно тромаво, гълтащо памет и несигурно от край време. Освен това като софтуерен дизайн е малко скапана идея, поради това че заделя все повече памет напред във времето за да може да "анализира" впоследствие трафика и евентуално при желание да го експорт-не във pcap формат. Не знам дали има някакъв вариант да му се дава timeframe, но навремето като съм го ползвал, ако го забравeх за дълго време си заварвах машината изпаднала в тежък swapping
Иначе, wireshark (ethereal постаро му) е прекрасен инструмент за "сглобяване" на ICQ сесии изснифени, хахаха.
Апропо...има и друг малко по-power вариант, нарича се hunt. Той позволява и разни хахорски изпълнения, например има MitM arpspoof наклонности (с relay-ване на трафика през tun/tap), "трепане" на TCP сесии с RST, дори превземане на установени такива (голям смях е ако го използваш на рутера докато някой от мрежата ти чати с cleartext протокол, например IRC - носи голямо удовлетворение за детински глупости). hunt дори го има из дебиан-ските пакетни репозитори-та, въпреки че версията която бях дръпнал с apt-get не работеше. И да, същият шит има прилични снифинг способности, макар че са далеч от тези на tcpdump.
редакция: всъщност не се налага да го пускаш на рутера и трафика да минава през теб, както и работи в switched среда. Просто трябва да си поиграеш със ARP spoofing & relaying възможностите му.
И да, работи само в рамките на етернет сегмента. layer2 е пословично несигурно нещо и го позволява. Не работи и със суичове подържащи порт секюрити (ще резнат фалшифицираните арп пакети вероятно).
wireshark е много удобно и нагледно нещо, но за жалост ужасно тромаво, гълтащо памет и несигурно от край време. Освен това като софтуерен дизайн е малко скапана идея, поради това че заделя все повече памет напред във времето за да може да "анализира" впоследствие трафика и евентуално при желание да го експорт-не във pcap формат. Не знам дали има някакъв вариант да му се дава timeframe, но навремето като съм го ползвал, ако го забравeх за дълго време си заварвах машината изпаднала в тежък swapping Иначе, wireshark (ethereal постаро му) е прекрасен инструмент за "сглобяване" на ICQ сесии изснифени, хахаха.
Апропо...има и друг малко по-power вариант, нарича се hunt. Той позволява и разни хахорски изпълнения, например има MitM arpspoof наклонности (с relay-ване на трафика през tun/tap), "трепане" на TCP сесии с RST, дори превземане на установени такива (голям смях е ако го използваш на рутера докато някой от мрежата ти чати с cleartext протокол, например IRC - носи голямо удовлетворение за детински глупости). hunt дори го има из дебиан-ските пакетни репозитори-та, въпреки че версията която бях дръпнал с apt-get не работеше. И да, същият шит има прилични снифинг способности, макар че са далеч от тези на tcpdump.
редакция: всъщност не се налага да го пускаш на рутера и трафика да минава през теб, както и работи в switched среда. Просто трябва да си поиграеш със ARP spoofing & relaying възможностите му.
И да, работи само в рамките на етернет сегмента. layer2 е пословично несигурно нещо и го позволява. Не работи и със суичове подържащи порт секюрити (ще резнат фалшифицираните арп пакети вероятно).
Титла: Отново рутиране
Публикувано от: Robert_ в Dec 10, 2006, 21:33
Отново на старата тема...
Пропуснах да добавя резултатът от изпълнението на ifconfig. Забележете стойността на MTU на интерфейс ppp0, който отговаря за PPPoE-то и MTU-то на другите интерфейси. Прави впечатление, че на eth0 и eth1 е по-високо от това на ppp0. Как може да се направи така, че да се разделят пакетите от рутера?
eth0 Link encap:Ethernet HWaddr 00:00:C0:DB:B3:FF
inet6 addr: fe80::200:c0ff:fedb:b3ff/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:25483 errors:0 dropped:0 overruns:0 frame:0
TX packets:746 errors:0 dropped:0 overruns:0 carrier:0
collisions:39 txqueuelen:1000
RX bytes:2121172 (2.0 MiB) TX bytes:108174 (105.6 KiB)
Interrupt:5 Base address:0x250 Memory:c0000-c2000
eth1 Link encap:Ethernet HWaddr 00:0D:61:29:DC:B6
inet addr:192.168.118.1 Bcast:192.168.118.255 Mask:255.255.255.0
inet6 addr: fe80::20d:61ff:fe29:dcb6/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:149 errors:0 dropped:0 overruns:0 frame:0
TX packets:175 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:11116 (10.8 KiB) TX bytes:13900 (13.5 KiB)
Interrupt:11 Base address:0xe400
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:94 errors:0 dropped:0 overruns:0 frame:0
TX packets:94 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:6140 (5.9 KiB) TX bytes:6140 (5.9 KiB)
ppp0 Link encap:Point-to-Point Protocol
inet addr:87.120.8.84 P-t-P:87.120.8.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:487 errors:0 dropped:0 overruns:0 frame:0
TX packets:557 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:327045 (319.3 KiB) TX bytes:84442 (82.4 KiB)
Пропуснах да добавя резултатът от изпълнението на ifconfig. Забележете стойността на MTU на интерфейс ppp0, който отговаря за PPPoE-то и MTU-то на другите интерфейси. Прави впечатление, че на eth0 и eth1 е по-високо от това на ppp0. Как може да се направи така, че да се разделят пакетите от рутера?
eth0 Link encap:Ethernet HWaddr 00:00:C0:DB:B3:FF
inet6 addr: fe80::200:c0ff:fedb:b3ff/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:25483 errors:0 dropped:0 overruns:0 frame:0
TX packets:746 errors:0 dropped:0 overruns:0 carrier:0
collisions:39 txqueuelen:1000
RX bytes:2121172 (2.0 MiB) TX bytes:108174 (105.6 KiB)
Interrupt:5 Base address:0x250 Memory:c0000-c2000
eth1 Link encap:Ethernet HWaddr 00:0D:61:29:DC:B6
inet addr:192.168.118.1 Bcast:192.168.118.255 Mask:255.255.255.0
inet6 addr: fe80::20d:61ff:fe29:dcb6/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:149 errors:0 dropped:0 overruns:0 frame:0
TX packets:175 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:11116 (10.8 KiB) TX bytes:13900 (13.5 KiB)
Interrupt:11 Base address:0xe400
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:94 errors:0 dropped:0 overruns:0 frame:0
TX packets:94 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:6140 (5.9 KiB) TX bytes:6140 (5.9 KiB)
ppp0 Link encap:Point-to-Point Protocol
inet addr:87.120.8.84 P-t-P:87.120.8.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:487 errors:0 dropped:0 overruns:0 frame:0
TX packets:557 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:327045 (319.3 KiB) TX bytes:84442 (82.4 KiB)