Debianプロキシサーバーのトラブルシューティングの海岸壁
セットアップは次のとおりです： debian proxy-server-> linsys router-> internal ubuntu server
問題は次のとおりです： debianプロキシのブラウザに192.168.1.128と入力すると、ubuntu Webサーバー（Apache2）にアクセスできます。ただし、私の海岸壁転送ルールは、次のいずれかのルールを使用しても成功しません。
#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
編集：
また、ubuntuマシンでApacheログを確認した後、どのリクエストもそれを行っていないようです。 LANからリクエストすると、アクセスログにエントリが記録されますが、LANの外部からプロキシ経由でリクエストすると、何も取得されません。
プロキシでの「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
パケットが正しく転送されているようです（「shorewallshownat」からの出力が私たちのために行ったことだと思います）
'tcpdump -n -i port80'からの出力
パブリックインターフェイス：
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）win 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>
Ubuntuサーバーのデフォルトゲートウェイとして設定されているホストは何ですか？プロキシするDebianサーバーでない場合は、/ etc/shorewal/masqに別のルールを追加する必要があります。
eth1:192.168.1.128 0.0.0.0/0 192.168.1.137 tcp 80
DebianプロキシLAN NICはeth1で、DebianサーバーのIPアドレスは192.168.1.137だと思います。基本的に、ここでの問題は、DNATルールが転送されたパケットの送信元IPアドレスを変更しないことです。 Ubuntuサーバーは、LANの外部にあるリクエスト発信者に直接応答しようとします。デフォルトのゲートウェイを使用して通信を実行するため、応答がDebianボックスに到達することはありません。この追加のルールにより、発信元IPがプロキシのIPに変更されます。とにかく、Ubuntu上のApacheはDebian IPをクライアントIPとして記録し、すべてのリクエストのログにアクセスするため、おそらくそれはあなたが望むものではありません。
まず第一に、私は記号#各ルールが構成ファイルに存在しない前（その行にコメントが付けられ、役に立たなくなります）。
パブリックとプライベートの両方のインターフェイスでプロキシサーバーのネットワークトラフィックを監視してみてください。パブリック側：
# tcpdump -n -i <public interface> port 80
プライベート側：
# tcpdump -n -i <private interface> port 80 and Host 192.168.1.128
外の世界からリクエストを行うときは、プライベート側にトラフィックがない場合は、次のことを再確認する必要があります。
カーネルはトラフィックの転送を許可します（1つである必要があります）：
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の場合、HTTPサーバーへのトラフィックの転送を許可するFORWARDチェーン上のルールを探します。
iptables -vnL FORWARD | grep 192.168.1.128
（ここでも、FORWARDで意味のあるものが何も表示されない場合は、net2locを確認してください）。
これで回線が返されない場合（およびポリシーがREJECT/DROPである場合）、トラフィックの転送を許可するルールがありません...海岸壁の構成を再確認してください。ポリシー構成ファイルでlocログをinfoに設定し、ルールを強制します。
iptables -A net2loc -i <public iface> -o <private iface> \
--dst 192.168.1.128 -p tcp --dport 80 -j ACCEPT
そして、何が起こるかを見てください。
別の方法として、外部の場所からリクエストを送信し、それがプライベート側に表示される場合は、他の問題が発生していることを意味します（linksysルーターの転送ポリシーやルートなどを確認してください）。
@ Alexリスクがあるので、私は何もしません。誰があなたのサービスにアクセスしているかの痕跡をすべて失うため、統計が失われます。サイトに攻撃があった場合、Webサーバーのログやその他の多くの理由を見るだけでは、どこから攻撃が来ているのかを判断することはできません。通常、パブリックネットワークからプライベート宛先へのSNATは強くお勧めしません。
さて、少し異なる設定で動作しているようです。
今、私はDebianプロキシ-> Ubuntuサーバーに行きます（これ以上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はうまくいっているようで、私のApacheログは有益です（すべてのリクエストがDebianマシンから来ていると言っているだけではありません）
皆さんの助けに感謝します。私はここに投稿されたすべてのものを使用して、許容できる解決策になることを願っています。