回答編集履歴
4
typoを微修正
test
CHANGED
@@ -64,7 +64,7 @@
|
|
64
64
|
|
65
65
|
ens32がIPアドレス自体が別のものがあたっていないといけない。
|
66
66
|
|
67
|
-
あるい
|
67
|
+
あるいは、別のVLANにens32がつながっていて、upしている必要があるけれど、私の知りうる限り、firewalldはNICへの転送はできずというか、そもそも想定しておらず、結局強制的にルートを切っても、IPアドレスの転送になり、その場合結局eth1側に行ってしまい、ens34で着信応答するしか無いように思える。
|
68
68
|
|
69
69
|
|
70
70
|
|
3
説明的に書き改め
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
書式修正
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
もう少し突っ込んで考察
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すればいいはずなので、特に問題ないように思える。
|