回答編集履歴

4

typoを微修正

2020/02/06 09:53

投稿

退会済みユーザー
test CHANGED
@@ -64,7 +64,7 @@
64
64
 
65
65
  ens32がIPアドレス自体が別のものがあたっていないといけない。
66
66
 
67
- あるいは、別のVLANにens32がつながっていて、upしている必要があるけれど、私の知りうる限り、firewalldはNICへの転送はできずというか、そもそも想定しておらず、IPアドレスの転送になり、その場合結局eth1側に行ってしまい、結局は強制的にルートをens34で着信応答するしか無いように思える。
67
+ あるいは、別のVLANにens32がつながっていて、upしている必要があるけれど、私の知りうる限り、firewalldはNICへの転送はできずというか、そもそも想定しておらず、結局強制的にルートを切っても、IPアドレスの転送になり、その場合結局eth1側に行ってしまい、ens34で着信応答するしか無いように思える。
68
68
 
69
69
 
70
70
 

3

説明的に書き改め

2020/02/06 09:53

投稿

退会済みユーザー
test CHANGED
@@ -48,7 +48,7 @@
48
48
 
49
49
  もしens32をupしないとなると、そもそも転送できないはず。
50
50
 
51
- この時点で同一セグメントに同じIPアドレスが存在することになってしまいます。
51
+ というわけでens32をupすると、この時点で同一セグメントに同じIPアドレスが存在することになってしまいます。
52
52
 
53
53
  これは可能なのかな?
54
54
 
@@ -64,6 +64,8 @@
64
64
 
65
65
  ens32がIPアドレス自体が別のものがあたっていないといけない。
66
66
 
67
+ あるいいは、別のVLANにens32がつながっていて、upしている必要があるけれど、私の知りうる限り、firewalldはNICへの転送はできずというか、そもそも想定しておらず、IPアドレスの転送になり、その場合結局eth1側に行ってしまい、結局は強制的にルートをens34で着信応答するしか無いように思える。
68
+
67
69
 
68
70
 
69
71
  > ・切替時は、ens34を無効化+@して、ens32が直接応答する。

2

書式修正

2020/02/06 09:51

投稿

退会済みユーザー
test CHANGED
@@ -34,6 +34,8 @@
34
34
 
35
35
  > 他のサーバから172.17.1.100(ens32)が応答してはいけない。
36
36
 
37
+
38
+
37
39
  ens32の設定だけ入れて、downしておけばいいはず
38
40
 
39
41
 
@@ -41,6 +43,8 @@
41
43
  > ・構築時、ens34が他のサーバから応答する
42
44
 
43
45
  > リクエストはすべてens32に転送する。
46
+
47
+
44
48
 
45
49
  もしens32をupしないとなると、そもそも転送できないはず。
46
50
 
@@ -54,6 +58,8 @@
54
58
 
55
59
  > リクエストはすべてens34経由で戻す
56
60
 
61
+
62
+
57
63
  まずupしているという前提と、IPアドレスが衝突しないという前提が矛盾する。
58
64
 
59
65
  ens32がIPアドレス自体が別のものがあたっていないといけない。
@@ -64,4 +70,6 @@
64
70
 
65
71
  > アプリ側の設定変更はしない。
66
72
 
73
+
74
+
67
75
  これは普通にeth1をdownすればいいはずなので、特に問題ないように思える。

1

もう少し突っ込んで考察

2020/02/06 09:42

投稿

退会済みユーザー
test CHANGED
@@ -4,4 +4,64 @@
4
4
 
5
5
 
6
6
 
7
+ ens34とens32がnetwork addressが別である前提で話すとすると、
8
+
9
+ ens34からens32へルートを切ればいいように思えます。
10
+
11
+ しかしそのためには、ens32がupしていないといけません。
12
+
13
+
14
+
15
+ ですから、ens32をdownさせておいて、切り替え時にupするぐらいが適切なんだと思います。
16
+
17
+
18
+
19
+ もし同じnetwork addressであるとするなら、
20
+
21
+ そもそも、ens34のアドレスを、172.17.1.100に変更すればいいだけに思えてしまいます。
22
+
23
+
24
+
7
25
  切替時は、可能な限り単純な操作にすべきですし、切り戻しも比較的簡単な操作で済みます。
26
+
27
+ そのため、ens32をdownしておき、切替時にupするような方法が望ましいように思えます。
28
+
29
+
30
+
31
+ 以下は当初少々勘違いしておりましたが、気になるので、
32
+
33
+ > ・本番機と構築時は同一セグメント上で構築するため、
34
+
35
+ > 他のサーバから172.17.1.100(ens32)が応答してはいけない。
36
+
37
+ ens32の設定だけ入れて、downしておけばいいはず
38
+
39
+
40
+
41
+ > ・構築時、ens34が他のサーバから応答する
42
+
43
+ > リクエストはすべてens32に転送する。
44
+
45
+ もしens32をupしないとなると、そもそも転送できないはず。
46
+
47
+ この時点で同一セグメントに同じIPアドレスが存在することになってしまいます。
48
+
49
+ これは可能なのかな?
50
+
51
+
52
+
53
+ > ・構築時、ens32は他のサーバから直接応答しない。
54
+
55
+ > リクエストはすべてens34経由で戻す
56
+
57
+ まずupしているという前提と、IPアドレスが衝突しないという前提が矛盾する。
58
+
59
+ ens32がIPアドレス自体が別のものがあたっていないといけない。
60
+
61
+
62
+
63
+ > ・切替時は、ens34を無効化+@して、ens32が直接応答する。
64
+
65
+ > アプリ側の設定変更はしない。
66
+
67
+ これは普通にeth1をdownすればいいはずなので、特に問題ないように思える。