Linux за българи: Форуми

Здравейте,

значи имам следната ситуация... На един от сървърите ни сме качили софтуер, който работи на даден порт (примерно порт 5000) и ползва UDP протокола, но по трасето, доста от междинните станции са си затворили този порт. Имали някакъв начин да се преодолее това?

Бъди по-подробен. Според предназначението на софтуера е възможно да се налага използване на някаква тънкост. Ето, все пак, основните ми предложения:
1. Разгледай подробно дали няма настройка на този софтуер кой порт да използва и, ако има, го промени.
2. Ако няма такава настройка, следват два подслучая
а) този софтуер слуша за входящи конекции на порт 5000. Тогава пренасочваш някой друг порт, който е позволен, да отвежда конекциите към порт 5000 с командата
iptables -t nat -I PREROUTING 1 -p udp -i eth0 --dport 4000 -j DNAT --to 111.222.333.444:5000
където eth0 и 111.222.333.444 са съответно интерфейса и IP-то на картата, която е вързана към Интернет, а 4000 и 5000 са съответно позволения и непозволения порт. Тогава хората отвън ще трябва да се свързват към порт 4000, вместо към порт 5000, на който всъщност слуша софтуера.
б) този софтуер прави изходящи конекции нанякъде навън по порт 5000. Хмм... нещо нямам идея за момента за този вариант.

Все пак бъди по-подробен! Или е секретно?  

Навремето OpenVPN работеше на 5000 udp, но вече имат стандартизиран порт 1194 и в последните версии е по подразбиране. Та навремето го бях пуснал на 5001, задава се в  конфиг файла.

Да това за смяната на порта ще свърши работа, но имали някакъв начин да проследя какво се случва с затворения порт и защо и къде може да е затворен?

5000 се ползвал за някакво pnp в windows ХР. Имаше някаква уязвимост, която после беше закърпена..., но как да разбереш кой го спира ...  

Ако е забранен на някой рутер, принципно блокирането на UDP портове се прави с правило, което връща ICMP грешка, хостът върнал грешката е виновникът. Тъй като много хора обаче тихо ги DROP-ват, върви разбери какво става. UDP протоколът не гарантира някаква обратна комуникация, примерно като пратиш SYN да ти се върне SYN-ACK или RST, така че дали е приет отсреща или издропен нямаш голяма гаранция.

Има все пак начин да се разбере кой ти discard-ва тихо пакетите. Хващаш hping3 или нещо от сорта и почваш да пускаш до хоста UDP пакети с нужния дест. порт. Първо с TTL=1, после 2,3 и т.н. В момента в който се окаже че някой не ти връща ICMP TTL exceeded, то пакетът или е достигнал до целта си, или предпоследният (TTL-1) хоп го е издропил. Всичко това при положение че някой малоумник не е хванал да реже ICMP пакетите, които рутира. Защото и такива ненормалници има.

Обикновено можеш да REJECT-неш, като върнеш пакета с друг source. Правил съм го за пробата със source gateway-a

Иначе аз съм от тези ненормалници, които са резнали целия ICMP Параноя, бейбе !

Не искам да ставам като оня Весо дето се кара на "е-простаците", ама това наистина е леко българска работа

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

Мм да наистина е много трудно да се хване нещо такова на UDP, ужас!

Ма това за домашна употреба ли е? Ааа, така кажи, това оправдава всякакви експерименти Този твоят рутер НАТ-ва ли или не? Щото ако само forward-ва е малко кофти...Иначе, идват ми наум отсега няколко потенциални проблема на едно такова решение:

Ако имаш някакъв сайт или ftp услуга или квото и да било, което слухти зад рутера ти, на повечето клиенти с pppoe връзка, които се опитват да го достъпят ще им се случат случки, заради счупено PMTU discovery. Проблемите се задълбочават леко при UDP комуникациите, щото там няма и MSS. Така че например дори ако става въпрос за домашен рутер (не NAT-ващ, само forwarding), тогава ей така заради параноята ще си дърпаш торънтите по-бавно например, а сума ти клиенти, например на megalan, ще има да се чудят как така се връзват с теб, пък почти никакъв трансфер на данни няма

Като страничен  ефект, ще превърнеш UDP сканиранията отвън към машина зад рутера в кошмар, ма то тва е хубав страничен ефект де Ще строшиш всеки ping или traceroute, изпълнен от машинка зад рутера до навънка (и обратно).  Ще вгорчиш донякъде живота на хората, които ползват nmap зад рутера ти до навън. Ще увеличиш времето, за което някой клиент разбира дали това до което се връзва е филтрирано или не (стига да е филтрирано като хората). Понякога, това е гадно (ако например първият resolver на клиентът ти е сдал багажа, докато се сети да ползва втория ще трябва да чакаш timeout-a)

Абе не е точно баш за домашни експерименти...

Той си е pfSense from scratch, но с някои екстри Pf-то спира и hping при правилна настройка, tracepath може да си върви ако поискаш. Максималният размер на сегмента не би трябвало да ни бърка - всички адреси (4 на брой) са с MTU-40, поради IPv4. Проблеми с торентите нямам - 1.5~2MB/s dl.

Иначе resolver-ът сдаде ли багажа, си има OpenDNS. При публичен адрес (адреси) това е манна небесна - докато чакаш рестарта на DNS-а на ISP-то ти, вече си отворил сайтовете

Edit: ето ти нещо бързо и лесно за network boot-a
http://vamosproject.org/InternetBoot

Ммм то hping не прави някакви специални фокуси, прави каквото му кажеш в общи линии..

Оказа се, че още на първата инстанция ме режат и май доста играчка ще е с това нещо Бях се сетил за проследяване по тоя начин. Правя трасиране да видя пътя до сървъра и след това опит за тест на отворен порт за всяка инстанция. Но това също ще е проблем, някой ако е резнал трасиранията и ICMP-тата....

smelkomar, по-лоши неща стават при flood с големи пакети с много ниско MTU, ако трябва да се мислят лоши идеи де

gat3way, какво ще рече "големи пакети с много ниско MTU"

Ми такива с големина 32000 например, разбити на фрагменти по 100 байта. В hping има нещо наречено "виртуално MTU", което не е задължително еквивалентно на MTU-то на интерфейса. Спрямо него, пакетите се "разбиват" на такива фрагменти, със съответните "more fragments" флагове вдигнати.

Като резултат, получателят се затормозява да ги сглобява, което заема ресурсите му.

Е, всъщност през IP слоя трябва да чакаш докато интерфейса сглоби оригиналната datagram-a. То всъщност това е първото, което се усеща. Тъй де...