
これが私が解決しようとしている問題です。自分のローカルコンピュータからサーバー(「リモートシステム」)に接続できますが、リモートシステムにはインターネットが接続されていません。 SSHベースのVPNを使用してローカルコンピュータを介してインターネットにアクセスできるリモートシステムを提供したいと思います。この目標をどのように達成できますか?以下を試しましたが、部分的に機能しているようです。 「部分的に動作する」とは、接続パケット(同期パケット)が自分のローカルコンピュータに送信されますが、インターネット接続を確立できないことを意味します。私はローカルコンピュータからパケットをキャプチャするためにtcpdumpを使用しています。ローカルコンピュータとリモートシステムの両方がcentos 7を実行しています。
設定- 注:次のコマンドは順番に実行されます。 user@remote コマンドはリモートサーバーで実行され、user@local コマンドはローカルコンピュータで実行されます。
[user@remote ~]$ IP アドレスを表示 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 常に優先_lft inet6::1/128 スコープホスト 常に valid_lft 常に優先_lft 2: eth0: mtu 1500 qdisc pfifo_fast 状態 UP qlen 1000 リンク/エーテル AA:BB:CC:DD:EE:FF brd ff:ff:ff:ff:ff:ff inet AAA.BBB.CCC.DDD/24 brd AAA.BBB.CCC.255 範囲グローバル動的 eth0 valid_lft 1785秒 Preferred_lft 1785秒 inet6 EEEE:FFFF:GGGG:HHHH:IIII:JJJJ:KKKK:LLLL/64 範囲 グローバル noprefixroute 動的 valid_lft 2591987秒 Preferred_lft 604787秒 inet6 ABCD::IIII:JJJJ:KKKK:LLLL/64 範囲リンク 常に valid_lft 常に優先_lft
[user@local ~]$ IP アドレスを表示 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 常に優先_lft inet6::1/128 スコープホスト 常に valid_lft 常に優先_lft 2: eth0: mtu 1500 qdisc pfifo_fast 状態 UP qlen 1000 リンク/エーテル AA:BB:CC:DD:EE:FF brd ff:ff:ff:ff:ff:ff inet AAA.BBB.CCC.DDD/24 brd AAA.BBB.CCC.255 範囲グローバル動的 eth0 valid_lft 1785秒 Preferred_lft 1785秒 inet6 EEEE:FFFF:GGGG:HHHH:IIII:JJJJ:KKKK:LLLL/64 範囲 グローバル noprefixroute 動的 valid_lft 2591987秒 Preferred_lft 604787秒 inet6 ABCD::IIII:JJJJ:KKKK:LLLL/64 範囲リンク 常に valid_lft 常に優先_lft
tun0 インターフェイスの生成離れてシステム。
[user@remote~]$ sudo ip tuntap add tun0 mode tun [user@remote ~]$ IP アドレスを表示 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 常に優先_lft inet6::1/128 スコープホスト 常に valid_lft 常に優先_lft 2: eth0: mtu 1500 qdisc pfifo_fast 状態 UP qlen 1000 リンク/エーテル AA:BB:CC:DD:EE:FF brd ff:ff:ff:ff:ff:ff inet AAA.BBB.CCC.DDD/24 brd AAA.BBB.CCC.255 範囲グローバル動的 eth0 valid_lft 1785秒 Preferred_lft 1785秒 inet6 EEEE:FFFF:GGGG:HHHH:IIII:JJJJ:KKKK:LLLL/64 範囲 グローバル noprefixroute 動的 valid_lft 2591987秒 Preferred_lft 604787秒 inet6 ABCD::IIII:JJJJ:KKKK:LLLL/64 範囲リンク 常に valid_lft 常に優先_lft 3: tun0: mtu 1500 qdisc noop 状態 DOWN qlen 500 リンク/なし
tun0 インターフェイスの生成地元のシステム。
[user@local ~]$ sudo ip tuntap add tun0 mode tun [user@local ~]$ IP アドレスを表示 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 常に優先_lft inet6::1/128 スコープホスト 常に valid_lft 常に優先_lft 2: eth0: mtu 1500 qdisc pfifo_fast 状態 UP qlen 1000 リンク/エーテル AA:BB:CC:DD:EE:FF brd ff:ff:ff:ff:ff:ff inet AAA.BBB.CCC.DDD/24 brd AAA.BBB.CCC.255 範囲グローバル動的 eth0 valid_lft 1785秒 Preferred_lft 1785秒 inet6 EEEE:FFFF:GGGG:HHHH:IIII:JJJJ:KKKK:LLLL/64 範囲 グローバル noprefixroute 動的 valid_lft 2591987秒 Preferred_lft 604787秒 inet6 ABCD::IIII:JJJJ:KKKK:LLLL/64 範囲リンク 常に valid_lft 常に優先_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 常に優先_lft
[user@remote~]$ sudo ip addr add 10.0.2.2/30 dev tun0 [user@remote~]$ sudo ip link set dev tun0 up [user@remote~]$ip addr show tun0 3: tun0: mtu 1500 qdisc pfifo_fast 状態 DOWN qlen 500 リンク/なし inet 10.0.2.2/30 範囲グローバル tun0 常に valid_lft 常に優先_lft
トンネリングをイネーブルにするには、リモートおよびローカルシステムで sshd_config を変更します。
[User@remote~]$ sudo grep PermitTunnel /etc/ssh/sshd_config ポイントツーポイント権限トンネル
[user@local ~]$ sudo grep PermitTunnel /etc/ssh/sshd_config ポイントツーポイント権限トンネル
SSHトンネルを作成します。
[User@local~]$ sudo ssh -f -w0:0 root@remote true root@remoteのパスワード: [ユーザー@ローカル〜] $ ps grep root @ remote | ルート 1851 0.0 0.0 76112 1348? ss 23:12 0:00 ssh -f -w0:0 root@remote true
新しいIPアドレスを使用して両方のサーバーでpingをテストします。
[user@local~]$ 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%パケット損失、時間1002ms rtt 最小/平均/最大/mdev = 0.861/1.274/1.688/0.415 ミリ秒
[user@remote~]$ 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%パケット損失、時間1000ms rtt 最小/平均/最大/mdev = 0.589/0.739/0.8 89/0.150 ミリ秒
[User@remote~]$route カーネルIPルーティングテーブル Ifaceを使用したターゲットゲートウェイGenmaskマークメトリックリファレンス デフォルトゲートウェイ 0.0.0.0 UG 100 0 0 eth0 10.0.2.0 0.0.0.0 255.255.255.252 ユー 0 0 0 tun0 AAA.BBB.CCC.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0 [user@remote ~]$ IP ルーティングを表示 デフォルトでは、AAA.BBB.CCC.1 dev eth0オリジナルスタティックインジケータ100 10.0.2.0/30 dev tun0プロトタイプカーネルスコープリンクsrc 10.0.2.2 AAA.BBB.CCC.0/24 dev eth0プロトタイプカーネル範囲リンク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で始まりますので、すべてローカルシステムを介してルーティングします。
[user@remote ~]$ sudo ip パスを追加 173.194.219.0/24 dev tun0 [User@remote~]$route カーネルIPルーティングテーブル Ifaceを使用したターゲットゲートウェイGenmaskマークメトリックリファレンス デフォルトゲートウェイ 0.0.0.0 UG 100 0 0 eth0 10.0.2.0 0.0.0.0 255.255.255.252 ユー 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 ユー 0 0 0 tun0 [user@remote ~]$ IP ルーティングを表示 デフォルトでは、AAA.BBB.CCC.1 dev eth0オリジナルスタティックインジケータ100 10.0.2.0/30 dev tun0プロトタイプカーネルスコープリンクsrc 10.0.2.2 AAA.BBB.CCC.0/24 dev eth0プロトタイプカーネル範囲リンクsrc AAA.BBB.CCC.31メートル法100 173.194.219.0/24 dev tun0 スコープリンク
ip_forwardingを有効にする:
[user@local ~]$ grep ip_forward /etc/sysctl.conf net.ipv4.ip_forward = 1 [user@local~]$sudo サービスネットワークの再起動 ネットワークの再起動(systemctl経由):[OK]
tcpdumpを使用してローカルマシンでパケットキャプチャを設定します。
[user@local ~]$ sudo tcpdump -nn -vv 'ポートが22ではありません。 -i any tcpdump:すべて受信、リンクタイプLINUX_SLL(Linuxに慣れている)、キャプチャサイズ65535バイト
リモートサーバーからGoogleに接続してみてください。
[User@remote~]$ 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, 0 0 、長さ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, 0 ]、長さ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]、raw TCP(6)、長さ60) 10.0.2.2.48774 > 173.194.219.100.443: フラグ [S], cksum 0x47a7(正しい), seq 2218733674, win 29200, オプション [mss 1460, sackOK, 0 ]、長さ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, 0 0 、長さ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]、raw TCP(6)、長さ60) 10.0.2.2.51312 > 173.194.219.101.443: フラグ [S], cksum 0x6ff8(正しい), seq 2634016105, win 29200, オプション [mss 1460, sackOK, 0 0 、長さ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, 0 0 、長さ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]、raw TCP(6)、長さ60) 10.0.2.2.33686 > 173.194.219.139.443: フラグ [S], cksum 0x542b(正しい), seq 995927943, win 29200, オプション [mss 1460, sackOK, 0 0 、長さ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 変装 -o eth0 [user@local~]$ sudo iptables-save # 2017年4月15日土曜日01:40:57にiptables-save v1.4.21によって作成されました *鎌 :事前ルーティングが許可されました[35:8926] :入力が許可されました[1:84] :出力承認[6:439] :ポストルーティングが許可されました[6:439] :出力方向 - [0:0] :ポストアウト_ゾーン - [0:0] :POSTROUTING_ZONES_SOURCE - [0:0] :ポストアウト_ダイレクト - [0:0] :POST_公開 - [0:0] :POST_public_allow - [0:0] :POST_public_deny - [0:0] :POST_public_log - [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_public_log - [0:0] -A 辞書ルーティング -j 辞書ルーティング_direct -A 辞書ルーティング -j 辞書ルーティング_ZONES_SOURCE -A 事前ルーティング -j PREROUTING_ZONES -A 出力 -j OUTPUT_direct -A POSTROUTING -j POSTROUTING_direct -A POSTROUTING -j POSTROUTING_ZONES_SOURCE -A POSTROUTING -j POSTROUTING_ZONES -ルーティング後 -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_公開 -j POST_公開_拒否 -A POST_public -j POST_public_allow -A PREROUTING_ZONES -i eth0 -g PRE_public -A PREROUTING_ZONES -g PRE_public -A PRE_public -j PRE_public_log -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_ダイレクト - [0:0] :出力方向 - [0:0] :ポストアウト_ダイレクト - [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_public_log - [0:0] -A 辞書ルーティング -j 辞書ルーティング_direct -A 辞書ルーティング -j 辞書ルーティング_ZONES_SOURCE -A 事前ルーティング -j PREROUTING_ZONES -A 入力 -j INPUT_direct -A フォワード -j FORWARD_direct -A 出力 -j OUTPUT_direct -A POSTROUTING -j POSTROUTING_direct -A PREROUTING_ZONES -i eth0 -g PRE_public -A PREROUTING_ZONES -g PRE_public -A PRE_public -j PRE_public_log -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_ダイレクト - [0:0] :出力方向 - [0:0] -A 入力 -j INPUT_direct -A フォワード -j FORWARD_direct -A 出力 -j OUTPUT_direct 犯罪 #2017年4月15日(土)01:40:57完了 # 2017年4月15日土曜日01:40:57にiptables-save v1.4.21によって作成されました *生の :事前ルーティングを許可[2362:184437] : 出力許可 [1229:185742] :出力方向 - [0:0] :PREROUTING_direct - [0:0] -A 辞書ルーティング -j 辞書ルーティング_direct -A 出力 -j OUTPUT_direct 犯罪 #2017年4月15日(土)01:40:57完了 # 2017年4月15日土曜日01:40:57にiptables-save v1.4.21によって作成されました *フィルター :入力承認[0:0] :転送を受け入れる[0:0] :出力承認[80:8149] :FORWARD_IN_ZONES - [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_public_log - [0:0] :FWDO_公開 - [0:0] :FWDO_public_allow - [0:0] :FWDO_public_deny - [0:0] :FWDO_public_log - [0:0] :INPUT_ZONES - [0:0] :INPUT_ZONES_SOURCE - [0:0] :INPUT_ダイレクト - [0:0] :IN_公開 - [0:0] :IN_public_allow - [0:0] :IN_public_deny - [0:0] :IN_public_log - [0:0] :出力方向 - [0:0] -A enter -m conntrack --ctstate 関連、設定 -j accept -A 入力 -i lo -j 受け入れ -A 入力 -j INPUT_direct -A 入力 -j INPUT_ZONES_SOURCE -A 入力 -j INPUT_ZONES -A 入力 -m conntrack --ctstate 無効 -j DROP -A Enter -j 拒否 --reject-with icmp-host-prohibited -A 転送 -m conntrack --ctstate 関連、設定済み -j 受け入れ -A フォワード -i lo -j 承諾 -A フォワード -j FORWARD_direct -A フォワード -j FORWARD_IN_ZONES_SOURCE -A 転送-j FORWARD_IN_ZONES -A フォワード -j FORWARD_OUT_ZONES_SOURCE -A FORWARD-j FORWARD_OUT_ZONES -A 順方向 -m conntrack --ctstate 無効 -j DROP -A FORWARD -j REJECT --icmp-host-禁止で拒否 -A 出力 -j OUTPUT_direct -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_public -j FWDI_public_log -A FWDI_public -j FWDI_public_deny -A FWDI_public -j FWDI_public_allow -A FWDI_public -p icmp -j を受け入れる -A FWDO_public -j FWDO_public_log -A FWDO_public -j FWDO_public_deny -A FWDO_public -j FWDO_public_allow -A INPUT_ZONES -i eth0 -g IN_public -A INPUT_ZONES -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 を受け入れる -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 30473 、長さ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, 28960, オプション [MSS 1470,4 p、 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 377045
リモートサーバーからローカルサーバーを介してWebサーバーに接続しようとすると、Webサーバーのtcpdumpはパケットをキャプチャしませんが(初期同期も含む)、ローカルサーバーはWebサーバーに送信された同期パケットをキャプチャします(以下を参照)。これにより、何かがパケットが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
重要:パケットはeth0を介してルーティングされず、代わりにtun0を介してネットワークサーバーにパケットを送信しようとします(失敗)。 tun0インターフェースでtcpdumpを実行してこれを確認できます。
[user@local ~]$ sudo tcpdump -nn -vv 'ポートが22および80ではありません。 -i tun0 tcpdump:tun0でリッスン、リンクタイプ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, ca
ノート3:
ローカルコンピュータでファイアウォールをオフにし、Webサーバーから同期パケットを受信しました。
[user@local~]$ sudo systemctl stopfirewalld
[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 7123510 ec 08:25:17.391003 IP(tos 0x0, ttl 64, id 0, オフセット 0, フラグ [DF], 生 TCP(6), 長さ 60) Web.server.80> 10.2.2.50580: ロゴ [s.], CKSUM 0x4E23 (エラー-> 0xa316), SEQ 959115533, ACK 2601927550, Win 28960, オプション [MSS 141 7なし、 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 ec 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, オプション [mss1 4 124517、なし、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
これで、パケットをネットワークサーバーに送信する前に、ソースIPをローカルサーバーのIPアドレスと一致するように更新する必要があることが明らかになりました。 @xinが提案したように、NATはローカルサーバーに設定する必要があります。
注#4:
Web サーバーに接続しようとすると、ルール 9 の pkts 数が 1 増加したことがわかります (下記参照)。
[User@local~]$ sudo iptables -nvL --line-numbers ......... Chain FORWARD(ポリシーは0パケット、0バイト許容) num pkts バイトターゲット prot オプトインソースターゲット 1 0 0すべて受け入れ - * * 0.0.0.0/0 0.0.0.0/0 ctstate関連、作成済み 2 0 0すべて受け入れ - lo * 0.0.0.0/0 0.0.0.0/0 3 1 60 FORWARD_direct All - * * 0.0.0.0/0 0.0.0.0/0 4 1 60 FORWARD_IN_ZONES_SOURCE All - * * 0.0.0.0/0 0.0.0.0/0 5 1 60 FORWARD_IN_ZONES All - * * 0.0.0.0/0 0.0.0.0/0 6 1 60 FORWARD_OUT_ZONES_SOURCE All - * * 0.0.0.0/0 0.0.0.0/0 7 1 60 FORWARD_OUT_ZONES All - * * 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ホスト拒否を無効にする ......... [user@local ~]$ sudo iptables -D 前方 9
FORWARDチェーン(上記の@xinが提案したように)からルール9を削除した後、Webサーバーに接続できました。
[User@local~]$ sudo iptables -nvL --line-numbers ......... Chain FORWARD(ポリシーは1パケット、60バイト許容) num pkts バイトターゲット prot オプトインソースターゲット 1 12 5857すべて承認 - * * 0.0.0.0/0 0.0.0.0/0 ctstate関連、確立 2 0 0すべて受け入れ - lo * 0.0.0.0/0 0.0.0.0/0 3 2 120 FORWARD_direct All - * * 0.0.0.0/0 0.0.0.0/0 4 2 120 FORWARD_IN_ZONES_SOURCE All - * * 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 All - * * 0.0.0.0/0 0.0.0.0/0 7 2 120 FORWARD_OUT_ZONES All - * * 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