Q&A
tap_dev は VPN などのトンネリングのために作成したものですか？
Server Bのeth0については使用しない予定ですので、図からは割愛しています。
やりたいこと
ServerBからServer Aのtap_dev 172.31.0.1との疎通をさせたいですが、一方方向のみ疎通が取れる状況です。
現在の状況
・ClientとServer A(eth1,tap_dev)へは双方向で疎通がとれています。
ルーティングも問題なさそうです。
・Server A(eth1,tap_dev)とServerB eth1は片方向で疎通が取れます。
Server A⇒Server B
Server A eth1 172.16.0.1⇒Server B 172.16.0.2 === ping OK
ServerA tap_dev 172.31.0.1 ⇒ Server B 172.16.0.2 === ping OK
.Server B ⇒ Server A
Server B 172.16.0.2 ⇒ ServerA eth1 172.16.0.1 === ping OK
Server B 172.16.0.2 ⇒ ServerA tap_dev 172.31.0.1 === ping NG
Server Aのroute -nの実行結果
[root@xxx-xxx-xxx-xxx ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 xxx.xxx.xxx.xxx 0.0.0.0 UG 100 0 0 eth0
xxx.xxx.xxx.0 0.0.0.0 255.255.254.0 U 100 0 0 eth0
172.16.0.0 0.0.0.0 255.255.255.0 U 100 0 0 eth1
172.31.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tap_dev
192.168.0.0 172.31.0.254 255.255.255.0 UG 0 0 0 tap_dev
Server Bのroute -nの実行結果
[root@yyy-yyy-yyy-yyy network-scripts]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 yyy.yyy.yyy.yyy 0.0.0.0 UG 100 0 0 eth0
yyy.yyy.yyy.0 0.0.0.0 255.255.254.0 U 100 0 0 eth0
172.16.0.0 0.0.0.0 255.255.255.0 U 100 0 0 eth1
172.31.0.0 172.16.0.1 255.255.255.0 UG 0 0 0 eth1
※192.168.0.0/24へのルートはまだ追加していません。
確認してみたこと
- Server Aでtcpdumpを実行し、Server Bから172.31.0.1へpingを実行
１. tcpdump -i eth1の実行結果
ServerA内でeth1からtap_devへリレーされています。
dumpをwiresharkで確認すると以下のようになります。
5 1.000035 172.16.0.2 172.31.0.1 ICMP 98 Echo (ping) request id=0x2992, seq=1861/17671, ttl=64 (reply in 6)
しかし、直接コンソールに表示すると以下のようになります。
11:32:14.206928 IP 172.16.0.2 > xxx-xxx-xxx-xxx: ICMP echo request, id 2506, seq 535, length 64
以上のことからServer BからServer A tap_dev 172.31.0.1へpingは送信されているものの、172.31.0.1からの戻りがeth1からではなくeth0に出てしまっているのではないかと考えました。
やってみたこと
SererAのtap_devからの戻りがeth1からではなくeth0から出てしまっているため戻れないので、eth1からServer Bへ戻れるようにServerAにソースルーティングの設定を行ってみました。
１．yum install NetworkManager-config-routing-rules -y
２．/etc/iproute2/rt_tablesファイルを開き、末尾に以下を記述を追加
1 inr.ruhep
200 rule200
３．/etc/sysconfig/network-scripts/ ディレクトリにrule-eth1を作成して以下を記述
from 172.16.0.1 table rule200
４．/etc/sysconfig/network-scripts/ ディレクトリにroute-eth1を作成して以下を記述
172.16.0.0/24 dev eth1 table rule200
default dev eth1 table rule200
※172.16.0.0/24にデフォルトゲートウェイにできるルーターなどのゲートウェイが存在しないため、デバイス名のみ記述しました。
５．設定を反映
systemctl restart network.service
参考サイト
https://ast.qt-space.com/linux/centos7.html 『AST的電子記憶箱』 CentOS7-ネットワーク設定-マルチホーム
https://mano.xyz/2033/ 『mano.xyz』 CentOS7 policy routing する (複数のデフォルトゲートウェイを設定する)
http://blog.techlab-xe.net/archives/5264 『すらりん日記』-ポリシーベースルーティングの話
質問の要領が悪く恐縮ではございますが、識者の皆様のご教授を頂戴できませんでしょうか。
よろしくお願いいたします。
コメントありがとうございます。
ご指摘のとおり、tap_devはVPN用になります。最終的にはserver⇒Client方向の通信ができるようになることが目標ですが、まずは、tap_devまでの疎通ができるようにしたいと考えていました。
回答1件
0
ベストアンサー
tap_dev は VPN 用とのことですので、VPN 接続機器どうしの通信のカプセル化を行なうためのインターフェースであって、それ以外のホストから tap_dev を意識する必要はないと思います。
しかし、直接コンソールに表示すると以下のようになります。
11:32:14.206928 IP 172.16.0.2 > xxx-xxx-xxx-xxx: ICMP echo request, id 2506, seq 535, length 64
「xxx-xxx-xxx-xxx」は伏せ字ではなく、そのままですか？
もし、そうだとすると、tap_dev ではカプセル化されたものを期待していたけれど、Server B から送られたパケットはカプセル化されていないものだったので、
送り先がわからない、ということではないでしょうか？ (自信なし)
172.31.0.1からの戻りがeth1からではなくeth0に出てしまっているのではないかと考えました。
送信元IP = 172.16.0.2 ですので、戻りは 宛先IP = 172.16.0.2 となり、eth1 から返すはずです。
投稿2018/05/06 16:09
総合スコア12146
ご回答ありがとうございます。
申し訳ありません。「xxx-xxx-xxx-xxx」は伏字です（アスタリスクの方がわかりやすいでしょうか？）。xxx-xxx-xxx-xxx-xxx はeth0が持っているグローバルIPです。
（尚、vpnはsoftetherでserver側がsoftether bridge client側にサーバーを置いています。
構成図は私の前回の質問に記載させていただいています。
https://teratail.com/questions/124570）
今、書いていて言うのもおかしいのですが、172.16.0.2⇒xxx.xxx.xxx.xxx(eth0)になっていますね。
wiresharkでdaumpを見ると、tap_devから返ってきているように見えるので、戻りだけがeht1ではなく、eht0に出ていってしまっていると思っていました。
tcpdumpの結果をそのまま見る限りだと直接、172.16.0.2からeth0に出ていってしまっていますね・・・どう読み取ったらよいのか悩みます。
tcpdump の結果はよくわかりませんね。
softether が何かしているのでしょうか？
ソースルーティングは一旦忘れて、Server B - Server A 間、Server A - Client 間の通信がそれぞれできているのであれば、プロキシーやポートフォワードで代替できないか検討してみてはいかがでしょうか。
そうですね。検討してみたいと思います。
あなたの回答
tips
プレビュー
