Подскажите, в какие места надо бить админа, если маршрутизация поломана

помоги админу помочь тебе - сообщи об обнаруженной проблеме кратно, чётко, вежливо. Не вдавайся в подробности того, как и что следует админу делать, админ в этом вопросе он, а не ты.

меня белый IP, и я спокойно могу достучаться до любого хоста в мире. А вот любой хост в мире не может достучаться до меня

а TCP-сессии устанавливаются? От тебя, естественно.

> админ в этом вопросе он, а не ты.

Бывают и админы саботажники. Итальянская забастовка.

Скажем, в договоре ip есть - вот он, а доступ извне в договоре к примеру не упомянут, и что без этого и ip не имеет смысла - всё равно.

> помоги админу помочь тебе - сообщи об обнаруженной проблеме кратно, чётко, вежливо. Не вдавайся в подробности того, как и что следует админу делать, админ в этом вопросе он, а не ты.

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

От себя TCP-сессии устанавливаются, а то. Как иначе я сюда пишу?

> Скажем, в договоре ip есть - вот он, а доступ извне в договоре к примеру не упомянут, и что без этого и ip не имеет смысла - всё равно.

Не, здесь, по-моему, круче.

«Согласно договору, мы предоставляем вам доступ к интернету. В договоре нигде не прописано, что при этом интернет получает доступ к вам!»

пообщайтесь с начальством админа, а лучше тисните официальную бумажку, сразу зашевелятся ;-)

есть ли возможность послушать входящий не-ICMP трафик? Посмотреть, есть ли входящие снаружи SYN-ы по различным портам?

если этого нет - значит они выпиливают трафик. Это уже айайай, и «интернет к вам» тут, ИМХО, не подойдут в качестве оправдания.

Получается что-то в виде

Забавно :)

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

И второй, об альтернативе.

Злобный одмин наверное сделал что-то вроде:
iptables -I FORWARD -d твой-айпи -m state --state NEW -j DROP

А с маршрутизацией у него всё в порядке. Ответные пакеты же до тебя как-то доходят.

у него входящие ICMP-пакеты на внутреннюю сеть переправляются на аплинка, это «всё в порядке»?

spunky> ICMP-пакеты

А почему вы думаете что это ICMP? Мусье виндузятник?

Каюсь, не внимательно прочитал. Но тогда не понятно почему ответные пакеты в уже установленных соединениях не зацикливаются.

Выборочная маршрутизация по состоянию (флагам) пакета? Или такая лажа только с ICMP? (это уже вопрос к ТС)

> есть ли возможность послушать входящий не-ICMP трафик? Посмотреть, есть ли входящие снаружи SYN-ы по различным портам?

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

Если админ провайдера где-то раньше на местном форуме сообщал мне, что он multipath реализовывает с помощью двух команд iptables (!), одна из которых почему-то -m limit --limit-burst 1, то либо я чего-то не понимаю в устройстве ядра, либо не исключено, что он мог сделать

iptables -I FORWARD -d твой-айпи -m state --state NEW -j DROP

совершенно не ведая, что творит.

c внешки пропускает только ESTAB пакеты

о, отличная идея! Попробовать чем-то вроде hping-а сгенерировать TCP-пакет с ACK, но без SYN, или вообще без флагов. Можно будет определить, отслеживает ли провайдер именно установку соединений. Побольше бы фактов, побольше экспериментальных данных.

Как я понимаю, айпишники вы привили фейковые. И не понятно, как у вас там устроена сеть и занимается в ней ли Линукс маршрутизацией. Может эти приколы какой железяки и почему тред скатился к обсуждению правил iptables?

Настоящие, настоящие.

Это по меньшей мере странно. У меня (Екатеринбург, провайдер УралВЭС) трейс на 194.44.13.90 не идёт вобще, то есть не доходит даже до Москвы, может он как то криво проанонсирован и BGP его не видит. Спрошу в понедельник.

Трейсы до 95.215.156.29 и 194.44.136.193 идут разными путями:

 8  po2-20G.ar4.FRA3.gblx.net (67.16.133.34)  69.407 ms  69.180 ms  69.475 ms
 9  ge-6-11.car2.Frankfurt1.Level3.net (195.122.136.245)  74.627 ms  127.407 ms  74.568 ms
10  ae-3-89.edge3.Frankfurt1.Level3.net (4.68.23.139)  107.900 ms  74.893 ms  74.634 ms
11  95.215.156.29 (95.215.156.29)  100.657 ms  101.045 ms  100.680 ms

 6  GW-TransTeleCom.retn.net (87.245.247.30)  30.968 ms  31.317 ms  31.035 ms
 7  ae3-196.RT.NTL.KIV.UA.retn.net (87.245.247.29)  52.833 ms  53.282 ms  52.753 ms
 8  GW-UARNet.retn.net (87.245.247.22)  53.819 ms  53.609 ms  52.766 ms
 9  194.44.136.193 (194.44.136.193)  63.195 ms  63.553 ms  63.233 ms

А whois на 95.215.156.29 посмотрите сами.

Лучше всего трейс смотреть сразу на www.ris.ripe.net тогда многие вопросы автоматически отпадают.

> Трейсы до 95.215.156.29 и 194.44.136.193 идут разными путями:

У меня (Екатеринбург, провайдер УралВЭС) трейс на 194.44.13.90 не идёт вобще, то есть не доходит даже до Москвы

194.44.13.90 и не может у тебя видеться. Это гейт в UA-IX, сугубо украинскую трафикообменную сеть (которая возникла, когда интернеты за рубеж были тоненькими и дорогими шописец — помню, провайдеры выставляли одно время разные цены на украинский и мировой трафик, сегодня только по пропускной способности различия есть).

Проблема решилась сама по себе, когда сессия PPPoE передернулась и мне был выдан адрес из другого совершенно пула — туда маршруты прописаны уже правильно.