Мистика

ominous emoticon

Я так и не понял что это такое. И проблему так и не решил, хотя сутки возился.

Дано:

  1. Есть некий хост, назовем его условно хост A. На хост A пытается осуществлять доступ мой сервер, осуществляющий также роутинг с NAT на локальную сеть и обвешанный файрволлом1. Сервер имеет «белый» статический ipv4, ipv6 через 6to4, и еще несколько openvpn в довесок. Локальная сеть воткнута непосредственно в сервер с противоположной стороны. Хост A имеет только ipv4 и находится где-то в Канаде.
  2. Машины внутри локальной сети успешно пингуют хост А и создают TCP-соединения к хосту А – в первую очередь, нормально открывают его по http.
  3. Сервер успешно пингует хост А, но по какой-то причине попытка создать TCP-соединение не удается, в смысле что ответ на него никогда не приходит.
  4. Внимание, важный момент: Ни для каких хостов, кроме одного конкретного хоста А, описанное здесь поведение не наблюдается. Все остальное открывается без запинки. Никаких особенных websockets там, или прочей ерунды на хосте A нет, а если бы и были, они мне не нужны, обыкновенный вебсайт.

Задача:

Найти грабли.

Дополнительные сведения:

  1. Ситуация абсолютно не меняется вне зависимости от того, есть в файрволле список блэклистов или нет. Ситуация не меняется если прибить hosts.deny или дописать хост A в hosts.allow. Я уж молчу про то, что wget игнорирует hosts.deny/allow.
  2. Ситуация абсолютно не меняется, если поднять на сервере еще один openvpn, скажем, до FrootVPN, и зароутить хост A сквозь него. Клиенты в локалке видят, что у них изменился пинг, и что трейсрут исходит звездочками, но открывают http, сервер нет.
  3. Ситуация не меняется, если вместо FrootVPN в той же роли применить vpn поднятый самостийно на VPS в Европе, который сам успешно открывает хост A.
  4. Нигде в конфигах по всей системе хост A не встречается ни в виде своего доменного имени, ни в виде IP-адреса, и повода предположить что хоть кто-нибудь относится к нему как-то особенно нет.
  5. IP-адрес полученный на это имя совпадает на всех системах упомянутых выше и вообще проверен через DNSCrypt.
  6. tshark показывает что пакеты уходят, и ответы на пинги приходят. А ответы на tcp-соединение не приходят…
  7. И для справки, telnet, curl и wget полностью солидарны и ведут себя одинаково.

Самый очевидный вариант, «Они забаррикадировались от меня лично с той стороны» – отпадает, в основном, за счет пункта 3, потому что на момент установления TCP-соединения через openvpn никаких способов идентифицировать конкретную машину как источник запроса не существует.

Временно я обошел проблему, просовывая запросы к хосту A через sixx.org, даром что ipv6 работает, но где, черт подери, эти грабли?


  1. Для генерации iptables-файрволла применяется firehol. ↩︎