Настройка такова: прокси-сервер debian -> маршрутизатор linsys -> внутренний сервер ubuntu
Проблема в следующем: Я могу получить доступ к веб-серверу ubuntu (apache2), введя 192.168.1.128 в браузере на моем прокси-сервере debian. Однако мое правило переадресации shorewall не позволяет использовать одно из следующих правил:
#Web/DNAT net loc:192.168.1.128
#DNAT net loc:192.168.1.128:80 tcp 80 - 70.90.XXX.XX
Дополнительная информация:
У меня есть внутренний сервер ubuntu, принимающий все соединения прямо сейчас для целей отладки (также установлен shorewall)
вырезан из вывода 'shorewall show log' (на машине debian):
Feb 1 19:37:15 fw2loc:ACCEPT:IN= OUT=eth1 SRC=192.168.1.137 DST=224.0.0.251 LEN=104 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=84
Feb 1 19:40:31 fw2loc:ACCEPT:IN= OUT=eth1 SRC=192.168.1.137 DST=224.0.0.251 LEN=104 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=84
вывод 'shorewall show nat' (на машине debian):
Chain PREROUTING (policy ACCEPT 235 packets, 74689 bytes)
pkts bytes target prot opt in out source destination
12 724 net_dnat all -- eth0 * 0.0.0.0/0 0.0.0.0/0
Chain POSTROUTING (policy ACCEPT 8 packets, 670 bytes)
pkts bytes target prot opt in out source destination
3 242 eth0_masq all -- * eth0 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 7 packets, 611 bytes)
pkts bytes target prot opt in out source destination
Chain eth0_masq (1 references)
pkts bytes target prot opt in out source destination
1 69 MASQUERADE all -- * * 192.168.1.0/24 0.0.0.0/0
Chain net_dnat (1 references)
pkts bytes target prot opt in out source destination
2 128 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 to:192.168.1.128
0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 to:192.168.1.128
РЕДАКТИРОВАТЬ:
Я также должен упомянуть, что после проверки журналов apache на машине ubuntu, похоже, ни один из запросов не выполняет его. Когда я делаю запрос из локальной сети, я получаю запись в журнале доступа, но когда я делаю запрос извне через прокси, я ничего не получаю.
Вывод iptables -vnL на прокси:
22 1280 TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
22 1280 eth0_fwd all -- eth0 * 0.0.0.0/0 0.0.0.0/0
22 1280 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW
22 1280 smurfs all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW
22 1280 tcpflags tcp -- * * 0.0.0.0/0 0.0.0.0/0
22 1280 net2loc all -- * eth1 0.0.0.0/0 0.0.0.0/0
1 60 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 80,443
22 1280 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.128 tcp dpt:80
Не совсем уверен, что с этим делать ...
Я начинаю задаваться вопросом, есть ли фундаментальная проблема с попыткой пройти через маршрутизатор Linksys, и должен ли я просто перейти на debian -> ubuntu с кроссовером ...
РЕДАКТИРОВАТЬ 2
Похоже, пакеты пересылаются правильно (я думаю, именно это и сделал для нас вывод shorewall show nat)
Вывод из 'tcpdump -n -i port 80'
публичный интерфейс:
20:15:40.458118 IP 71.182.212.251.57261 > 70.90.XXX.XXX.80: S 2834662754:2834662754(0) win 65535 <mss 1452,nop,wscale 3,nop,nop,timestamp 25163236 0,sackOK,eol>
частный интерфейс:
20: 15: 45.405347 IP 71.182.212.251.57261> 192.168.1.128.80: S 2834662754: 2834662754 (0) выигрыш 65535
После нескольких из вышеперечисленных пакетов он превращается в:
20:16:17.623882 IP 71.182.212.251.57254 > 70.90.XXX.XXX.80: S 1673429824:1673429824(0) win 65535 <mss 1452,sackOK,eol>
и
20:16:17.623917 IP 71.182.212.251.57254 > 192.168.1.128.80: S 1673429824:1673429824(0) win 65535 <mss 1452,sackOK,eol>
Прежде всего, я предполагаю, что знак # перед тем, как каждое правило отсутствует в файлах конфигурации (комментирует эту строку, что делает ее бесполезной).
Попробуйте отслеживать сетевой трафик на прокси-сервере на обоих интерфейсах, публичном и частном. С публичной стороны:
# tcpdump -n -i <public interface> port 80
На частной стороне:
# tcpdump -n -i <private interface> port 80 and host 192.168.1.128
При выполнении запросов из внешнего мира вы не видите трафика на частной стороне, тогда вам следует дважды проверить:
Ядро позволяет пересылать трафик (должно быть одно):
cat /proc/sys/net/ipv4/ip_forward
Если он возвращает 0:
echo 1 > /proc/sys/net/ipv4/ip_forward
Политика по умолчанию для FORWARD цепочка на фильтровальном столе
iptables -nL | grep 'Chain FORWARD'
(согласно предоставленной вами информации, вместо FORWARD вы должны увидеть его в цепочке net2loc)
Если политика по умолчанию - REJECT / DROP, найдите правило в цепочке FORWARD, которое позволяет перенаправлять трафик на HTTP-сервер:
iptables -vnL FORWARD | grep 192.168.1.128
(опять же, если в FORWARD ничего значимого не появляется, проверьте net2loc).
Если это не возвращает строку (и политика REJECT / DROP), значит, вам не хватает правила, которое позволяет вам пересылать трафик ... дважды проверьте конфигурацию shorewall. Установить loc войти в info в файле конфигурации политики установите правило:
iptables -A net2loc -i <public iface> -o <private iface> \
--dst 192.168.1.128 -p tcp --dport 80 -j ACCEPT
И посмотрим, что получится.
В качестве альтернативы, когда вы делаете запросы из внешнего местоположения, и вы видите это на частной стороне, это будет означать, что что-то еще не так (проверьте политику пересылки маршрутизатора Linksys, маршруты и т. Д.).
Я бы не стал делать то, что @Alex рекомендует, поскольку это рискованно. Вы теряете все следы того, кто обращается к вам, и теряете статистику. Если на ваш сайт происходит какая-либо атака, невозможно определить, откуда она взялась, просто взглянув на журналы вашего веб-сервера и по множеству других причин. Обычно SNAT переход от общедоступных сетей к частным назначениям крайне не рекомендуется.
Какой хост установлен в качестве шлюза по умолчанию на вашем сервере Ubuntu? Если это не ваш проксирующий сервер Debian, вам следует добавить еще одно правило в / etc / shorewal / masq:
eth1:192.168.1.128 0.0.0.0/0 192.168.1.137 tcp 80
Я предполагаю, что ваша сетевая карта LAN прокси-сервера Debian - eth1, а IP-адрес вашего сервера Debian - 192.168.1.137. По сути, проблема здесь в том, что правило DNAT не изменяет IP-адрес источника в пересылаемых пакетах, поэтому ваш сервер Ubuntu пытается ответить напрямую отправителю запроса, который находится за пределами вашей локальной сети. Он использует шлюз по умолчанию для связи, поэтому ответ никогда не попадает в ящик Debian. Это дополнительное правило меняет исходный IP-адрес на IP-адрес самого прокси-сервера, поэтому оно должно помочь. В любом случае, вероятно, это не то, что вам нужно, потому что Apache в Ubuntu будет записывать IP-адрес Debian в качестве IP-адреса клиента для доступа к журналам для каждого запроса.
Кажется, теперь все в порядке с немного другой настройкой:
Теперь я просто перехожу Debian proxy -> Ubuntu server (больше нет маршрутизатора Linksys). В любом случае я решил не использовать маршрутизатор, потому что именно он используется в нашей офисной беспроводной сети. В любом случае наличие того, что должно быть безопасным сервером, подключенным к офисному маршрутизатору, кажется не очень умным шагом с моей стороны.
Сводка изменений:
Предоставил частным интерфейсам обеих машин статические локальные IP-адреса со следующими
iface eth0 inet static
ipaddress 192.168.1.128 #the other one got 192.168.1.137
netmask 255.255.255.255
network 192.168.1.0
перезапущенные сетевые устройства
перезапущен Shorewall
Кажется, у Shorewall все хорошо, и мои журналы apache информативны (они не просто говорят, что все запросы поступают с машины debian)
Спасибо всем за помощь, я использовал все, что было здесь опубликовано, чтобы прийти к тому, что, я надеюсь, является приемлемым решением.