私が解決しようとしている問題は次のとおりです。ローカル コンピュータから SSH で接続できるサーバー (「リモート システム」) がありますが、このリモート システムにはインターネット接続がありません。SSH ベースの VPN を使用して、ローカル コンピュータ経由でリモート システムにインターネットへのアクセスを提供したいのですが、どうすればよいでしょうか。次の方法を試しましたが、部分的に機能しているようです。「部分的に機能する」とは、接続パケット (同期パケット) がローカル コンピュータに送信されるものの、インターネットへの接続を確立できないことを意味します。ローカル コンピュータでパケットをキャプチャするために tcpdump を使用しています。ローカル コンピュータとリモート システムはどちらも Centos 7 を実行しています。
セットアップ- 注意: 以下のコマンドは順番に実行されます。user@remote コマンドはリモート サーバーで実行され、user@local コマンドはローカル コンピューターで実行されます。
[ユーザー@リモート ~]$ ip addr show
1: lo: mtu 65536 qdisc noqueue 状態 不明
リンク/ループバック 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 スコープ ホスト lo
valid_lft 永久に preferred_lft 永久に
inet6 ::1/128 スコープホスト
valid_lft 永久に preferred_lft 永久に
2: eth0: mtu 1500 qdisc pfifo_fast 状態 UP qlen 1000
リンク/イーサ AA:BB:CC:DD:EE:FF ブリッジ ff:ff:ff:ff:ff:ff
inet AAA.BBB.CCC.DDD/24 brd AAA.BBB.CCC.255 スコープ グローバル ダイナミック eth0
有効_lft 1785秒 推奨_lft 1785秒
inet6 EEEE:FFFF:GGGG:HHHH:IIII:JJJJ:KKKK:LLLL/64 スコープ グローバル noprefixroute ダイナミック
有効_lft 2591987秒 推奨_lft 604787秒
inet6 ABCD::IIII:JJJJ:KKKK:LLLL/64 スコープ リンク
valid_lft 永久に preferred_lft 永久に
[user@local ~]$ ip addr show
1: lo: mtu 65536 qdisc noqueue 状態 不明
リンク/ループバック 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 スコープ ホスト lo
valid_lft 永久に preferred_lft 永久に
inet6 ::1/128 スコープホスト
valid_lft 永久に preferred_lft 永久に
2: eth0: mtu 1500 qdisc pfifo_fast 状態 UP qlen 1000
リンク/イーサ AA:BB:CC:DD:EE:FF ブリッジ ff:ff:ff:ff:ff:ff
inet AAA.BBB.CCC.DDD/24 brd AAA.BBB.CCC.255 スコープ グローバル ダイナミック eth0
有効_lft 1785秒 推奨_lft 1785秒
inet6 EEEE:FFFF:GGGG:HHHH:IIII:JJJJ:KKKK:LLLL/64 スコープ グローバル noprefixroute ダイナミック
有効_lft 2591987秒 推奨_lft 604787秒
inet6 ABCD::IIII:JJJJ:KKKK:LLLL/64 スコープ リンク
valid_lft 永久に preferred_lft 永久に
tun0インターフェースを作成しますリモートシステム。
[user@remote ~]$ sudo ip tuntap add tun0 mode tun
[ユーザー@リモート ~]$ ip addr show
1: lo: mtu 65536 qdisc noqueue 状態 不明
リンク/ループバック 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 スコープ ホスト lo
valid_lft 永久に preferred_lft 永久に
inet6 ::1/128 スコープホスト
valid_lft 永久に preferred_lft 永久に
2: eth0: mtu 1500 qdisc pfifo_fast 状態 UP qlen 1000
リンク/イーサ AA:BB:CC:DD:EE:FF ブリッジ ff:ff:ff:ff:ff:ff
inet AAA.BBB.CCC.DDD/24 brd AAA.BBB.CCC.255 スコープ グローバル ダイナミック eth0
有効_lft 1785秒 推奨_lft 1785秒
inet6 EEEE:FFFF:GGGG:HHHH:IIII:JJJJ:KKKK:LLLL/64 スコープ グローバル noprefixroute ダイナミック
有効_lft 2591987秒 推奨_lft 604787秒
inet6 ABCD::IIII:JJJJ:KKKK:LLLL/64 スコープ リンク
valid_lft 永久に preferred_lft 永久に
3: tun0: mtu 1500 qdisc noop 状態 DOWN qlen 500
リンク/なし
tun0インターフェースを作成します地元システム。
[user@local ~]$ sudo ip tuntap add tun0 mode tun
[user@local ~]$ ip addr show
1: lo: mtu 65536 qdisc noqueue 状態 不明
リンク/ループバック 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 スコープ ホスト lo
valid_lft 永久に preferred_lft 永久に
inet6 ::1/128 スコープホスト
valid_lft 永久に preferred_lft 永久に
2: eth0: mtu 1500 qdisc pfifo_fast 状態 UP qlen 1000
リンク/イーサ AA:BB:CC:DD:EE:FF ブリッジ ff:ff:ff:ff:ff:ff
inet AAA.BBB.CCC.DDD/24 brd AAA.BBB.CCC.255 スコープ グローバル ダイナミック eth0
有効_lft 1785秒 推奨_lft 1785秒
inet6 EEEE:FFFF:GGGG:HHHH:IIII:JJJJ:KKKK:LLLL/64 スコープ グローバル noprefixroute ダイナミック
有効_lft 2591987秒 推奨_lft 604787秒
inet6 ABCD::IIII:JJJJ:KKKK:LLLL/64 スコープ リンク
valid_lft 永久に preferred_lft 永久に
3: tun0: mtu 1500 qdisc noop 状態 DOWN qlen 500
リンク/なし
tun0 に IP アドレスを割り当てて起動します。
[user@local ~]$ sudo ip addr add 10.0.2.1/30 dev tun0
[user@local ~]$ sudo ip link set dev tun0 up
[user@local ~]$ ip addr show tun0
3: tun0: mtu 1500 qdisc pfifo_fast 状態 DOWN qlen 500
リンク/なし
inet 10.0.2.1/30 スコープ グローバル tun0
valid_lft 永久に preferred_lft 永久に
[ユーザー@リモート ~]$ sudo ip addr add 10.0.2.2/30 dev tun0
[user@remote ~]$ sudo ip link set dev tun0 up
[ユーザー@リモート ~]$ ip addr show tun0
3: tun0: mtu 1500 qdisc pfifo_fast 状態 DOWN qlen 500
リンク/なし
inet 10.0.2.2/30 スコープ グローバル tun0
valid_lft 永久に preferred_lft 永久に
トンネリングを有効にするには、リモート システムとローカル システムの両方で sshd_config を変更します。
[user@remote ~]$ sudo grep PermitTunnel /etc/ssh/sshd_config PermitTunnel ポイントツーポイント
[user@local ~]$ sudo grep PermitTunnel /etc/ssh/sshd_config PermitTunnel ポイントツーポイント
SSH トンネルを作成します。
[ユーザー@ローカル ~]$ sudo ssh -f -w0:0 root@リモート true root@remoteのパスワード: [user@local ~]$ ps aux | grep root@remote ルート 1851 0.0 0.0 76112 1348 ? Ss 23:12 0:00 ssh -f -w0:0 root@remote true
新しい IP アドレスを使用して両方のサーバーで ping をテストします。
[ユーザー@ローカル ~]$ ping 10.0.2.2 -c 2 PING 10.0.2.2 (10.0.2.2) 56(84) バイトのデータ。 10.0.2.2 からの 64 バイト: icmp_seq=1 ttl=64 time=1.68 ms 10.0.2.2 からの 64 バイト: icmp_seq=2 ttl=64 time=0.861 ms --- 10.0.2.2 ping 統計 --- 送信パケット 2 個、受信パケット 2 個、パケット損失 0%、時間 1002 ミリ秒 rtt 最小/平均/最大/平均偏差 = 0.861/1.274/1.688/0.415 ミリ秒
[ユーザー@リモート ~]$ ping 10.0.2.1 -c 2 PING 10.0.2.1 (10.0.2.1) 56(84) バイトのデータ。 10.0.2.1 からの 64 バイト: icmp_seq=1 ttl=64 time=0.589 ms 10.0.2.1 からの 64 バイト: icmp_seq=2 ttl=64 time=0.889 ms --- 10.0.2.1 ping 統計 --- 送信パケット 2 個、受信パケット 2 個、パケット損失 0%、時間 1000 ミリ秒 rtt 最小/平均/最大/平均偏差 = 0.589/0.739/0.889/0.150 ミリ秒
[user@remote ~]$ ルート カーネル IP ルーティング テーブル 宛先ゲートウェイ Genmask フラグ メトリック参照 Iface の使用 デフォルトゲートウェイ 0.0.0.0 UG 100 0 0 eth0 10.0.2.0 0.0.0.0 255.255.255.252 U 0 0 0 tun0 AAA.BBB.CCC.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0 [ユーザー@リモート ~]$ ip ルート ショー デフォルト AAA.BBB.CCC.1 dev eth0 proto 静的メトリック 100 10.0.2.0/30 dev tun0 proto カーネル スコープ リンク src 10.0.2.2 AAA.BBB.CCC.0/24 dev eth0 proto カーネル スコープ リンク src AAA.BBB.CCC.31 メトリック 100
Google IP アドレスを取得します:
[user@local ~]$ nslookup google.com サーバー: サーバー アドレス: サーバー#53 権威のない回答: 名前: google.com 住所: 173.194.219.101 名前: google.com 住所: 173.194.219.100 名前: google.com 住所: 173.194.219.113 名前: google.com 住所: 173.194.219.102 名前: google.com 住所: 173.194.219.139 名前: google.com 住所: 173.194.219.138
重要： 上記のコマンドを別の時間に実行したところ、異なる結果が得られました。上記の nslookup に対する私の応答と同じ結果になると想定しないでください。
Google の IP アドレスはすべて 173.194.219 で始まるため、これらすべての IP アドレスをローカル コンピューター経由でルーティングします。
[user@remote ~]$ sudo ip route add 173.194.219.0/24 dev tun0 [user@remote ~]$ ルート カーネル IP ルーティング テーブル 宛先ゲートウェイ Genmask フラグ メトリック参照 Iface の使用 デフォルトゲートウェイ 0.0.0.0 UG 100 0 0 eth0 10.0.2.0 0.0.0.0 255.255.255.252 U 0 0 0 tun0 AAA.BBB.CCC.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0 173.194.219.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0 [ユーザー@リモート ~]$ ip ルート ショー デフォルト AAA.BBB.CCC.1 dev eth0 proto 静的メトリック 100 10.0.2.0/30 dev tun0 proto カーネル スコープ リンク src 10.0.2.2 AAA.BBB.CCC.0/24 dev eth0 proto カーネル スコープ リンク src AAA.BBB.CCC.31 メトリック 100 173.194.219.0/24 dev tun0 スコープリンク
ip_forwarding を有効にする:
[user@local ~]$ grep ip_forward /etc/sysctl.conf ネット.ipv4.ip_forward = 1 [user@local ~]$ sudo サービスネットワークを再起動 ネットワークを再起動しています（systemctl経由）: [ OK ]
tcpdump を使用してローカル コンピューターでパケット キャプチャを設定します。
[user@local ~]$ sudo tcpdump -nn -vv 'ポート22以外' -i 任意 tcpdump: 任意でリッスン、リンクタイプ LINUX_SLL (Linux で調理済み)、キャプチャサイズ 65535 バイト
リモート サーバーから Google への接続を試みます。
[ユーザー@リモート ~]$ openssl s_client -connect google.com:443 ソケット: ホストへのルートがありません 接続:エラー番号=113
リモート サーバーで openssl コマンドが実行されるとすぐに、tcpdump はいくつかのパケットをキャプチャします。
10.0.2.2.52768 > 173.194.219.102.443: フラグ [S]、cksum 0x8702 (正しい)、seq 994650730、win 29200、オプション [mss 1460、sackOK、TS val 7701438 ecr 0、nop、wscale 7]、長さ 0
00:49:33.247753 IP (tos 0x0、ttl 64、id 46037、オフセット 0、フラグ [DF]、プロトコル TCP (6)、長さ 60)
10.0.2.2.48774 > 173.194.219.100.443: フラグ [S]、cksum 0x47a7 (正しい)、seq 2218733674、win 29200、オプション [mss 1460、sackOK、TS val 7701439 ecr 0、nop、wscale 7]、長さ 0
00:49:33.247883 IP (tos 0xc0、ttl 64、id 9538、オフセット 0、フラグ [なし]、プロトコル ICMP (1)、長さ 88)
10.0.2.1 > 10.0.2.2: ICMP ホスト 173.194.219.100 に到達できません - 管理者は禁止されています、長さ 68
IP (tos 0x0、ttl 63、id 46037、オフセット 0、フラグ [DF]、プロトコル TCP (6)、長さ 60)
10.0.2.2.48774 > 173.194.219.100.443: フラグ [S]、cksum 0x47a7 (正しい)、seq 2218733674、win 29200、オプション [mss 1460、sackOK、TS val 7701439 ecr 0、nop、wscale 7]、長さ 0
00:49:33.253068 IP (tos 0x0、ttl 64、id 26282、オフセット 0、フラグ [DF]、プロトコル TCP (6)、長さ 60)
10.0.2.2.51312 > 173.194.219.101.443: フラグ [S]、cksum 0x6ff8 (正しい)、seq 2634016105、win 29200、オプション [mss 1460、sackOK、TS val 7701443 ecr 0、nop、wscale 7]、長さ 0
00:49:33.254771 IP (tos 0xc0、ttl 64、id 9539、オフセット 0、フラグ [なし]、プロトコル ICMP (1)、長さ 88)
10.0.2.1 > 10.0.2.2: ICMP ホスト 173.194.219.101 に到達できません - 管理者は禁止されています、長さ 68
IP (tos 0x0、ttl 63、id 26282、オフセット 0、フラグ [DF]、プロトコル TCP (6)、長さ 60)
10.0.2.2.51312 > 173.194.219.101.443: フラグ [S]、cksum 0x6ff8 (正しい)、seq 2634016105、win 29200、オプション [mss 1460、sackOK、TS val 7701443 ecr 0、nop、wscale 7]、長さ 0
00:49:33.258805 IP (tos 0x0、ttl 64、id 9293、オフセット 0、フラグ [DF]、プロトコル TCP (6)、長さ 60)
10.0.2.2.33686 > 173.194.219.139.443: フラグ [S]、cksum 0x542b (正しい)、seq 995927943、win 29200、オプション [mss 1460、sackOK、TS val 7701450 ecr 0、nop、wscale 7]、長さ 0
00:49:33.258845 IP (tos 0xc0、ttl 64、id 9540、オフセット 0、フラグ [なし]、プロトコル ICMP (1)、長さ 88)
10.0.2.1 > 10.0.2.2: ICMP ホスト 173.194.219.139 に到達できません - 管理者は禁止されています、長さ 68
IP (tos 0x0、ttl 63、id 9293、オフセット 0、フラグ [DF]、プロトコル TCP (6)、長さ 60)
10.0.2.2.33686 > 173.194.219.139.443: フラグ [S]、cksum 0x542b (正しい)、seq 995927943、win 29200、オプション [mss 1460、sackOK、TS val 7701450 ecr 0、nop、wscale 7]、長さ 0
^C
13パケットをキャプチャ
フィルタによって受信されたパケット 13 個
カーネルによってドロップされたパケット数: 0
tcpdump を使用してキャプチャされたパケットは、接続を確立する試み (同期パケットが送信される) が行われたものの、何も受信されていないことを示しています。また、10.0.2.1 > 10.0.2.2: ICMP host 173.194.219.139 unreachable - admin prohibited, length 68問題を示唆するメッセージもあります。
この問題を回避する方法について何か提案はありますか? 追加する必要がある iptable ルールはありますか? ファイアウォールの問題はありますか (firewall-d?)。
注 #1
iptables-saveからの出力:
[user@local ~]$ sudo iptables -t nat -A POSTROUTING -s 10.0.2.2/32 ! -d 10.0.2.1/30 -j MASQUERADE -o eth0 [ユーザー@ローカル ~]$ sudo iptables-save # 2017 年 4 月 15 日土曜日 01:40:57 に iptables-save v1.4.21 によって生成されました *ナット :事前ルーティング受け入れ [35:8926] :入力承認 [1:84] :出力受け入れ [6:439] :ポストルーティング受け入れ [6:439] :OUTPUT_direct - [0:0] :ポストルーティングゾーン - [0:0] :POSTROUTING_ZONES_SOURCE - [0:0] :POSTROUTING_direct - [0:0] :POST_パブリック - [0:0] :POST_public_allow - [0:0] :POST_public_deny - [0:0] :POST_パブリックログ - [0:0] :PREROUTING_ZONES - [0:0] :PREROUTING_ZONES_SOURCE - [0:0] :PREROUTING_direct - [0:0] :PRE_公開 - [0:0] :PRE_public_allow - [0:0] :PRE_public_deny - [0:0] :PRE_公開ログ - [0:0] -A 事前ルーティング -j 事前ルーティング_direct -A 事前ルーティング -j 事前ルーティング_ゾーン_ソース -A 事前ルーティング -j 事前ルーティングゾーン -A 出力 -j 出力直接 -A ポストルーティング -j ポストルーティング_ダイレクト -A POSTROUTING -j POSTROUTING_ZONES_SOURCE -A ポストルーティング -j ポストルーティングゾーン -A ポストルーティング -s 10.0.2.2/32 ! -d 10.0.2.0/30 -j マスカレード -A POSTROUTING_ZONES -o eth0 -g POST_public -A POSTROUTING_ZONES -g POST_public -A POST_public -j POST_public_log -A POST_public -j POST_public_deny -A POST_public -j POST_public_allow -A 事前ルーティングゾーン -i eth0 -g 事前パブリック -A 事前ルーティングゾーン -g 事前パブリック -A PRE_パブリック -j PRE_パブリックログ -A PRE_public -j PRE_public_deny -A PRE_public -j PRE_public_allow 専念 # 2017年4月15日土曜日01:40:57に完了 # 2017 年 4 月 15 日土曜日 01:40:57 に iptables-save v1.4.21 によって生成されました *マングル :事前ルーティング受け入れ [169:18687] :入力を受け入れます [144:11583] :転送承認[0:0] :出力受け入れ [80:8149] :ポストルーティング受け入れ [80:8149] :FORWARD_direct - [0:0] :INPUT_direct - [0:0] :OUTPUT_direct - [0:0] :POSTROUTING_direct - [0:0] :PREROUTING_ZONES - [0:0] :PREROUTING_ZONES_SOURCE - [0:0] :PREROUTING_direct - [0:0] :PRE_公開 - [0:0] :PRE_public_allow - [0:0] :PRE_public_deny - [0:0] :PRE_公開ログ - [0:0] -A 事前ルーティング -j 事前ルーティング_direct -A 事前ルーティング -j 事前ルーティング_ゾーン_ソース -A 事前ルーティング -j 事前ルーティングゾーン -A 入力 -j 直接入力 -A 転送 -j 転送_直接 -A 出力 -j 出力直接 -A ポストルーティング -j ポストルーティング_ダイレクト -A 事前ルーティングゾーン -i eth0 -g 事前パブリック -A 事前ルーティングゾーン -g 事前パブリック -A PRE_パブリック -j PRE_パブリックログ -A PRE_public -j PRE_public_deny -A PRE_public -j PRE_public_allow 専念 # 2017年4月15日土曜日01:40:57に完了 # 2017 年 4 月 15 日土曜日 01:40:57 に iptables-save v1.4.21 によって生成されました *安全 :入力を受け入れます [2197:163931] :転送承認[0:0] :出力受け入れ [1229:185742] :FORWARD_direct - [0:0] :INPUT_direct - [0:0] :OUTPUT_direct - [0:0] -A 入力 -j 直接入力 -A 転送 -j 転送_直接 -A 出力 -j 出力直接 専念 # 2017年4月15日土曜日01:40:57に完了 # 2017 年 4 月 15 日土曜日 01:40:57 に iptables-save v1.4.21 によって生成されました *生 :事前ルーティング受け入れ [2362:184437] :出力受け入れ [1229:185742] :OUTPUT_direct - [0:0] :PREROUTING_direct - [0:0] -A 事前ルーティング -j 事前ルーティング_direct -A 出力 -j 出力直接 専念 # 2017年4月15日土曜日01:40:57に完了 # 2017 年 4 月 15 日土曜日 01:40:57 に iptables-save v1.4.21 によって生成されました *フィルター :入力受け入れ[0:0] :転送承認[0:0] :出力受け入れ [80:8149] :ゾーン内前方 - [0:0] :FORWARD_IN_ZONES_SOURCE - [0:0] :FORWARD_OUT_ZONES - [0:0] :FORWARD_OUT_ZONES_SOURCE - [0:0] :FORWARD_direct - [0:0] :FWDI_パブリック - [0:0] :FWDI_public_allow - [0:0] :FWDI_public_deny - [0:0] :FWDI_パブリックログ - [0:0] :FWDO_パブリック - [0:0] :FWDO_public_allow - [0:0] :FWDO_public_deny - [0:0] :FWDO_パブリックログ - [0:0] :入力ゾーン - [0:0] :入力ゾーンソース - [0:0] :INPUT_direct - [0:0] :IN_パブリック - [0:0] :IN_public_allow - [0:0] :IN_public_deny - [0:0] :IN_パブリックログ - [0:0] :OUTPUT_direct - [0:0] -A 入力 -m conntrack --ctstate 関連、確立 -j 受け入れ -A 入力 -i lo -j 受け入れ -A 入力 -j 直接入力 -A 入力 -j 入力ゾーンソース -A 入力 -j 入力ゾーン -A 入力 -m conntrack --ctstate 無効 -j ドロップ -A 入力 -j 拒否 --拒否-icmp-ホスト禁止 -A 転送 -m conntrack --ctstate 関連、確立 -j 受け入れ -A 転送 -i lo -j 承認 -A 転送 -j 転送_直接 -A 転送 -j 転送元ゾーン内 -A 前進 -j 前進ゾーン -A 転送 -j 転送アウトゾーンソース -A 転送 -j 転送アウトゾーン -A 転送 -m 接続トラック --ctstate 無効 -j ドロップ -A FORWARD -j REJECT --reject-with icmp-host-prohibited -A 出力 -j 出力直接 -A FORWARD_IN_ZONES -i eth0 -g FWDI_public -A FORWARD_IN_ZONES -g FWDI_public -A FORWARD_OUT_ZONES -o eth0 -g FWDO_public -A FORWARD_OUT_ZONES -g FWDO_public -A FWDI_パブリック -j FWDI_パブリック_ログ -A FWDI_パブリック -j FWDI_パブリック拒否 -A FWDI_パブリック -j FWDI_パブリック_許可 -A FWDI_public -p icmp -j 受け入れる -A FWDO_パブリック -j FWDO_パブリック_ログ -A FWDO_パブリック -j FWDO_パブリック拒否 -A FWDO_パブリック -j FWDO_パブリック_許可 -A 入力ゾーン -i eth0 -g IN_public -A 入力ゾーン -g IN_public -A IN_public -j IN_public_log -A IN_public -j IN_public_deny -A IN_public -j IN_public_allow -A IN_public -p icmp -j ACCEPT -A IN_public_allow -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT 専念 # 2017年4月15日土曜日01:40:57に完了
注2:
ローカル サーバーのみがアクセスできる別のホストに Apache Web サーバーをセットアップしました。ポート 80 でリッスンしている Web サーバーで tcpdump を実行しました
telnet webserver 80。実行すると、次のパケットがキャプチャされます。TCP 接続が確立されているため、これは予想される動作です (S、S-Ack、Ack)。
[user@webserver ~]$ sudo tcpdump -nn -vv 'ポートが22と80以外' -i eth0
tcpdump: eth0 でリッスン、リンク タイプ EN10MB (イーサネット)、キャプチャ サイズ 65535 バイト
07:17:30.411474 IP (tos 0x10、ttl 64、id 34376、オフセット 0、フラグ [DF]、プロトコル TCP (6)、長さ 60)
local.server.46710 > web.server.80: フラグ [S]、cksum 0x8412 (不正 -> 0x6d96)、seq 3018586542、win 29200、オプション [mss 1460、sackOK、TS val 3047398 ecr 0、nop、wscale 7]、長さ 0
07:17:30.411557 IP (tos 0x0、ttl 64、id 0、オフセット 0、フラグ [DF]、プロトコル TCP (6)、長さ 60)
web.server.80 > local.server.46710: フラグ [S.]、cksum 0x8412 (不正 -> 0x9114)、seq 2651711943、ack 3018586543、win 28960、オプション [mss 1460、sackOK、TS val 37704524 ecr 3047398、nop、wscale 7]、長さ 0
07:17:30.411725 IP (tos 0x10、ttl 64、id 34377、オフセット 0、フラグ [DF]、プロトコル TCP (6)、長さ 52)
local.server.46710 > web.server.80: フラグ [.]、cksum 0x840a (不正 -> 0x301c)、seq 1、ack 1、win 229、オプション [nop、nop、TS val 3047398 ecr 37704524]、長さ 0
リモート サーバーからローカル サーバーを介して Web サーバーに接続しようとすると、Web サーバー上の tcpdump はパケットをキャプチャしません (最初の Sync もキャプチャしません)。ただし、ローカル サーバーは Web サーバーに送信される Sync パケットをキャプチャします (以下を参照)。このことから、パケットが Web サーバーに送信されない原因が何かあると考えられます。おそらく、構成ミスまたはファイアウォールが原因です。
[user@local ~]$ sudo tcpdump -nn -vv 'ポート22と80以外' -i any
tcpdump: 任意でリッスン、リンクタイプ LINUX_SLL (Linux で調理済み)、キャプチャサイズ 65535 バイト
02:24:09.135842 IP (tos 0x10、ttl 64、id 38062、オフセット 0、フラグ [DF]、プロトコル TCP (6)、長さ 60)
10.0.2.2.50558 > web.server.80: フラグ [S]、cksum 0x668d (正しい)、seq 69756226、win 29200、オプション [mss 1460、sackOK、TS val 4780524 ecr 0、nop、wscale 7]、長さ 0
重要：パケットは eth0 経由でルーティングされておらず、代わりに tun0 経由で Web サーバーにパケットを送信しようとしています (失敗します)。tun0 インターフェイスで tcpdump を実行すると、これを確認できます。
[user@local ~]$ sudo tcpdump -nn -vv 'ポートが22と80以外' -i tun0
tcpdump: tun0 でリッスン、リンク タイプ RAW (Raw IP)、キャプチャ サイズ 65535 バイト
02:28:10.295972 IP (tos 0x10、ttl 64、id 46976、オフセット 0、フラグ [DF]、プロトコル TCP (6)、長さ 60)
10.0.2.2.50560 > webserver.80: フラグ [S]、cksum 0xd560 (正しい)、seq 605366388、win 29200、オプション [mss 1460、sackOK、TS val 5021684 ecr 0、nop、wscale 7]、長さ 0
注3：
ローカル コンピューターでファイアウォールをオフにすると、同期パケットが Web サーバーによって受信されました。
[user@local ~]$ sudo systemctl stop firewalld
[user@webserver ~]$ sudo tcpdump -nn -vv 'ポートが22と80以外' -i eth0
tcpdump: eth0 でリッスン、リンク タイプ EN10MB (イーサネット)、キャプチャ サイズ 65535 バイト
08:25:17.390912 IP (tos 0x10、ttl 63、id 61767、オフセット 0、フラグ [DF]、プロトコル TCP (6)、長さ 60)
10.0.2.2.50580 > web.server.80: フラグ [S]、cksum 0x30dc (正しい)、seq 2601927549、win 29200、オプション [mss 1460、sackOK、TS val 7123514 ecr 0、nop、wscale 7]、長さ 0
08:25:17.391003 IP (tos 0x0、ttl 64、id 0、オフセット 0、フラグ [DF]、プロトコル TCP (6)、長さ 60)
web.server.80 > 10.0.2.2.50580: フラグ [S.]、cksum 0x4e23 (不正 -> 0xa316)、seq 959115533、ack 2601927550、win 28960、オプション [mss 1460、sackOK、TS val 41771503 ecr 7123514、nop、wscale 7]、長さ 0
08:25:17.391192 IP (tos 0x0、ttl 128、id 60032、オフセット 0、フラグ [なし]、プロトコル TCP (6)、長さ 40)
10.0.2.2.50580 > web.server.80: フラグ [R]、cksum 0x7339 (正しい)、seq 2601927550、win 8192、長さ 0
08:25:18.393794 IP (tos 0x10、ttl 63、id 61768、オフセット 0、フラグ [DF]、プロトコル TCP (6)、長さ 60)
10.0.2.2.50580 > web.server.80: フラグ [S]、cksum 0x2cf1 (正しい)、seq 2601927549、win 29200、オプション [mss 1460、sackOK、TS val 7124517 ecr 0、nop、wscale 7]、長さ 0
08:25:18.393898 IP (tos 0x0、ttl 64、id 0、オフセット 0、フラグ [DF]、プロトコル TCP (6)、長さ 60)
web.server.80 > 10.0.2.2.50580: フラグ [S.]、cksum 0x4e23 (不正 -> 0x7e71)、seq 974785773、ack 2601927550、win 28960、オプション [mss 1460、sackOK、TS val 41772506 ecr 7124517、nop、wscale 7]、長さ 0
08:25:18.394003 IP (tos 0x0、ttl 128、id 60033、オフセット 0、フラグ [なし]、プロトコル TCP (6)、長さ 40)
10.0.2.2.50580 > web.server.80: フラグ [R]、cksum 0x566a (正しい)、seq 2601927550、win 8192、長さ 0
明らかに、パケットが Web サーバーに送信される前に、送信元 IP を更新してローカル サーバーの IP アドレスと一致させる必要があります。@xin が示唆したように、NAT はローカル サーバーで設定する必要があります。
注#4:
Web サーバーに接続しようとすると、ルール 9 のパケット数が 1 増加することがわかります (以下を参照)。
[user@local ~]$ sudo iptables -nvL --line-numbers .......... チェーン FORWARD (ポリシー ACCEPT 0 パケット、0 バイト) パケット数 バイト数 ターゲット プロトコル オプトイン アウト ソース 宛先 1 0 0 すべてを受け入れる -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED、ESTABLISHED 2 0 0 すべてを受け入れる -- lo * 0.0.0.0/0 0.0.0.0/0 3 1 60 FORWARD_direct すべて -- * * 0.0.0.0/0 0.0.0.0/0 4 1 60 FORWARD_IN_ZONES_SOURCE すべて -- * * 0.0.0.0/0 0.0.0.0/0 5 1 60 FORWARD_IN_ZONES すべて -- * * 0.0.0.0/0 0.0.0.0/0 6 1 60 FORWARD_OUT_ZONES_SOURCE すべて -- * * 0.0.0.0/0 0.0.0.0/0 7 1 60 FORWARD_OUT_ZONES すべて -- * * 0.0.0.0/0 0.0.0.0/0 8 0 0 すべて削除 -- * * 0.0.0.0/0 0.0.0.0/0 ctstate 無効 9 1 60 すべてを拒否 -- * * 0.0.0.0/0 0.0.0.0/0 icmp-host-prohibited による拒否 .......... [user@local ~]$ sudo iptables -D FORWARD 9
FORWARD チェーンのルール 9 が削除されると (上記、@xin の提案どおり)、Web サーバーに接続できるようになります。
[user@local ~]$ sudo iptables -nvL --line-numbers .......... チェーン FORWARD (ポリシー ACCEPT 1 パケット、60 バイト) パケット数 バイト数 ターゲット プロトコル オプトイン アウト ソース 宛先 1 12 5857 すべてを受け入れる -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED、ESTABLISHED 2 0 0 すべてを受け入れる -- lo * 0.0.0.0/0 0.0.0.0/0 3 2 120 FORWARD_direct すべて -- * * 0.0.0.0/0 0.0.0.0/0 4 2 120 FORWARD_IN_ZONES_SOURCE すべて -- * * 0.0.0.0/0 0.0.0.0/0 5 2 120 FORWARD_IN_ZONES すべて -- * * 0.0.0.0/0 0.0.0.0/0 6 2 120 FORWARD_OUT_ZONES_SOURCE すべて -- * * 0.0.0.0/0 0.0.0.0/0 7 2 120 FORWARD_OUT_ZONES すべて -- * * 0.0.0.0/0 0.0.0.0/0 8 0 0 すべて削除 -- * * 0.0.0.0/0 0.0.0.0/0 ctstate 無効 ..........
答え1
パケットの送信元アドレスは、ローカル マシンが応答を受信できるように、ローカル マシンのアドレスの 1 つに置き換える必要があります。そうしないと、これらのパケットを次のルーターに送信する (正当な) 理由がなく、応答をキャッチできなくなります。iptables はMASQUERADE、SNATこれらのパケットの送信元アドレスを変更するのに役立ちます。
[user@local ~]$ iptables -t nat -A POSTROUTING -s 10.0.2.2/32 ! -d 10.0.2.1/30 -j MASQUERADE -o eth0