ICMP filtering

Клиент съм на един ISP по LAN, но поради известни причини ни филтрират ICMP пакетите. Въпроса ми е - в този случай има ли заобиколен начин да се използуват команди като ping и traceroute, или техни алтернативи? ОС-а е Win2k.

В windows по неведоми причини, известни само на Бил Гейтс, командата tracert използва icmp, вместо UDP. Всяка външна програма, която прави traceroute би трябвало да работи. Аз не съм ползвал такава, но със сигурност може да бъде намерено нещо в [линк]

Нашите клиенти могат да използват ping и traceroute през [линк]

Митко

кои са тези ламери "провайдъри", които филтрират целия ICMP трафик...
..дано да филтрират само echo request,reply i time exceed, които са за пинга и трасирането, щото ако филтрират всичко, просто нямам думи.

В момента аз филтрирам само echo_request с дължина 92, но първата седмица след като започна масовото разпространение на вируси бях отрязал селия icmp канал понеже бях останал без думи като видях през главния рутер да минава 1Мбит icmp външен трафик и 50000 сесси.

Добрия Интернет струва пари!!!

ами използувам външна програма - VisualRoute
ето един примерен резултат:

Report for [линк] [194.145.63.12]

Analysis: Connections to HTTP port 80 on host '[линк]' are working, but ICMP packets are being blocked past network "xxxxxxxxxxxxxxxx" at hop 2. It is a HTTP server (running Apache/1.3.27 (Unix) Debian GNU/Linux mod_ssl/2.8.14 OpenSSL/0.9.7a PHP/4.2.3)

И аз предполагам че го правят заради скорошните вирусни атаки, но ако някой ми препоръча нещо друго ще съм му благодарен

Трябва да си потърсите някоя проста програма за traceroute, която да не пингва всяка една стъпка. По принцип traceroute при нас не е спиран и под Linux си работи перфектно, но под Windows не работи. Аз ползвам windows сравнително рядко и нямам опит с много различни програми, но съм тествал вградения tracert и графичния SamSpade - и двата изпращат echo request пакети, т.е. пингват. Не е логично, но го правят. Вероятно VisualRoute прави същото.

Митко

дам наистина след като netwlan ми казаха за welchia(i mi pokazaha mrtg-to za international buahhaha) и аз филтрирах целия icmp... а сега пък целия пак си работи ;-)
be happy

The Real Net - The Real Internet Provider
[линк]

Много е идейно да филтрираш примерно "ICMP fragmentation needed" да знаеш ...

Microsoft Certified Double Clicker

там, че много го правят. и то не умишлено, просто нямат елементарна представа за смисъла от ICMP (и за много други неща), яде ли се, за какво се ползва.
И после мрежата не е вече мрежа, юзърите пискат, че нещо се е е*, а "умния" админ вика редовното: "грешката не е в моя телевизор".. верно не е, в главата му е грешката...

Не е голяма беда, ако филтрираш всички ICMP пакети със source адреса на клиента, ако клиентът е с фалшиво IP. Тогава няма практически никакъв риск той да изпраща fragmentation needed, port unreachable или каквото и да е. Важното е той да може да получава всичко, но ако му отрежеш изпращането, с нищо няма да му навредиш. Е, ако е с реално IP и към него се отварят сесии, тогава може и да има проблеми.

Митко

разбира се че е маскиран.. и че се режат само тези които се изпращат...

The Real Net - The Real Internet Provider
[линк]

Няма никакво значение дали клиента е с реално ИП или с маскирано и в двата случая забраната на исмп няма да се отрази на качеството на комуникасия по тсп или удп единствената вреда идва от това, че има клиенти които следят автоматизирано връзката до рутера по исмп и в случай на отпадане на главната линия скрипта трябва да прерутира трафика през резервната линия.
Всеки що годе свестен администратор който си познава мрежата може да се оправи и без пинг при повреда. Друг е въпроса, че народа е свикнал "щом нема пинг значи нема интернет" .

Добрия Интернет струва пари!!!

