この問題は数日間私を狂わせた。私は従業員の家に配布するミニルーター/ VPNクライアントデバイスのプロトタイプを作業しています。現在、私は家族の事情により実際に他の州で遠隔で働いていますが、今がそうするのに良い時期だと思いました。
ルーターにはエンドユーザーへの接続が1つ以上あります（この場合私のもの）インターネットは4G / 5Gセルラー接続を介して有線で接続されバックアップされます。
質問：3つのWANインターフェイスがあります（下記参照）。そのうちの2つは完璧に動作します。 Xfinityルータ接続が時々許可されないどの私のデバイスからのトラフィックです。常にXfinityルータ自体にpingを送信できます。インターフェイス（例ifdown ethwan0 && ifup ethwan1：）を再起動すると動作することがありますが、そうでない場合もあります。操作が開始されると（たとえば、パブリックインターネットへのトラフィックの送信など）、無期限にうまく機能します。
2つの異なるWAN接続間で前後に失敗することがあります（以下のカスタムスクリプトを使用）。 Xfinity 接続にフェイルオーバーすると、ほとんどの場合トラフィックは発生しません。 （私のルータを介したSNATではなく、私のルータから直接接続することもありません。）
Xfinityルータの管理インターフェイスの[オフラインデバイス]の下に、私のルータのIP / MACが一覧表示されます。この時点で、実際にルータインターフェイスでXfinityのIPをpingできます。この文脈では、「オフライン」が何を意味するのか分かりません。
編集する： 100％確信できませんが、問題がXfinityデバイスにある場合：
Technicolor TC8305C
Boot Version: 2.1.8_Technicolor
Core Version: 01.E6.01.22.59
HW Version: 1.5
私は4つのethポートと1つのWi-Fiカードを備えた白いラベルファンレスミニコンピュータを持っています。 CentOS 7を実行しており、[このレッスンを省略してください:)]ポートは次のとおりです（udev / rules.dで名前が変更されます）。
ethwan0- Xfinityケーブルモデム/ルーター（Xfinityデバイスはいいえブリッジモード - NAT'd)
ethwan1- T-Mobileゲートウェイデバイス（NATもあります）
ethint - VPNの反対側のシステムにアクセスするためにユーザーのネットワークに内部接続
ethgst - ユーザーの家族や他の人のゲスト接続。インターネットにのみアクセスできます。
ethwifi- Verizon Hotspot（過度ですがテスト中です）。
NetworkManagerとファイアウォールがあります。障害のある私はiptables-servicesiptablesスクリプトを使用する他の集中型ルータがたくさんあるので、一貫性のために使用しています。 selinux障害がある。
ifcfg-ethwan0:
TYPE=Ethernet
BOOTPROTO=static
DEFROUTE=no
NAME=ethwan1
DEVICE=ethwan1
ONBOOT=yes
IPADDR=192.168.242.12
PREFIX=24
ifcfg-ethwan1:
TYPE=Ethernet
BOOTPROTO=static
DEFROUTE=no
NAME=ethwan0
DEVICE=ethwan0
ONBOOT=yes
IPADDR=192.168.38.1
PREFIX=24
ifcfg-ethwifi:
MODE=Managed
KEY_MGMT=WPA-PSK
TYPE=Wireless
BOOTPROTO=static
DEFROUTE=no
NAME=ethwifi
DEVICE=ethwifi
ONBOOT=yes
IPADDR=192.168.97.245
PREFIX=24
メモ:この接続はうまく機能し、問題にならないので、wpa_supplicant構成などを省略しました。
iptables構成:
*nat
-A POSTROUTING -m state --state RELATED,ESTABLISHED -j ACCEPT
-A POSTROUTING -s 10.38.168.0/24 -d 192.168.0.0/16 -j ACCEPT
-A POSTROUTING -s 10.38.168.0/24 -d 10.0.0.0/8 -j ACCEPT
-A POSTROUTING -s 10.38.168.0/24 -m state --state NEW -j SNAT --to-source 192.168.242.12
COMMIT
*filter
:OUTPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -p icmp -j ACCEPT
-A FORWARD -s 10.38.100.0/22 -d 10.38.168.0/24 -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -m state --state NEW -s 10.38.168.0/24 -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
:INPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -s 10.38.168.0/24 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT
failover-conn.bsh [interface]:
#!/bin/bash
# Arg $1 is the interface name to fail over to (e.g. ethwan0)
declare -A snat_src
declare -A gateway
declare -A cidr
snat_src[ethwan0]="192.168.242.12"
gateway[ethwan0]="192.168.242.1"
snat_src[ethwan1]="192.168.38.1"
gateway[ethwan1]="192.168.38.11"
snat_src[ethwifi]="192.168.97.245"
gateway[ethwifi]="192.168.97.1"
# Should use awk here but this does work.
snat_line_num=`iptables -t nat -nL --line-numbers |grep SNAT |grep "10\.38\.168\.0\/24" |grep -oP "^[0-9]+"`
# This looks foolish but it's in case a malfunction caused more than one rule to be put in place.. it's happened to me before and this overkill can't hurt.
for whatever in 1 2 3; do
ip route del default
iptables -t nat -D POSTROUTING -s 10.38.168.0/24 -m state --state NEW -j SNAT --to-source ${snat_src[ethwan0]}
iptables -t nat -D POSTROUTING -s 10.38.168.0/24 -m state --state NEW -j SNAT --to-source ${snat_src[ethwan1]}
iptables -t nat -D POSTROUTING -s 10.38.168.0/24 -m state --state NEW -j SNAT --to-source ${snat_src[ethwifi]}
done
ip route add default via ${gateway[$1]} dev $1
iptables -t nat -I POSTROUTING ${snat_line_num} -s 10.38.168.0/24 -m state --state NEW -j SNAT --to-source ${snat_src[$1]}
conntrack -D
# I thought flushing the ARP cache might cause a re-announce to the Xfinity modem and make it play nice. I tested with/without this and same result.
ip -s -s neigh flush all
# Without the sleep the VPNs timeout a couple of times before connecting anyway.
sleep 10
systemctl restart openvpn@client-REDACTED0
systemctl restart openvpn@client-REDACTED1
以下は、問題を説明する一連のコマンド/結果です。
./failover-conn.bsh ethwan0
# ping from router or SNAT'd connection to 8.8.8.8 may return one pong then unlimited timeouts, no responses at all, or it will be fully functional. VPNs may or may not connect after some time; EVEN IF PINGS ARE FAILING CONSTANTLY..???
ifdown ethwan0 && ifup ethwan0
# pings may or may not get responses or timeout depending on the phase of the moon...?
./failover-conn.bsh ethwan1
# Everything works flawlessly. Can ping from router, from SNAT'd clients, and VPNs connect. All traffic transits correctly.
./failover-conn.bsh ethwifi
# Everything works flawlessly. Can ping from router, from SNAT'd clients, and VPNs connect. All traffic transits correctly.
./failover-conn.bsh ethwan0
# Same as the first time. May or may not work.
Xfinityルーターで試したことは次のとおりです。
- ファイアウォール/ IDSを完全にオフにします（おそらく、IDSはデュアルNATのために迷惑をかけると思いました）。
- 私のルーターを「予約済みデバイス」として追加
- すべてのブロック/子供の保護がオフになっていることを確認しました。
- 別のノートブックをXfinityデバイスのWi-Fiに直接接続し、pingを開いたままにしてルータをテストしている間に、実際のデバイス/インターネット接続が機能していることを確認してください。すでに起きています。
- 私のルーターのIPをDMZホストに設定します（可能性は低いが??????利益）
- バックアップノートブックをXfinityゲートウェイに接続してテスト/pingします。ルータがダウンすると、そのノートブックは常に正常に動作します。
- Xfinityルーターの再起動/再起動する接続の復元。 （ルーターを再起動してもそうではありません。）
私のルーターで次のことを試しました。
- VPNを無効にする
- iptableを無効にする
- 他のすべてのインターフェイスを無効にします。
- 「通常の」コンピュータと同じように変更してください
ifcfg-ethwan0。DEFROUTE=yesGATEWAY=192.168.242.1 ethwan0物理的および構成交換ethwan1。 Xfinityデバイスは接続されているポートに関係なく信頼できませんでしたが、T-Mobileゲートウェイは正常に動作しました。- あちこちイーサネットケーブルを交換してください。
私はこれについて混乱しています。この奇妙なXfinityデバイスに接続されている他のすべてのデバイスは正常に動作します。このミニコンピュータに何か問題があります。しかし、私が言ったように、ミニコンピュータはT-Moルーターでも動作しますethint。
トラブルシューティングの段階を経て、誰かが同様の問題を抱えて解決策を見つけてください。
それとも、私の構成やアプローチで明らかな顔の手のひらのバグを発見しますか？そうだったらいいな。それでは、少なくともGiTMではないことがわかります。
よろしくお願いします！ -スコット