LINUX.ORG.RU
Форум — Admin  

Apache за NAT (проблема доступа)

 


1

1

Имеется сеть построенная на механизме NAT, lan:192.168.1.1/24, wan:xx.yy.xx.yy.

Во внутренней сети по адресу 192.168.1.22 стоит apache2 (Debian), на шлюзе стоит проброс xx.yy.xx.yy:zzzz на 192.168.1.22:8080, прописывалось не мной, доступа к шлюзу у меня нет.

При попытке подключиться из локальной сети (192.168.1.62) я вижу index.html, при попытке подключиться из интернета (88.34.35.11) пустой экран.

Насколько мне известно (на основе man iptables), TCP соединение устанавливается за 3 шага, SYN_RECV - показывает, что пакет из интернета миновал шлюз и пришел на 192.168.1.22, но ответ на этот пакет веб сервер отправить не может, почему - мне не известно, хотел бы попросить помощи у сообщества. Понять вывод tcpdump я не смог :(

tcpdump: http://pastebin.com

ports.conf http://pastebin.com

apache2.conf http://pastebin.com

netstat -na |grep :8080

tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN     
tcp        0      0 192.168.1.22:8080       88.34.35.11:57900     SYN_RECV   
tcp        0      0 192.168.1.22:8080       192.168.1.62:51876      ESTABLISHED
tcp        0      0 192.168.1.22:8080       192.168.1.62:51877      ESTABLISHED

iptables --lsit

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination


Последнее исправление: cetjs2 (всего исправлений: 1)
← ACL на основе DynList'ов не работают
Настройка гарантированной доставки почты. →

Понять вывод tcpdump я не смог :( 

03:20:51.680019 IP 88.34.35.11.57925 > webserver.http-alt: Flags [S], seq 3794393729, win 8192, options [mss 1380,nop,nop,sackOK], length 0
03:20:51.680053 IP webserver.http-alt > 88.34.35.11.57925: Flags [S.], seq 4294584096, ack 3794393730, win 14600, options [mss 1460,nop,nop,sackOK], length 0
03:20:51.680173 IP webserver.47283 > 192.168.1.1.domain: 32070+ PTR? 11.35.34.88.in-addr.arpa. (45)
03:20:51.696059 IP 88.34.35.11.57925 > webserver.http-alt: Flags [.], ack 2898677489, win 64240, length 0

порт-форвардинг работает, вот соединение установилось... но потом: 

03:20:51.696074 IP webserver.http-alt > 88.34.35.11.57925: Flags [R], seq 2898294289, win 0, length 0
А имя у сайта есть? а то если вы к нему обращаетесь по IP, то он и не должен знать как ответить на GET <ip роутера>

naszar ★
()
Последнее исправление: naszar (всего исправлений: 1)
Ответ на: комментарий от naszar

А имя у сайта есть?

Не совсем понимаю какое имя именно, внутренний dns адрес, внешнее dns имя, имя виртуального хоста?

из интернета обращаюсь по real_name.ru:zzzz; из локальной сети по 192.168.1.22:8080

/etc/hosts

127.0.0.1       localhost
127.0.0.1       real_name.ru
192.168.1.22    real_name          real_name.ru

/etc/apache2/sires-available/default

<VirtualHost *:8080>
        ServerAdmin webmaster@localhost

        DocumentRoot /var/www
        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride None
                Order allow,deny
                allow from all
        </Directory>

        ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
        <Directory "/usr/lib/cgi-bin">
                AllowOverride None
                Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
                Order allow,deny
                Allow from all
        </Directory>

        ErrorLog ${APACHE_LOG_DIR}/error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
aseco
() автор топика
Ответ на: комментарий от aseco

Понятно, просто в первом сообщении не было сказано есть ли дефолтный виртуалхост. Давайте логи апача глянем?

/etc/apache2/sires-available/default - это у вас опечатка, или у директория неправильное имя?

naszar ★
()
Последнее исправление: naszar (всего исправлений: 3)
Ответ на: комментарий от naszar

Опечатка, набирал руками

other_vhosts_access.log - пуст

в error.log только:

[Sat Feb 22 04:58:36 2014] [notice] caught SIGTERM, shutting down
[Sat Feb 22 04:59:21 2014] [notice] Apache/2.2.22 (Debian) configured -- resuming normal operations

В access.log только:

192.168.1.62 - - [22/Feb/2014:03:20:47 +0400] "GET / HTTP/1.1" 304 209 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36"
192.168.1.62 - - [22/Feb/2014:03:39:24 +0400] "GET / HTTP/1.1" 304 209 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36"
192.168.1.62 - - [22/Feb/2014:05:00:33 +0400] "GET / HTTP/1.1" 200 364 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36"
aseco
() автор топика
Ответ на: комментарий от aseco

Похоже, до апача запрос не доходит. Хотя tcp соединение устанавливается. Посмотрите внимательно правила netfilter (вы показали только таблицу filter;нужно чтонибудь типа iptables-save). Опишите подробно топологию сети: где апачь и откуда сняты дампы трафика (ресет идет от чего-то, что после машины с которой снимались дампы). Полностью исключить апачь, можно подвесив вместо него netcat и установив с ним соединение из внешней сети при помощи другого netcat'a.

naszar ★
()
Ответ на: комментарий от aseco

Возможно у вас где-то в iptables написано -j REJECT --reject-with tcp-reset.. надо поискать его на машинах после той с которой снимался дамп трафика.

naszar ★
()
Ответ на: комментарий от aseco

Если пакостящее правило не найдете, поймайте трафик к апачу вот так: 

tcpdump -i <интерфейс> host <откуда> and tcp port 8080 -w exp.cap

<интерфейс> - где будем ловить пакеты <откуда> - внешний адрес с которого пробуете подключится (в вашем дампе был 88.34.35.11)

Создастся файл exp.cap, его можно открыть wireshark'ом, ибо разбирать каракули tcpdump'a - это издевательство. Возможно, ядру что-то не нравится в параметрах tcp/ip и оно сбрасывает соединение. Основной смысл - увидеть как проходит хэндшейк и что происходит потом, вплоть до момента когда ваш сервер посылает RESET.

Кстати немного интересного уже видно: у сервера просят [mss 1380,nop,nop,sackOK], а он отвечает [mss 1460,nop,nop,sackOK]. В локалке такого явления не наблюдается. Возможно проблемма с MTU.. кстати, как роутер подключается к интернету? Не через vpn?

naszar ★
()
Последнее исправление: naszar (всего исправлений: 1)
Ответ на: комментарий от naszar

tcpdump делался с 192.168.1.22 

iptables-save

# Generated by iptables-save v1.4.14 on Sat Feb 22 06:49:14 2014
*filter
:INPUT ACCEPT [1574:142711]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [897:56896]
COMMIT
# Completed on Sat Feb 22 06:49:14 2014

установить «чат» внутри 192.168.1.1/24 удалось, из интернета - нет (так же висит SYN_RECV)

доступа к шлюзу у меня нет :(

картинка--топология

aseco
() автор топика
Ответ на: комментарий от aseco

Ловите пакеты, так, чтобы их можно было в варешарке почитать. Если поймаете одно соединение, как оно выглядит со стороны 192.168.1.22 и 88.34.35.11 будет замечательно. Фаервол отпадает, апачь отпадает, остаются только проблемы с настройкой сети. Возможно в сети провайдера или на роутере с пакетами делается что-то нехорошее (в смысле меняются).

Если боитесь показать лишнего вот вам статейка как фильтры писать. Еще в варешарке можно сохранять только определенные пакеты.

naszar ★
()
Ответ на: комментарий от aseco

Вы еще про TCP посмотрите. Точно не скажу, но помоему тут немного не правильно: 

03:20:51.680053 IP webserver.http-alt > 88.34.35.11.57925: Flags [S.], seq 4294584096, ack 3794393730, win 14600, options [mss 1460,nop,nop,sackOK], length 0
03:20:51.696059 IP 88.34.35.11.57925 > webserver.http-alt: Flags [.], ack 2898677489, win 64240, length 0
Сдается мне, что клиент должен был послать ack 4294584098.. но не уверен. Проблема точно в том, что сервер отвечает на этот пакет ресетом: 
03:20:51.696074 IP webserver.http-alt > 88.34.35.11.57925: Flags [R], seq 2898294289, win 0, length 0
По хорошему нам нужны эти четыре пакета(syn от клиета, syn-ack от сервера, ack от клиента и rst от сервера) как их видят обе стороны и полностью. Нужно внимательно глянуть на опции и флаги tcp, тогда станет ясно почему сервер шлет ресет. Повторюсь, возможно что-то между клиентом и сервером меняет пакет (точно DNAT переписывает адрес). Поэтому желателен и дамп со стороны 88.34.35.11 (ввиду наличия подлых личностей желательно поменять IP'шник сервера в .pcap файле hex редактором, иначе вас начнут проверять на прочность).

Если короче, надо понять, что нелюбо ядру сервера в последнем ack'e клиента.

naszar ★
()
Ответ на: комментарий от aseco

Проверил, третий пакет от клиента должен был выглядеть в tcpdump так: 

03:20:51.696059 IP 88.34.35.11.57925 > webserver.http-alt: Flags [.], ack 1, win 64240, length 0
Возможно что-то не так с sequence number( единица это не то, что в пакете на самом деле, а просто tcpdump так пишет для удобства).

naszar ★
()
Ответ на: комментарий от aseco

Дамп со стороны клиента не нужен. Просто сами сравните Acknowledgment number и Sequence number в пакетах на стороне клиента и сервера. Совпадают или нет?

naszar ★
()
Ответ на: комментарий от aseco

Давайте с начала, и прошу прощения что я не заметил эту странность сразу. Имеем пять пакетов: 

03:20:51.680019 IP 88.34.35.11.57925 > webserver.http-alt: Flags [S], seq 3794393729, win 8192, options [mss 1380,nop,nop,sackOK], length 0
03:20:51.680053 IP webserver.http-alt > 88.34.35.11.57925: Flags [S.], seq 4294584096, ack 3794393730, win 14600, options [mss 1460,nop,nop,sackOK], length 0
03:20:51.696059 IP 88.34.35.11.57925 > webserver.http-alt: Flags [.], ack 2898677489, win 64240, length 0
03:20:51.696074 IP webserver.http-alt > 88.34.35.11.57925: Flags [R], seq 2898294289, win 0, length 0
03:20:51.696813 IP 88.34.35.11.57925 > webserver.http-alt: Flags [P.], seq 1:594, ack 2898677489, win 64240, length 593
Обзовем их syn_1,syn_ack_2,ack_3,rst_4,data_5. 1,3,5 пакеты от клиента к серверу; 2 и 4 - от сервера к клиенту.

На данный момент нас интересует ack_3 и конкретно значение поля Acknowledgment number. Нам нужно сравнить поля Sequence number и Acknowledgment number во всех пяти пакетах на клиенте и на сервере (можно посмотреть в варешарке: тыкаете соотв. поле и внизу, где шестнадцатеричный дамп пакета, подсветиться 4 байта). Возможно какое-то поле модифицируется в процессе передачи пакета. Если это так, то надо понять где это происходит: на участке сети от клиента до выхода из провайдера, в роутере или на вашей машине ( у вас вроде виртуалка?).

Исключить проблемы с сервером вы можете, выключив его и прописав его адрес на машине у которой сейчас 192.168.1.62.. назначте ей 192.168.1.22, подвесте неткат(есть под винду) на 8080 и устройте чатик с клиентом из интернета.

Кстати как у сервера с интернетом? Исходящие подключения устанавливаются? Как с интернетом у клиента, работает?

naszar ★
()
Ответ на: комментарий от naszar

dump

syn_1: 
Sequence number = 47 41 ca 36

syn_ack_2:
Sequence number = 41 9d 33 cf
Acknowledgment number = 47 41 ca 37

ack_3:
Sequence number = 47 41 ca 37
Acknowledgment number = 1e be a6 5f

rst_4:
Sequence number = 1e be a6 5f

Попробовал nc подключение с другой машины c указанием 192.168.1.22 (Windows, не виртуалка) с записью дампа с обеих сторон

Как выглядит внешне: ожидание секунд 5 и программа сервера закрывается. При нескольких запусках, выяснилось, что если на клиенте сразу при подключении напечатать текст, то в итоге он дойдет до сервера, но сервер завершает работу через ~5c.

При сравнении пакетов на клиенте и на сервере можно заметить, что SYN, SYN_ACK одинаковые, а АСК(от машины из интернета к 192.168.1.22) имеет разные значения(на сервере и клиенте) Acknowledgment number, после этого идет TCP RETRANSMISSION (Раз 5) и RST

Такое сравнение проводил с разных компьютеров, с разными провайдерами.

если проблема повторяется с разных провайдеров => проблема в сети 192.168.1.0/24 или в сети её провайдера, но вот у кого конкретно?

aseco
() автор топика
Ответ на: комментарий от aseco

АСК(от машины из интернета к 192.168.1.22) имеет разные значения(на сервере и клиенте) Acknowledgment number

Вот тут и кроется корень зла. Я предполагаю, что на клиенте значение правильное(Acknowledgment number(ack_3) = Sequence number(syn_ack_2) + 1). Подмена может происходить в сети провайдера (возможно, провайдер запрещает входящие соединения на определенные порты своих абонентов.. хотя это весьма странный способ, возможно это просто неполадки), в роутере (нат иногда может лазать внутрь пакетов, хотя в данном случае явно баг), в свитче (невозможно, ибо он работает на канальном уровне, но случай у вас весьма необычный, думаю стоит проверить все варианты).

В любом случае вам стоит обратиться к человеку обслуживающему роутер и к провайдеру. Если есть возможность подключится к провайдеру в обход роутера, то можно исключить провайдера, проверив правильность значения Acknowledgment number в ack_3.

Чтобы вы смогли объяснить поддержке провайдера и администратору роутера, что происходит посмотрите RFC 793 (гуглятся руские переводы). Можно пролистать сразу к

3.4. Establishing a connection

Отправка RST в ответ на пакеты с неправильными ACK'ами в RFC называется «recovery from old duplicates». В вашем случае это не старые пакеты, а кто-то по ошибке подменяет значение поля в заголовке tcp.

naszar ★
()
Ответ на: комментарий от naszar

success story

Проблема решилась, загвоздка была в настройках шлюза.

Благодаря топику открыл для себя netcat и немного стал понимать то, что пишет tcpdump, WireShark & etc.

Спасибо naszar за помощь!

aseco
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← ACL на основе DynList'ов не работают
Admin
Настройка гарантированной доставки почты. →