💾 Archived View for r2aze.observer › archive › 2015-01-22-mystical.gmi captured on 2022-07-16 at 13:45:04. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2022-06-03)

-=-=-=-=-=-=-

Мистика

📅 2015-01-22

📑 Tech

🏷 #linux

🏷 #firewall

🏷 #routing

🏷 #mystery

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

Дано:

1. Есть некий хост, назовем его условно _хост A._ На хост _A_ пытается осуществлять доступ мой сервер, осуществляющий также роутинг с NAT на локальную сеть и обвешанный файрволлом¹. Сервер имеет «белый» статический ipv4, ipv6 через [6to4], и еще несколько [openvpn] в довесок. Локальная сеть воткнута непосредственно в сервер с противоположной стороны. Хост _A_ имеет только ipv4 и находится где-то в Канаде.

2. Машины внутри локальной сети успешно пингуют хост _А_ и создают TCP-соединения к хосту _А_ – в первую очередь, нормально открывают его по http.

3. Сервер успешно пингует хост _А,_ но по какой-то причине попытка создать TCP-соединение не удается, в смысле что ответ на него никогда не приходит.

4. Внимание, важный момент: Ни для каких хостов, кроме одного конкретного хоста _А,_ описанное здесь поведение не наблюдается. Все остальное открывается без запинки. Никаких особенных websockets там, или прочей ерунды на хосте _A_ нет, а если бы и были, они мне не нужны, обыкновенный вебсайт.

┄┄

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

firehol

6to4

openvpn

Задача:

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

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

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 полностью солидарны и ведут себя одинаково.

FrootVPN

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

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

sixx.org

✏️ View and leave comments

◀️ 2015-01-09: Dododo

⬅️ Tech: Огульное программирование

➡️ Tech: The Sliding Lower Bound

▶️ 2015-02-16: The Sliding Lower Bound

↩ Home

© 2001-2022 Eugene Medvedev. All rights reserved, not like that ever stopped anyone, or means anything when not backed up by a corporation.