質問編集履歴
19
字数制限による、新たな投稿
title
CHANGED
File without changes
|
body
CHANGED
@@ -283,14 +283,9 @@
|
|
283
283
|
|
284
284
|
普段のネット接続と別の通信にしたいなどの要望は多く、ip routeやvpnでの対応が多いが、設定を大幅に変更してしまい、普段のネットワーク環境を破壊する恐れがあるので、簡単な操作・変更で済みそうなプロキシーにより実現できると良い。
|
285
285
|
|
286
|
-
```
|
287
|
-
|
286
|
+
### 続き
|
288
|
-
|
287
|
+
字数制限のため、[新たな投稿](https://teratail.com/questions/145425)をしました。
|
289
288
|
|
290
|
-
### 該当のソースコード
|
291
|
-
|
292
|
-
|
293
|
-
### 試したこと
|
294
289
|
### 補足情報(FW/ツールのバージョンなど)
|
295
290
|
dante 1.52.10.2
|
296
291
|
iptables v1.6.0
|
18
eth1のipがdhcp再リースで変更されたこと。
title
CHANGED
File without changes
|
body
CHANGED
@@ -115,7 +115,7 @@
|
|
115
115
|
danteなら異なるnic間の転送ができると期待しましたが、異なるネットワークセグメント間の転送はできないようです。
|
116
116
|
|
117
117
|
```
|
118
|
-
root@raspberrypi:/
|
118
|
+
root@raspberrypi:/# ip route
|
119
119
|
default via 192.168.0.1 dev eth0 src 192.168.0.3 metric 202
|
120
120
|
default via 192.168.1.1 dev eth1 src 192.168.1.3 metric 203
|
121
121
|
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.3 metric 202
|
@@ -179,13 +179,15 @@
|
|
179
179
|
rpiが起動しなくなり、再インストールしてから、squid + iptables で同様の設定までしたところ、何故かsub-gwへの転送ができなくなってしまいました。
|
180
180
|
|
181
181
|
やっていることは、「特定ユーザのip route変更」です。squidのユーザーであるproxyのip route変更のため、このサイトを参考にし、
|
182
|
+
(当該記事は、異なるnicの切り替えでなく、単純な同一ネットワーク内でのgw変更である)
|
182
183
|
http://d.hatena.ne.jp/rti7743/20150320/1426880601
|
184
|
+
|
183
185
|
以下の操作をしました。
|
184
186
|
|
185
187
|
squidユーザのルーティングテーブル変更コード
|
186
188
|
```
|
187
189
|
|
188
|
-
#再起動で各nicのipが変動するための取得方法
|
190
|
+
#再起動で各nicのipが再dhcpリースにより変動するための自動的な取得方法
|
189
191
|
#https://askubuntu.com/questions/430853/how-do-i-find-my-internal-ip-address
|
190
192
|
|
191
193
|
eth0_ip=$(ip addr show eth0 |grep -v inet6 | awk '/inet/ {print $2}' | cut -d/ -f1) &&
|
@@ -260,7 +262,6 @@
|
|
260
262
|
Chain POSTROUTING (policy ACCEPT)
|
261
263
|
target prot opt source destination
|
262
264
|
|
263
|
-
|
264
265
|
```
|
265
266
|
|
266
267
|
また、rpi側から見たtcpdumpの結果としては、
|
@@ -269,6 +270,8 @@
|
|
269
270
|
物理nicがeth1でのdumpなのに、srcipがeth0のipとなり、
|
270
271
|
サーバからの応答を受信できません。
|
271
272
|
|
273
|
+
proxygwのルーティングテーブルは理解していますが、iptablesのmangleはまだ正しく理解していないところです。
|
274
|
+
|
272
275
|
###事前調査について
|
273
276
|
|
274
277
|
よく「linuxルータを作ろう」などという記事があり、
|
17
rpi再インストールで、squid + iptables でsub-gwへの転送ができなくなった。
title
CHANGED
File without changes
|
body
CHANGED
@@ -174,6 +174,101 @@
|
|
174
174
|
自分でツール開発できるスキルはありません。
|
175
175
|
|
176
176
|
|
177
|
+
## 発生している問題・エラーメッセージ)(その3)
|
178
|
+
|
179
|
+
rpiが起動しなくなり、再インストールしてから、squid + iptables で同様の設定までしたところ、何故かsub-gwへの転送ができなくなってしまいました。
|
180
|
+
|
181
|
+
やっていることは、「特定ユーザのip route変更」です。squidのユーザーであるproxyのip route変更のため、このサイトを参考にし、
|
182
|
+
http://d.hatena.ne.jp/rti7743/20150320/1426880601
|
183
|
+
以下の操作をしました。
|
184
|
+
|
185
|
+
squidユーザのルーティングテーブル変更コード
|
186
|
+
```
|
187
|
+
|
188
|
+
#再起動で各nicのipが変動するための取得方法
|
189
|
+
#https://askubuntu.com/questions/430853/how-do-i-find-my-internal-ip-address
|
190
|
+
|
191
|
+
eth0_ip=$(ip addr show eth0 |grep -v inet6 | awk '/inet/ {print $2}' | cut -d/ -f1) &&
|
192
|
+
eth1_ip=$(ip addr show eth1 |grep -v inet6 | awk '/inet/ {print $2}' | cut -d/ -f1)
|
193
|
+
|
194
|
+
proxy_route_tbl=proxygw &&
|
195
|
+
proxy_route_tbl_number=201 &&
|
196
|
+
echo 1 > /proc/sys/net/ipv4/ip_forward &&
|
197
|
+
echo "$proxy_route_tbl_number $proxy_route_tbl" >> /etc/iproute2/rt_tables &&
|
198
|
+
ip rule add fwmark 1 table $proxy_route_tbl &&
|
199
|
+
ip route add table $proxy_route_tbl default via 192.168.0.1 dev eth0 src $eth0_ip metric 203 &&
|
200
|
+
ip route add table $proxy_route_tbl default via 192.168.1.1 dev eth1 src $eth1_ip metric 202 &&
|
201
|
+
ip route add table $proxy_route_tbl 192.168.0.0/24 dev eth0 proto kernel scope link src $eth0_ip metric 203 &&
|
202
|
+
ip route add table $proxy_route_tbl 192.168.1.0/24 dev eth1 proto kernel scope link src $eth1_ip metric 202 &&
|
203
|
+
iptables -t mangle -P OUTPUT ACCEPT &&
|
204
|
+
iptables -t mangle -A OUTPUT -m owner --uid-owner proxy -j MARK --set-mark 1
|
205
|
+
|
206
|
+
# ip route,iptables 初期化用
|
207
|
+
|
208
|
+
ip rule del fwmark 1 table $proxy_route_tbl &&
|
209
|
+
ip route del table $proxy_route_tbl default via 192.168.0.1 dev eth0 src $eth0_ip metric 203 &&
|
210
|
+
ip route del table $proxy_route_tbl default via 192.168.1.1 dev eth1 src $eth1_ip metric 202 &&
|
211
|
+
ip route del table $proxy_route_tbl 192.168.0.0/24 dev eth0 proto kernel scope link src $eth0_ip metric 203 &&
|
212
|
+
ip route del table $proxy_route_tbl 192.168.1.0/24 dev eth1 proto kernel scope link src $eth1_ip metric 202 &&
|
213
|
+
iptables -F &&
|
214
|
+
iptables -F -t mangle
|
215
|
+
|
216
|
+
```
|
217
|
+
また、変更後のip route,iptablesの設定は、
|
218
|
+
|
219
|
+
ip routeの変更後の設定
|
220
|
+
```
|
221
|
+
root@raspberrypi:/# ip route show table main
|
222
|
+
default via 192.168.0.1 dev eth0 src 192.168.0.3 metric 202
|
223
|
+
default via 192.168.1.1 dev eth1 src 192.168.1.5 metric 203
|
224
|
+
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.3 metric 202
|
225
|
+
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.5 metric 203
|
226
|
+
|
227
|
+
root@raspberrypi:/# ip route show table proxygw
|
228
|
+
default via 192.168.1.1 dev eth1 src 192.168.1.5 metric 202
|
229
|
+
default via 192.168.0.1 dev eth0 src 192.168.0.3 metric 203
|
230
|
+
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.3 metric 203
|
231
|
+
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.5 metric 202
|
232
|
+
```
|
233
|
+
iptablesの変更後の設定
|
234
|
+
|
235
|
+
```
|
236
|
+
root@raspberrypi:/# iptables -L
|
237
|
+
Chain INPUT (policy ACCEPT)
|
238
|
+
target prot opt source destination
|
239
|
+
|
240
|
+
Chain FORWARD (policy ACCEPT)
|
241
|
+
target prot opt source destination
|
242
|
+
|
243
|
+
Chain OUTPUT (policy ACCEPT)
|
244
|
+
target prot opt source destination
|
245
|
+
|
246
|
+
root@raspberrypi:/# iptables -L -t mangle
|
247
|
+
Chain PREROUTING (policy ACCEPT)
|
248
|
+
target prot opt source destination
|
249
|
+
|
250
|
+
Chain INPUT (policy ACCEPT)
|
251
|
+
target prot opt source destination
|
252
|
+
|
253
|
+
Chain FORWARD (policy ACCEPT)
|
254
|
+
target prot opt source destination
|
255
|
+
|
256
|
+
Chain OUTPUT (policy ACCEPT)
|
257
|
+
target prot opt source destination
|
258
|
+
MARK all -- anywhere anywhere owner UID match proxy MARK set 0x1
|
259
|
+
|
260
|
+
Chain POSTROUTING (policy ACCEPT)
|
261
|
+
target prot opt source destination
|
262
|
+
|
263
|
+
|
264
|
+
```
|
265
|
+
|
266
|
+
また、rpi側から見たtcpdumpの結果としては、
|
267
|
+
client-rpi間は、普通に (eth0のip):3128 への通信
|
268
|
+
rpi-通信先サーバ間は、例えば1.1.1.1宛にすると、
|
269
|
+
物理nicがeth1でのdumpなのに、srcipがeth0のipとなり、
|
270
|
+
サーバからの応答を受信できません。
|
271
|
+
|
177
272
|
###事前調査について
|
178
273
|
|
179
274
|
よく「linuxルータを作ろう」などという記事があり、
|
16
あ
title
CHANGED
File without changes
|
body
CHANGED
@@ -181,8 +181,10 @@
|
|
181
181
|
今回はrpiをgwとする通常のルータの利用方法とは違うので、
|
182
182
|
それらの記事を参考にして、目標を達成することはできません。
|
183
183
|
|
184
|
-
また、英語の質問サイトで、本質問で挙げた3つのツールと「異なるnicに変更する方法」、「異なるネットワークに転送する方法」を調べても、これといったものはありませんでした。
|
184
|
+
また、英語の質問サイトで、本質問で挙げた3つのツールと「異なるnicに変更する方法」、「異なるネットワークに転送する方法」を調べても、これといったものはありませんでした。
|
185
185
|
|
186
|
+
普段のネット接続と別の通信にしたいなどの要望は多く、ip routeやvpnでの対応が多いが、設定を大幅に変更してしまい、普段のネットワーク環境を破壊する恐れがあるので、簡単な操作・変更で済みそうなプロキシーにより実現できると良い。
|
187
|
+
|
186
188
|
```
|
187
189
|
エラーメッセージ
|
188
190
|
```
|
15
事前調査について
title
CHANGED
File without changes
|
body
CHANGED
@@ -173,11 +173,15 @@
|
|
173
173
|
どうしようもありません。
|
174
174
|
自分でツール開発できるスキルはありません。
|
175
175
|
|
176
|
+
|
177
|
+
###事前調査について
|
178
|
+
|
176
179
|
よく「linuxルータを作ろう」などという記事があり、
|
177
180
|
異なるネットワーク間の通信を異なるnicでクリアしていますが、
|
178
181
|
今回はrpiをgwとする通常のルータの利用方法とは違うので、
|
179
182
|
それらの記事を参考にして、目標を達成することはできません。
|
180
183
|
|
184
|
+
また、英語の質問サイトで、本質問で挙げた3つのツールと「異なるnicに変更する方法」、「異なるネットワークに転送する方法」を調べても、これといったものはありませんでした。(普段のネット接続と別の通信にしたいなどの要望は多く、vpnでの対応が多いが、望ましくない。)
|
181
185
|
|
182
186
|
```
|
183
187
|
エラーメッセージ
|
14
誤字脱字
title
CHANGED
File without changes
|
body
CHANGED
@@ -130,7 +130,7 @@
|
|
130
130
|
|
131
131
|
http/httpsプロキシだと、本来の通信先サーバがどこでも、
|
132
132
|
client-pcがrpi-eth0 (192.168.0.3:3218)を宛先とする通信しかしない
|
133
|
-
(client
|
133
|
+
(client-pcからwiresharkで確認)ので、
|
134
134
|
squidで処理したあとの通信をどうにかしてsubnet-Bに向ける事が重要です。
|
135
135
|
|
136
136
|
####中継プロキシ-通信先サーバの間の通信について
|
13
ツールのバージョンの追加
title
CHANGED
File without changes
|
body
CHANGED
@@ -7,8 +7,6 @@
|
|
7
7
|
|
8
8
|
2つの回線があり、メインの回線とは別に、特定の操作をした時に通信がサブ回線を経由するようにしたい。
|
9
9
|
今、以下のようなネットワーク構成であるとする。
|
10
|
-
(左側のaはスペースを反映させるための装飾で、特に意味はない。
|
11
|
-
また、モバイル版では図が崩れて表示されます。)
|
12
10
|
|
13
11
|
```
|
14
12
|
(subnet-A : 192.168.0.0/24)
|
@@ -24,9 +22,9 @@
|
|
24
22
|
(subnet-B : 192.168.1.0/24)
|
25
23
|
```
|
26
24
|
|
27
|
-
client-pc:ubuntu 18.04 (client-pcは今後増える可能性あり)
|
25
|
+
client-pc : ubuntu 18.04 (client-pcは今後増える可能性あり)
|
28
|
-
rpi: raspberry pi stretch
|
26
|
+
rpi : raspberry pi stretch
|
29
|
-
main-gw,sub-gw:市販のルータで、dhcpサーバ機能を持つ
|
27
|
+
main-gw,sub-gw : 市販のルータで、dhcpサーバ機能を持つ
|
30
28
|
|
31
29
|
rpiには、lanケーブルとusb-lanアダプタの2つのnicがついており、それぞれeth0,eth1である。また、ip割当は各ルータのdhcp機能により行った。rpiがルータの役割をする事はない。
|
32
30
|
|
@@ -190,4 +188,6 @@
|
|
190
188
|
|
191
189
|
### 試したこと
|
192
190
|
### 補足情報(FW/ツールのバージョンなど)
|
193
|
-
dante 1.52.10.2
|
191
|
+
dante 1.52.10.2
|
192
|
+
iptables v1.6.0
|
193
|
+
squid3-3.5.23
|
12
ネットワーク構成図の修正その2
title
CHANGED
File without changes
|
body
CHANGED
@@ -1,4 +1,3 @@
|
|
1
|
-
```
|
2
1
|
## 注意点
|
3
2
|
|
4
3
|
この質問は、既に行った方法と、これからやろうと試みているが、理解が足りず進んでいない部分を並列して載せているので、読みづらいかと思います。
|
@@ -11,6 +10,7 @@
|
|
11
10
|
(左側のaはスペースを反映させるための装飾で、特に意味はない。
|
12
11
|
また、モバイル版では図が崩れて表示されます。)
|
13
12
|
|
13
|
+
```
|
14
14
|
(subnet-A : 192.168.0.0/24)
|
15
15
|
clien-pc(192.168.0.2)ー main-gw(192.168.0.1)ーwan1
|
16
16
|
|
|
@@ -22,6 +22,7 @@
|
|
22
22
|
|
|
23
23
|
sub-gw (192.168.1.1)ーwan2
|
24
24
|
(subnet-B : 192.168.1.0/24)
|
25
|
+
```
|
25
26
|
|
26
27
|
client-pc:ubuntu 18.04 (client-pcは今後増える可能性あり)
|
27
28
|
rpi: raspberry pi stretch
|
@@ -189,5 +190,4 @@
|
|
189
190
|
|
190
191
|
### 試したこと
|
191
192
|
### 補足情報(FW/ツールのバージョンなど)
|
192
|
-
dante 1.52.10.2
|
193
|
+
dante 1.52.10.2
|
193
|
-
```
|
11
ネットワーク構成図の修正
title
CHANGED
File without changes
|
body
CHANGED
@@ -1,3 +1,4 @@
|
|
1
|
+
```
|
1
2
|
## 注意点
|
2
3
|
|
3
4
|
この質問は、既に行った方法と、これからやろうと試みているが、理解が足りず進んでいない部分を並列して載せているので、読みづらいかと思います。
|
@@ -12,14 +13,14 @@
|
|
12
13
|
|
13
14
|
(subnet-A : 192.168.0.0/24)
|
14
15
|
clien-pc(192.168.0.2)ー main-gw(192.168.0.1)ーwan1
|
15
|
-
|
16
|
+
|
|
16
|
-
|
17
|
+
|
|
17
|
-
|
18
|
+
|
|
18
|
-
|
19
|
+
rpi-eth0 (192.168.0.3)
|
19
|
-
|
20
|
+
| (rpi内部)
|
20
|
-
|
21
|
+
rpi-eth1 (192.168.1.3)
|
21
|
-
|
22
|
+
|
|
22
|
-
|
23
|
+
sub-gw (192.168.1.1)ーwan2
|
23
24
|
(subnet-B : 192.168.1.0/24)
|
24
25
|
|
25
26
|
client-pc:ubuntu 18.04 (client-pcは今後増える可能性あり)
|
@@ -188,4 +189,5 @@
|
|
188
189
|
|
189
190
|
### 試したこと
|
190
191
|
### 補足情報(FW/ツールのバージョンなど)
|
191
|
-
dante 1.52.10.2
|
192
|
+
dante 1.52.10.2
|
193
|
+
```
|
10
あ
title
CHANGED
File without changes
|
body
CHANGED
@@ -1,13 +1,14 @@
|
|
1
|
-
##
|
1
|
+
## 注意点
|
2
2
|
|
3
3
|
この質問は、既に行った方法と、これからやろうと試みているが、理解が足りず進んでいない部分を並列して載せているので、読みづらいかと思います。
|
4
4
|
ご了承ください。
|
5
5
|
|
6
|
-
##
|
6
|
+
##前提・実現したいこと
|
7
7
|
|
8
8
|
2つの回線があり、メインの回線とは別に、特定の操作をした時に通信がサブ回線を経由するようにしたい。
|
9
9
|
今、以下のようなネットワーク構成であるとする。
|
10
|
-
(左側のaはスペースを反映させるための装飾で、特に意味はない
|
10
|
+
(左側のaはスペースを反映させるための装飾で、特に意味はない。
|
11
|
+
また、モバイル版では図が崩れて表示されます。)
|
11
12
|
|
12
13
|
(subnet-A : 192.168.0.0/24)
|
13
14
|
clien-pc(192.168.0.2)ー main-gw(192.168.0.1)ーwan1
|
@@ -42,7 +43,7 @@
|
|
42
43
|
使用したツールについての動作や概念を正しく理解している自信がないため、
|
43
44
|
自分の理解を提示しつつ、説明を書いていきます。
|
44
45
|
|
45
|
-
##
|
46
|
+
## 発生している問題・エラーメッセージ(その1)
|
46
47
|
danteについて
|
47
48
|
```
|
48
49
|
・subnet-B宛の通信はeth1を経由するが、それ以外はeth0経由となる。
|
@@ -88,9 +89,9 @@
|
|
88
89
|
|
89
90
|
また、上記に記載したdanted.confの設定により、eth0からeth1に転送できるようにしたつもり。
|
90
91
|
|
91
|
-
|
92
|
+
####client-pcからのsocks proxy接続の結果について、
|
92
93
|
|
93
|
-
|
94
|
+
sub-gw(192.168.1.1)の管理画面にはアクセスできる、つまり、
|
94
95
|
subnet-B(eth1を経由とは書かない)を経由しているが、
|
95
96
|
1.1.1.1 (dns無しでhttp/httpsアクセス可能なアドレスで試行) には、
|
96
97
|
subnet-Aを経由しています。
|
@@ -105,7 +106,7 @@
|
|
105
106
|
送信先ネットワークセグメントの違いとは限らない、ということなので、
|
106
107
|
セグメント分けには利用できないです。
|
107
108
|
|
108
|
-
|
109
|
+
####proxy server本体となるrpiを送信元とする結果について
|
109
110
|
|
110
111
|
rpiにssh loginしてpingすると、
|
111
112
|
subnet-B宛はeth1を通るが、
|
@@ -121,9 +122,10 @@
|
|
121
122
|
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.3 metric 203
|
122
123
|
```
|
123
124
|
|
124
|
-
##
|
125
|
+
## 発生している問題・エラーメッセージ(というより、方法を模索中)(その2)
|
125
|
-
squid + iptablesについて
|
126
126
|
|
127
|
+
###squid + iptablesについて
|
128
|
+
|
127
129
|
次に考えたことは、rpiにsquidを立て、client-pcからsquidに対する通信をiptablesによりsubnet-Bへルーティングする事です。http/httpsプロキシの挙動については知らないので、自分の理解を示しながら説明していきます。
|
128
130
|
|
129
131
|
http/httpsプロキシだと、本来の通信先サーバがどこでも、
|
@@ -131,7 +133,7 @@
|
|
131
133
|
(client pcからwirsharkで確認)ので、
|
132
134
|
squidで処理したあとの通信をどうにかしてsubnet-Bに向ける事が重要です。
|
133
135
|
|
134
|
-
|
136
|
+
####中継プロキシ-通信先サーバの間の通信について
|
135
137
|
|
136
138
|
http/httpsのproxy接続では、中継プロキシ-通信先サーバの間の通信は、
|
137
139
|
メインの通信内容(layer5以上?)はclient-pcのもの、
|
@@ -171,7 +173,12 @@
|
|
171
173
|
どうしようもありません。
|
172
174
|
自分でツール開発できるスキルはありません。
|
173
175
|
|
176
|
+
よく「linuxルータを作ろう」などという記事があり、
|
177
|
+
異なるネットワーク間の通信を異なるnicでクリアしていますが、
|
178
|
+
今回はrpiをgwとする通常のルータの利用方法とは違うので、
|
179
|
+
それらの記事を参考にして、目標を達成することはできません。
|
174
180
|
|
181
|
+
|
175
182
|
```
|
176
183
|
エラーメッセージ
|
177
184
|
```
|
9
ネットワークの質問なのに、説明不足と致命的なミス、さらに説明の流れがなっていないので、修正
title
CHANGED
@@ -1,1 +1,1 @@
|
|
1
|
-
|
1
|
+
プロキシー接続による異なるネットワーク間のルーティングができない
|
body
CHANGED
@@ -1,36 +1,51 @@
|
|
1
|
+
### 注意点
|
2
|
+
|
3
|
+
この質問は、既に行った方法と、これからやろうと試みているが、理解が足りず進んでいない部分を並列して載せているので、読みづらいかと思います。
|
4
|
+
ご了承ください。
|
5
|
+
|
1
6
|
### 前提・実現したいこと
|
2
|
-
(書いている途中ですが、何個か試したので、随時追加で投稿します。)
|
3
7
|
|
4
|
-
2つの回線があり、メインの回線とは別に、特定の操作をした時にサブ回線を
|
8
|
+
2つの回線があり、メインの回線とは別に、特定の操作をした時に通信がサブ回線を経由するようにしたい。
|
9
|
+
今、以下のようなネットワーク構成であるとする。
|
5
|
-
|
10
|
+
(左側のaはスペースを反映させるための装飾で、特に意味はない)
|
6
11
|
|
7
|
-
(subnet
|
12
|
+
(subnet-A : 192.168.0.0/24)
|
8
|
-
pc(192.168.0.2)
|
13
|
+
clien-pc(192.168.0.2)ー main-gw(192.168.0.1)ーwan1
|
9
14
|
a |
|
10
15
|
a |
|
11
16
|
a |
|
12
|
-
a rpi
|
17
|
+
a rpi-eth0 (192.168.0.3)
|
13
|
-
a |(rpi内部)
|
18
|
+
a | (rpi内部)
|
14
|
-
a rpi
|
19
|
+
a rpi-eth1 (192.168.1.3)
|
15
|
-
a
|
20
|
+
a |
|
16
|
-
a sub
|
21
|
+
a sub-gw (192.168.1.1)ーwan2
|
17
|
-
(subnet
|
22
|
+
(subnet-B : 192.168.1.0/24)
|
18
23
|
|
24
|
+
client-pc:ubuntu 18.04 (client-pcは今後増える可能性あり)
|
25
|
+
rpi: raspberry pi stretch
|
19
|
-
|
26
|
+
main-gw,sub-gw:市販のルータで、dhcpサーバ機能を持つ
|
20
|
-
どんな方法でも良いが、client pcのip routeの変更やvpn設定はしたくない。
|
21
|
-
あくまでも、簡易な特定の操作により、wan2が利用できることが望ましいので、
|
22
|
-
大きな変更はプロキシとなるrpiに対して行うものとする。
|
23
|
-
(プログラムの通信も通すことを考えて)
|
24
27
|
|
25
|
-
自分が考えている方法は、rpi eth0にプロキシ接続をして、ルーティングされる方法です。
|
26
|
-
|
28
|
+
rpiには、lanケーブルとusb-lanアダプタの2つのnicがついており、それぞれeth0,eth1である。また、ip割当は各ルータのdhcp機能により行った。rpiがルータの役割をする事はない。
|
27
|
-
できなかったので、経緯を詳しく書きます。
|
28
|
-
使用したツールについての動作や概念を正しく理解している自身はありません。
|
29
29
|
|
30
|
+
特定の操作をしたときに、client-pcの通信がsub-gwを経由してwan2を利用できればよいので、
|
31
|
+
どんな方法でも良いが、client-pcのip routeの変更やvpn設定はしたくない。
|
32
|
+
|
33
|
+
プログラムの通信を経由させる事を考えると、プログラム上でも人間でも簡単な操作により、wan2が利用できることが望ましいので、方法はプロキシあたりになると思います。
|
34
|
+
そして、大きな変更はプロキシとなるrpiに対して行うものとして、
|
35
|
+
client機器には負担をかけたくない。
|
36
|
+
|
37
|
+
自分が考えている方法は、rpi-eth0にプロキシ接続をして、ルーティングされる方法です。
|
38
|
+
やった方法は、 「dante socks proxy」で、
|
39
|
+
途中で諦めて、再び試しているのは、「squid + iptables」です。
|
40
|
+
|
41
|
+
できていないので、経緯を詳しく書きます。
|
42
|
+
使用したツールについての動作や概念を正しく理解している自信がないため、
|
43
|
+
自分の理解を提示しつつ、説明を書いていきます。
|
44
|
+
|
30
45
|
### 発生している問題・エラーメッセージ(その1)
|
31
46
|
danteについて
|
32
47
|
```
|
33
|
-
|
48
|
+
・subnet-B宛の通信はeth1を経由するが、それ以外はeth0経由となる。
|
34
49
|
```
|
35
50
|
|
36
51
|
### 該当のソースコード
|
@@ -63,23 +78,40 @@
|
|
63
78
|
```
|
64
79
|
|
65
80
|
### 試したこと
|
81
|
+
|
82
|
+
まず、firefoxのプロキシ設定を
|
83
|
+
|
66
|
-
|
84
|
+
protocol version : socks_v4 or v5
|
85
|
+
proxy server:eth0のipアドレス
|
86
|
+
|
87
|
+
に設定した。
|
88
|
+
|
67
|
-
また、上記に記載したdanted.confの設定により、eth0からeth1に転送できるようにした。
|
89
|
+
また、上記に記載したdanted.confの設定により、eth0からeth1に転送できるようにしたつもり。
|
90
|
+
|
91
|
+
まず、client-pcからのsocks proxy接続の結果について、
|
92
|
+
|
68
|
-
すると、sub
|
93
|
+
すると、sub-gw(192.168.1.1)の管理画面にはアクセスできる、つまり、
|
69
|
-
subnet
|
94
|
+
subnet-B(eth1を経由とは書かない)を経由しているが、
|
70
95
|
1.1.1.1 (dns無しでhttp/httpsアクセス可能なアドレスで試行) には、
|
71
|
-
subnet
|
96
|
+
subnet-Aを経由しています。
|
72
97
|
|
73
98
|
tcpdumpで確認すると、
|
74
|
-
subnet
|
99
|
+
subnet-B宛は、tcpdump -i eth1 で確認できるが、
|
75
100
|
1.1.1.1宛は、tcpdump -i eth0で、しかも送信元が192.168.1.3(eth1)のアドレスです。
|
101
|
+
|
76
102
|
つまり、danteの設定において、
|
77
|
-
宛先がsubnet
|
103
|
+
宛先がsubnet-B以外だと、必ずeth0から出力されるが、送信元がexternalで設定したeth1のアドレスとなり、応答パケット受信できないです。
|
104
|
+
この意味は、danteの設定において、interanlとexternalが異なる事は、
|
78
|
-
|
105
|
+
送信先ネットワークセグメントの違いとは限らない、ということなので、
|
106
|
+
セグメント分けには利用できないです。
|
107
|
+
|
108
|
+
次に、proxy server本体となるrpiを送信元とする結果について
|
109
|
+
|
79
|
-
|
110
|
+
rpiにssh loginしてpingすると、
|
111
|
+
subnet-B宛はeth1を通るが、
|
80
112
|
それ以外はeth0を経由しており、
|
81
113
|
宛先選択には、danteの設定以前にosのルーティングテーブルが優先されているようです。(以下に貼り付けた)
|
82
|
-
danteなら異なるnic間の転送ができると期待しましたが。
|
114
|
+
danteなら異なるnic間の転送ができると期待しましたが、異なるネットワークセグメント間の転送はできないようです。
|
83
115
|
|
84
116
|
```
|
85
117
|
root@raspberrypi:/etc# ip route
|
@@ -89,14 +121,24 @@
|
|
89
121
|
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.3 metric 203
|
90
122
|
```
|
91
123
|
|
92
|
-
### 発生している問題・エラーメッセージ(その2)
|
124
|
+
### 発生している問題・エラーメッセージ(というより、方法を模索中)(その2)
|
93
|
-
squid + iptablesについて
|
125
|
+
squid + iptablesについて
|
94
126
|
|
95
|
-
次に考えたことは、rpiにsquidを立て、client
|
127
|
+
次に考えたことは、rpiにsquidを立て、client-pcからsquidに対する通信をiptablesによりsubnet-Bへルーティングする事です。http/httpsプロキシの挙動については知らないので、自分の理解を示しながら説明していきます。
|
96
128
|
|
129
|
+
http/httpsプロキシだと、本来の通信先サーバがどこでも、
|
97
|
-
|
130
|
+
client-pcがrpi-eth0 (192.168.0.3:3218)を宛先とする通信しかしない
|
131
|
+
(client pcからwirsharkで確認)ので、
|
132
|
+
squidで処理したあとの通信をどうにかしてsubnet-Bに向ける事が重要です。
|
98
133
|
|
134
|
+
次に、中継プロキシ-通信先サーバの間の通信について
|
135
|
+
|
136
|
+
http/httpsのproxy接続では、中継プロキシ-通信先サーバの間の通信は、
|
137
|
+
メインの通信内容(layer5以上?)はclient-pcのもの、
|
138
|
+
tcpヘッダまでは中継プロキシのものになる。
|
139
|
+
よって、実質的には、中継プロキシであるrpiを発信元とする通信とみなして問題を考えれば良い。
|
140
|
+
|
99
|
-
|
141
|
+
そこで、このサイトの
|
100
142
|
https://www.virment.com/iptables-outline/
|
101
143
|
「各チェインがどのパケットを対象とするかを表したイメージ図」を参考にすると、
|
102
144
|
「squid」というローカルプロセスで処理された通信を、「OUTPUT」「POSTROUTING」で操作する必要があります。
|
@@ -108,14 +150,22 @@
|
|
108
150
|
|
109
151
|
OUTPUTはローカルプロセスに処理されて出力されたパケット、すなわち送信元がホストマシンであるパケットを対象としているのに対し、POSTROUTINGは送信元がホストマシンであるとは限りません。例えば、FORWARDによって転送されたパケットも対象となります。
|
110
152
|
」
|
153
|
+
とあり、今回はrpi本体からの通信とみなして良いので、
|
111
|
-
|
154
|
+
説明文中の「ホストマシン」だけを考えており、実質的には、「OUTPUT」だけを考えれば良いです。
|
112
|
-
そして、http/https接続では、中継プロキシ-通信先サーバの間の通信は、
|
113
|
-
|
155
|
+
しかし、これでは、iptablesから見た時に、
|
156
|
+
src ipはrpi本体、src portはランダムなため、
|
114
|
-
|
157
|
+
squidからの通信かどうか判別不能です。
|
115
158
|
|
159
|
+
さらに、iptablesのsubnet-Bへの転送設定を弄ろうとしているので、
|
160
|
+
OUTPUTで変な設定をすると、
|
116
|
-
|
161
|
+
rpiへのssh accessも含め、全てsubnet Bへ転送されて、
|
162
|
+
ssh切断の危険性もあります。
|
117
163
|
|
164
|
+
となると、iptablesをやめて、squidの設定に、
|
165
|
+
client-pcからのsquid宛はsubnet-Bへ転送させる設定をする必要があります。
|
118
|
-
|
166
|
+
そのような設定があるか探しましたが、転送先を変更する方法として、「tcp_outgoing_address」というものがありましたが、
|
167
|
+
転送先nicではなく宛先ipが変更されるため、
|
168
|
+
通信先サーバへのアクセスができないです。
|
119
169
|
|
120
170
|
転送先nicとネットワークセグメントをうまく処理するツールがないため、
|
121
171
|
どうしようもありません。
|
8
タグ追加
title
CHANGED
File without changes
|
body
CHANGED
File without changes
|
7
あ
title
CHANGED
File without changes
|
body
CHANGED
@@ -17,7 +17,7 @@
|
|
17
17
|
(subnet B)
|
18
18
|
|
19
19
|
特定の操作をしたときに、sub gwを経由してwan2を利用できればよいので、
|
20
|
-
どんな方法でも良いが、client pcのip routeの変更はしたくない。
|
20
|
+
どんな方法でも良いが、client pcのip routeの変更やvpn設定はしたくない。
|
21
21
|
あくまでも、簡易な特定の操作により、wan2が利用できることが望ましいので、
|
22
22
|
大きな変更はプロキシとなるrpiに対して行うものとする。
|
23
23
|
(プログラムの通信も通すことを考えて)
|
@@ -37,7 +37,7 @@
|
|
37
37
|
|
38
38
|
「danted.conf」の設定
|
39
39
|
|
40
|
-
・入
|
40
|
+
・入口と出口のnicを別々にした
|
41
41
|
・カーネルパニック対策にローカルアドレスに対しても、client passを設定した。(https://qiita.com/hirohiro77/items/087c4d9e6b03050f70ad)
|
42
42
|
|
43
43
|
```
|
6
iptables squidではできないこと
title
CHANGED
@@ -1,1 +1,1 @@
|
|
1
|
-
squid+iptables , dante socks等
|
1
|
+
squid + iptables , dante socks等を利用したプロキシー接続による異なるnic or ネットワークセグメント間のルーティングについて
|
body
CHANGED
@@ -25,8 +25,8 @@
|
|
25
25
|
自分が考えている方法は、rpi eth0にプロキシ接続をして、ルーティングされる方法です。
|
26
26
|
やった方法は、「squid + iptables」 or 「dante socks proxy」でした。
|
27
27
|
できなかったので、経緯を詳しく書きます。
|
28
|
+
使用したツールについての動作や概念を正しく理解している自身はありません。
|
28
29
|
|
29
|
-
|
30
30
|
### 発生している問題・エラーメッセージ(その1)
|
31
31
|
danteについて
|
32
32
|
```
|
@@ -94,10 +94,11 @@
|
|
94
94
|
|
95
95
|
次に考えたことは、rpiにsquidを立て、client pcからsquidに対する通信をiptablesによりsubnet Bへルーティングする事です。
|
96
96
|
|
97
|
-
http/httpsプロキシだと、client pcがrpi (192.168.0.3:3218)を宛先とする通信しかしないので、squidで処理したあとの通信をどう扱うかが重要です。
|
97
|
+
http/httpsプロキシだと、client pcがrpi (192.168.0.3:3218)を宛先とする通信しかしない(client pcからwirsharkで確認)ので、squidで処理したあとの通信をどう扱うかが重要です。
|
98
|
+
|
98
99
|
特に、このサイトの
|
99
100
|
https://www.virment.com/iptables-outline/
|
100
|
-
「各チェインがどのパケットを対象とするかを表したイメージ図」
|
101
|
+
「各チェインがどのパケットを対象とするかを表したイメージ図」を参考にすると、
|
101
102
|
「squid」というローカルプロセスで処理された通信を、「OUTPUT」「POSTROUTING」で操作する必要があります。
|
102
103
|
そして、これらの説明には、
|
103
104
|
|
@@ -107,13 +108,20 @@
|
|
107
108
|
|
108
109
|
OUTPUTはローカルプロセスに処理されて出力されたパケット、すなわち送信元がホストマシンであるパケットを対象としているのに対し、POSTROUTINGは送信元がホストマシンであるとは限りません。例えば、FORWARDによって転送されたパケットも対象となります。
|
109
110
|
」
|
111
|
+
とあり、実質的には、「OUTPUT」だけを考えれば良いです。
|
110
|
-
|
112
|
+
そして、http/https接続では、中継プロキシ-通信先サーバの間の通信は、
|
113
|
+
tcpヘッダまでは中継プロキシのものになるので、
|
111
|
-
|
114
|
+
iptablesから見た時に、src ip,portによりsquidからの通信かどうか判別不能です。
|
112
115
|
|
116
|
+
だから、OUTPUTで変な設定をすると、rpiへのssh accessも含め、全てsubnet Bへ転送されて、ssh切断の危険性もあります。
|
117
|
+
|
113
118
|
となると、squidの設定に、squid宛はsubnet Bへ転送させる設定をすることになりますが、tcp_outgoing_addressを設定すると、転送先nicが変更されるのではなく、宛先ipが変更されており、通信先サーバへのアクセスができないです。
|
114
119
|
|
120
|
+
転送先nicとネットワークセグメントをうまく処理するツールがないため、
|
115
121
|
どうしようもありません。
|
122
|
+
自分でツール開発できるスキルはありません。
|
116
123
|
|
124
|
+
|
117
125
|
```
|
118
126
|
エラーメッセージ
|
119
127
|
```
|
5
iptables or squidの設定ではどうにもできない
title
CHANGED
File without changes
|
body
CHANGED
@@ -90,9 +90,30 @@
|
|
90
90
|
```
|
91
91
|
|
92
92
|
### 発生している問題・エラーメッセージ(その2)
|
93
|
-
squid + iptables
|
93
|
+
squid + iptablesについて、
|
94
94
|
|
95
|
+
次に考えたことは、rpiにsquidを立て、client pcからsquidに対する通信をiptablesによりsubnet Bへルーティングする事です。
|
95
96
|
|
97
|
+
http/httpsプロキシだと、client pcがrpi (192.168.0.3:3218)を宛先とする通信しかしないので、squidで処理したあとの通信をどう扱うかが重要です。
|
98
|
+
特に、このサイトの
|
99
|
+
https://www.virment.com/iptables-outline/
|
100
|
+
「各チェインがどのパケットを対象とするかを表したイメージ図」に参考にすると、
|
101
|
+
「squid」というローカルプロセスで処理された通信を、「OUTPUT」「POSTROUTING」で操作する必要があります。
|
102
|
+
そして、これらの説明には、
|
103
|
+
|
104
|
+
引用文:
|
105
|
+
「
|
106
|
+
OUTPUTとPOSTROUTINGの違い
|
107
|
+
|
108
|
+
OUTPUTはローカルプロセスに処理されて出力されたパケット、すなわち送信元がホストマシンであるパケットを対象としているのに対し、POSTROUTINGは送信元がホストマシンであるとは限りません。例えば、FORWARDによって転送されたパケットも対象となります。
|
109
|
+
」
|
110
|
+
とあり、http/https接続では、中継プロキシ-通信先サーバの間の通信は、tcpヘッダまでは中継プロキシのものになるので、squidによる通信か判別不能です。
|
111
|
+
だから、OUTPUTで変な設定をすると、rpiへのssh accessも含め、全てsubnet Bからやる必要が出る可能性もあります。
|
112
|
+
|
113
|
+
となると、squidの設定に、squid宛はsubnet Bへ転送させる設定をすることになりますが、tcp_outgoing_addressを設定すると、転送先nicが変更されるのではなく、宛先ipが変更されており、通信先サーバへのアクセスができないです。
|
114
|
+
|
115
|
+
どうしようもありません。
|
116
|
+
|
96
117
|
```
|
97
118
|
エラーメッセージ
|
98
119
|
```
|
4
あ
title
CHANGED
File without changes
|
body
CHANGED
@@ -63,18 +63,19 @@
|
|
63
63
|
```
|
64
64
|
|
65
65
|
### 試したこと
|
66
|
-
まず、firefoxのプロキシ設定からsocks_v4 or v5でeth0に設定し
|
66
|
+
まず、firefoxのプロキシ設定からsocks_v4 or v5でeth0に設定した。
|
67
|
-
eth0からeth1に
|
67
|
+
また、上記に記載したdanted.confの設定により、eth0からeth1に転送できるようにした。
|
68
68
|
すると、sub gw(192.168.1.1)の管理画面にはアクセスできる、つまり、
|
69
69
|
subnet B(eth1を経由とは書かない)を経由しているが、
|
70
70
|
1.1.1.1 (dns無しでhttp/httpsアクセス可能なアドレスで試行) には、
|
71
|
-
|
71
|
+
subnet Aを経由しています。
|
72
|
+
|
72
73
|
tcpdumpで確認すると、
|
73
74
|
subnet B宛は、tcpdump -i eth1 で確認できるが、
|
74
75
|
1.1.1.1宛は、tcpdump -i eth0で、しかも送信元が192.168.1.3(eth1)のアドレスです。
|
75
76
|
つまり、danteの設定において、
|
76
|
-
宛先がsubnet B以外だと、必ずeth0から出力されるが、送信元がexternalで設定したeth1のアドレスとなり、
|
77
|
+
宛先がsubnet B以外だと、必ずeth0から出力されるが、送信元がexternalで設定したeth1のアドレスとなり、応答パケット受信できないです。
|
77
|
-
interanlとexternalが異なる事は、送信先ネットワークセグメントの違いとはならないようなので、セグメント分けには利用できないです。
|
78
|
+
そして、interanlとexternalが異なる事は、送信先ネットワークセグメントの違いとはならないようなので、セグメント分けには利用できないです。
|
78
79
|
また、rpiにssh loginしてpingすると、subnet B宛はeth1を通るが、
|
79
80
|
それ以外はeth0を経由しており、
|
80
81
|
宛先選択には、danteの設定以前にosのルーティングテーブルが優先されているようです。(以下に貼り付けた)
|
3
danteがnic設定が宛先ネットワークセグメントを選択できない事
title
CHANGED
File without changes
|
body
CHANGED
@@ -35,7 +35,12 @@
|
|
35
35
|
|
36
36
|
### 該当のソースコード
|
37
37
|
|
38
|
-
|
38
|
+
「danted.conf」の設定
|
39
|
+
|
40
|
+
・入り口と出口のポートを別々にした
|
41
|
+
・カーネルパニック対策にローカルアドレスに対しても、client passを設定した。(https://qiita.com/hirohiro77/items/087c4d9e6b03050f70ad)
|
42
|
+
|
43
|
+
```
|
39
44
|
# $Id: sockd.conf,v 1.52.10.2 2014/09/03 14:49:13 michaels Exp $
|
40
45
|
logoutput: syslog stdout /var/log/sockd.log
|
41
46
|
debug: 1
|
@@ -61,11 +66,19 @@
|
|
61
66
|
まず、firefoxのプロキシ設定からsocks_v4 or v5でeth0に設定し、
|
62
67
|
eth0からeth1に流れるように、danted.confを設定した。
|
63
68
|
すると、sub gw(192.168.1.1)の管理画面にはアクセスできる、つまり、
|
64
|
-
eth1を経由しているが、
|
69
|
+
subnet B(eth1を経由とは書かない)を経由しているが、
|
65
70
|
1.1.1.1 (dns無しでhttp/httpsアクセス可能なアドレスで試行) には、
|
71
|
+
eth0を経由しています。
|
72
|
+
tcpdumpで確認すると、
|
66
|
-
|
73
|
+
subnet B宛は、tcpdump -i eth1 で確認できるが、
|
74
|
+
1.1.1.1宛は、tcpdump -i eth0で、しかも送信元が192.168.1.3(eth1)のアドレスです。
|
75
|
+
つまり、danteの設定において、
|
76
|
+
宛先がsubnet B以外だと、必ずeth0から出力されるが、送信元がexternalで設定したeth1のアドレスとなり、
|
77
|
+
interanlとexternalが異なる事は、送信先ネットワークセグメントの違いとはならないようなので、セグメント分けには利用できないです。
|
67
78
|
また、rpiにssh loginしてpingすると、subnet B宛はeth1を通るが、
|
79
|
+
それ以外はeth0を経由しており、
|
68
|
-
|
80
|
+
宛先選択には、danteの設定以前にosのルーティングテーブルが優先されているようです。(以下に貼り付けた)
|
81
|
+
danteなら異なるnic間の転送ができると期待しましたが。
|
69
82
|
|
70
83
|
```
|
71
84
|
root@raspberrypi:/etc# ip route
|
2
修正
title
CHANGED
File without changes
|
body
CHANGED
@@ -18,7 +18,8 @@
|
|
18
18
|
|
19
19
|
特定の操作をしたときに、sub gwを経由してwan2を利用できればよいので、
|
20
20
|
どんな方法でも良いが、client pcのip routeの変更はしたくない。
|
21
|
-
あくまでも、簡易な特定の操作により、wan2が利用できることが望ましい
|
21
|
+
あくまでも、簡易な特定の操作により、wan2が利用できることが望ましいので、
|
22
|
+
大きな変更はプロキシとなるrpiに対して行うものとする。
|
22
23
|
(プログラムの通信も通すことを考えて)
|
23
24
|
|
24
25
|
自分が考えている方法は、rpi eth0にプロキシ接続をして、ルーティングされる方法です。
|
1
追加
title
CHANGED
@@ -1,1 +1,1 @@
|
|
1
|
-
プロキシー接続による異なるnic or ネットワークセグメント間のルーティング
|
1
|
+
squid+iptables , dante socks等によるプロキシー接続による異なるnic or ネットワークセグメント間のルーティング
|
body
CHANGED
@@ -1,4 +1,6 @@
|
|
1
1
|
### 前提・実現したいこと
|
2
|
+
(書いている途中ですが、何個か試したので、随時追加で投稿します。)
|
3
|
+
|
2
4
|
2つの回線があり、メインの回線とは別に、特定の操作をした時にサブ回線を通るようにしたい。
|
3
5
|
今、以下のようなネットワーク構成であるとする。(左側のaはスペースを反映させるための装飾で、特に意味はない)
|
4
6
|
|
@@ -14,13 +16,17 @@
|
|
14
16
|
a sub gw(192.168.0.1)--wan2
|
15
17
|
(subnet B)
|
16
18
|
|
17
|
-
特定の操作をしたときに、sub gwを経由してwan2を利用
|
19
|
+
特定の操作をしたときに、sub gwを経由してwan2を利用できればよいので、
|
20
|
+
どんな方法でも良いが、client pcのip routeの変更はしたくない。
|
21
|
+
あくまでも、簡易な特定の操作により、wan2が利用できることが望ましい。
|
22
|
+
(プログラムの通信も通すことを考えて)
|
23
|
+
|
18
24
|
自分が考えている方法は、rpi eth0にプロキシ接続をして、ルーティングされる方法です。
|
19
25
|
やった方法は、「squid + iptables」 or 「dante socks proxy」でした。
|
20
26
|
できなかったので、経緯を詳しく書きます。
|
21
27
|
|
22
28
|
|
23
|
-
### 発生している問題・エラーメッセージ
|
29
|
+
### 発生している問題・エラーメッセージ(その1)
|
24
30
|
danteについて
|
25
31
|
```
|
26
32
|
エラーメッセージ
|
@@ -56,7 +62,7 @@
|
|
56
62
|
すると、sub gw(192.168.1.1)の管理画面にはアクセスできる、つまり、
|
57
63
|
eth1を経由しているが、
|
58
64
|
1.1.1.1 (dns無しでhttp/httpsアクセス可能なアドレスで試行) には、
|
59
|
-
eth0を経由しています。これらはtcpdumpでも確認済みです。
|
65
|
+
eth0を経由しています。これらはrpi上でのtcpdumpでも確認済みです。
|
60
66
|
また、rpiにssh loginしてpingすると、subnet B宛はeth1を通るが、
|
61
67
|
それ以外はeth0を経由しており、danteの設定以前にosのルーティングテーブルが優先されているようです。danteなら異なるnic間の転送ができると期待しましたが。
|
62
68
|
|
@@ -68,5 +74,17 @@
|
|
68
74
|
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.3 metric 203
|
69
75
|
```
|
70
76
|
|
77
|
+
### 発生している問題・エラーメッセージ(その2)
|
78
|
+
squid + iptables
|
79
|
+
|
80
|
+
|
81
|
+
```
|
82
|
+
エラーメッセージ
|
83
|
+
```
|
84
|
+
|
85
|
+
### 該当のソースコード
|
86
|
+
|
87
|
+
|
88
|
+
### 試したこと
|
71
89
|
### 補足情報(FW/ツールのバージョンなど)
|
72
90
|
dante 1.52.10.2
|