No CentOS 7 Linux (atuando como LAMP - e não como "firewall / gateway") eu criei um serviço systemd personalizado para executar o Jetty incorporado na porta 8080 como usuário nobody
:
[Unit]
Description=WebSocket Handler Service
After=network-online.target
[Service]
Type=simple
User=nobody
Group=nobody
ExecStart=/usr/bin/java -classpath '/usr/share/java/jetty/*' de.afarber.MyHandler 123.123.123.123:8080
ExecStop=/bin/kill ${MAINPID}
SuccessExitStatus=143
[Install]
WantedBy=multi-user.target
No entanto, eu realmente preciso do servidor para escutar na porta 80 - para que as conexões WebSocket funcionem mesmo através de firewalls corporativos.
O documento do Jetty em Como definir o acesso à porta 80 para um usuário não raiz sugere executar o seguinte comando:
# iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
Por sorte, eu já uso o pacote iptables-services
no meu servidor dedicado e o arquivo /etc/sysconfig/iptables
atual contém:
*filter
:INPUT DROP
:FORWARD DROP
:OUTPUT ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp -m multiport --dports 25,80,443,8080 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 2/min --limit-burst 1 -j ACCEPT
COMMIT
Meu problema é que eu não sei a sintaxe PREROUTING adequada para o arquivo acima.
Eu tentei executar o comando acima e, em seguida, iptables -S
na esperança de que o iptables liste a linha necessária para mim - mas isso não aconteceu.
ATUALIZAÇÃO:
Infelizmente, o seguinte arquivo /etc/sysconfig/iptables
não funciona:
*nat
:INPUT ACCEPT
:OUTPUT ACCEPT
:PREROUTING ACCEPT
:POSTROUTING ACCEPT
-A PREROUTING -p tcp -m tcp --dst 123.123.123.123 --dport 80 -j REDIRECT --to-ports 8080
COMMIT
*filter
:INPUT ACCEPT
:OUTPUT ACCEPT
:FORWARD ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
-A INPUT -p tcp -m tcp -m state --state NEW -m multiport --dports 25,80,443,8080 -j ACCEPT
-A INPUT -p tcp -m tcp -m state --state NEW --dport 22 --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 2/min --limit-burst 1 -j ACCEPT
-A FORWARD -p tcp -m tcp --dst 123.123.123.123 --dport 8080 -j ACCEPT
COMMIT
Eu preciso de conexões HTTP de entrada para 123.123.123.123:80
para ser redirecionado para 123.123.123.123:8080 (onde o Jetty está escutando
como usuário "nobody"), mas por alguma razão isso não acontece.
Quando navego para o link , vejo a resposta do Jetty.
Mas quando eu navego para a conexão link é recusada.
Alguém por favor pode identificar o erro para mim?
Aqui está minha tabela nat
atual:
# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
REDIRECT tcp -- anywhere afarber.de tcp dpt:http redir ports 8080
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
Aqui está minha tabela filter
atual:
# iptables -t filter -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere icmp any
ACCEPT tcp -- anywhere anywhere tcp state NEW multiport dports smtp,http,https,webcache
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh flags:FIN,SYN,RST,ACK/SYN state NEW limit: avg 2/min burst 1
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere afarber.de tcp dpt:webcache
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Aqui, meu arquivo /etc/sysctl.conf
:
net.ipv4.ip_forward=1
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
Problema: as solicitações para -d 123.123.123.123 --dport 80
não são redirecionadas para 8080
UPDATE 2:
A linha não ajuda:
-A PREROUTING -p tcp -m tcp -i eth0:1 --dst 123.123.123.123 --dport 80 -j DNAT --to-destination :8080
a conexão com 123.123.123.123:80
ainda é descartada