shorewall при устранении неполадок с прокси-сервером Debian
Настройка: прокси-сервер 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>
3 ответа
Какой хост установлен как шлюз по умолчанию на вашем сервере Ubuntu? Если это не ваш прокси-сервер Debian, вы должны добавить другое правило в /etc/shorewal/masq:
eth1:192.168.1.128 0.0.0.0/0 192.168.1.137 tcp 80
Я предполагаю, что ваша сетевая карта прокси-сервера Debian является eth1, а IP-адрес сервера Debian - 192.168.1.137. По сути, проблема в том, что правило DNAT не изменяет исходный IP-адрес в переадресованных пакетах, поэтому ваш сервер Ubuntu пытается напрямую ответить на источник запроса, который находится за пределами вашей локальной сети. Для связи он использует шлюз по умолчанию, поэтому ответ никогда не попадает в окно Debian. Это дополнительное правило изменяет исходный IP-адрес на IP-адрес самого прокси-сервера, поэтому оно должно помочь. В любом случае, вероятно, это не то, что вам нужно, потому что Apache в Ubuntu будет записывать IP-адрес Debian в качестве IP-адреса клиента для доступа к журналам для каждого запроса.
Прежде всего, я предполагаю, что знак # перед каждым правилом нет файлов конфигурации (он комментирует эту строку, делая его бесполезным).
Попробуйте отслеживать сетевой трафик на прокси-сервере на обоих интерфейсах, публичном и частном. На общественной стороне:
# 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
(again, if nothing meaningfull comes up on FORWARD, check net2loc).
If this doesn't return a line (and policy is REJECT / DROP) then you are missing the rule that allows you to forward traffic... double check shorewall configuration. Установить loc log to info on the policy configuration file, force a rule:
iptables -A net2loc -i <public iface> -o <private iface> \
--dst 192.168.1.128 -p tcp --dport 80 -j ACCEPT
And see what happens.
The alternative, when making requests from an external location, and you see it on the private side, that would mean that something else is wrong (check the linksys router forwarding policy, routes, etc).
I wouldn't do what @Alex recomends as it is risked. You loose every trace of who is accessing you service therefore you loose statistics. If there is any attack on your site, it is impossible to determine where is it comming from by just looking at your webserver logs, and lots of other reasons. Обычно SNAT from public networks to private destinations is highly discouraged.
Ладно, похоже, что теперь все происходит немного по-другому:
Теперь я просто захожу в прокси Debian -> 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)
Спасибо всем за помощь, я использовал все, что было размещено здесь, чтобы прийти к тому, что я надеюсь, является приемлемым решением.