Мисълта ми беше, че ако клиентът е с реално IP и КЪМ него се отварят сесии, тогава трябва задължително да НЕ филтрираш port unreachable и fragmentation needed, иначе няма да работи например path mtu discovery и ако клиентът е с mtu по-малко от 1500 никой няма да може да се свърже КЪМ него (а той ще може). port unreachable пък ще бави опитите за отваряне на сесии, които той по някаква причина не приема (примерно icq). А ако е с фалшиво IP, тогава сесии към него и без това не могат да се отварят и можеш спокойно да филтрираш абсолютно целия ICMP протокол, а не само echo request.

Що се отнася до проверката на връзката, аз съм разрешил icmp от и до ip-сегментите, в които ни се намират рутерите и сървърите (те не се намират в същите мрежи, в които са клиентите).

Митко

Така нека да уточним кога е възможно да възникне проблема за който говориш:
1. Клиент с уеб сървър -- МТУ 1450 -- рутер -- МТУ1500--рутер--МТУ1500--клиент

2. Клиент с уеб сървър -- МТУ 1500 -- рутер -- МТУ1450--рутер--МТУ1500--клиент

При вариант 1 няма да възникне проблем при вариант 2 е възможно да има такъв проблем когато единия от клиентите използва PMTU-D при отрязан icmp.
Проблема може да се корегира с забраната на PMTU-D, но това е крайна мярка.
Нека да обобщя :
Такъв проблем има изключително малка вероятност да се получи поради факта, че стандартно пакетите които се ползват в интернет рядко надвишават 1024 байта + 40байта за хедъри на IP i TCP, а никой не си позволява да намали МТУ под 1400 .
В общия случай MSS maximum segment size между две точки в интернет се анонсира при установяване на ТСП конекция. Повечето системи анонсират MSS като се ръководят от МТУ-то на интерфейса.
За тез които се интересуват от проблема повече информация може да намерят в RFC-1191.

Добрия Интернет струва пари!!!

Нямаш си представа колко често се появява. Почти всички хардуерни NAT-рутери не натват icmp fragmentation needed и в резултат на това всякакво mtu под 1500 спира да работи. Същото се получава и с голяма част от софтуерните. Едно време имахме подобен проблем с dir.bg: по технически причини заради vlan-а трябваше mtu-то да се намали само с 4 байта, но това беше достатъчно за да завалят оплаквания от клиенти, че не могат да влизат в дира. Проблемът възниква и при ipip/gre тунели. Въобще, ако някъде имаш mtu < 1500, със сигурност можеш да очакваш ядове. Оправя се с -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, ама не си е работа ...

Митко

Аз също ползвам L2 маршрутизатори, но когато намалявам МТУ не го намалявам само на интерфейса, а и в шейпъра и за това до сега съм имал само един случай на проблем с МТУ и той беше на някакъв доста стар компютър който не го детктваше автоматично и трябваше да му се зададе ръчно.
Освен това знаеш, че не е никакъв проблем в линукс рутера да махаш DF на пакети над определена големина. На интерфейсите за крайни клиенти МТУ е 1480 и нямам никакъв проблем.

Добрия Интернет струва пари!!!

Ако ти попадне от някъде 3com office connect, пробвай дали ще ти работи. След един куп такива проблеми, аз взех много просто решение - всичко е 1500 от край до край.

Митко

Да така е по лесно само, че нали се сещаш, че при скоростите които раздаваме в момента се появяват някой интелегенти с болни амбици дето взимат 1-2 Мбита от нас за 50лв и стават интернет доставчици.
Ония ден направо щях да падна от стола обажда се клиент в офиса и пита дали извършваме услги по конфигуриране на уиндолс на въпроса какво иска да му се конфигурира отговаря смело интернет конекшън шеринг да пуснел интернет на двама съседи той го бил пуснал ама нещо не работело.

Добрия Интернет струва пари!!!

Има такъв проблем, ама по-малкото mtu с какво ти помага?

Митко

Ами ако имаш време тествай какво се случва при следната опитна постановка
твой рутер с 2 влана
eth1.1 192.168.0.1
eth1.2 192.168.1.1
втори рутер
еth0 192.168.0.2 gw 192.168.1.1
eth1 10.10.10.1
clienti
До като не е пуснат NAT всичко работи пусне ли се NAT на втория 70% пакетлос.


Добрия Интернет струва пари!!!