事象

TLS Handshake で失敗する場合、しない場合があり、Webページが表示されない。
携帯が２台あり、どちらもSIMの回線を使用し、Webページにアクセスすると、片方は成功、片方は失敗
成功している場合は１回の応答でServer Hello, Change Cipher Spec, Encrypted Handshake Messgeをまとめて送信しています。対するACKも１回のみです。
完全に見れないのであればFirewall設定を疑いましたが、片方は見れている状態です。
tcpdump(& wireshark) で見た限り、以下に挙げる状態のときはTCP retransmission が発生して結果的にブラウザではタイムアウトとなるようです。(wireshark から抜粋)
TCP Out-Of-Order 時にWireshark では (reassembly error, protocol TCP: New fragment overlaps old data) が出ています。

|No.|Src|Dest|Proto|Info|
|:--|:--:|--:|
|1|Internet|HAProxy|TCP|xxx -> 443 SYN|
|2|HAProxy|Internet|TCP|443 -> xxx SYN,ACK|
|3|Internet|HAProxy|TCP|ACK|
|4|HAProxy|HOST[123]|TCP|yyy -> 30397 SYN|
|5|HOST[123]|HAProxy|TCP|30397 -> yyy SYN,ACK|
|6|HAProxy|HOST[123]|TCP|yyy -> 30397 ACK|
|7|Internet|HAProxy|TLS1.2|Client Hello|
|8|HAProxy|Internet|TCP|443 -> xxx ACK|
|9|HAProxy|HOST[123]|TLS1.2|Client Hello|
|10|HOST[123]|HAProxy|TCP|30397 -> yyy ACK|
|11|HOST[123]|HAProxy|TLS1.2|Server Hello|
|12|HOST[123]|HAProxy|TLS1.2|Certificate(TCP segment of a reassembled PDU)|
|13|HOST[123]|HAProxy|TLS1.2|Server Key Exchange, Server Hello Done|
|14|HAProxy|HOST[123]|TCP|yyy -> 30397 ACK|
|15|HAProxy|HOST[123]|TCP|yyy -> 30397 ACK|
|16|HAProxy|HOST[123]|TCP|yyy -> 30397 ACK|
|17|HAProxy|Internet|TLS1.2|Server Hello|
|18|HAProxy|Internet|TLS1.2|Certificate(TCP segment of a reassembled PDU)|
|19|HAProxy|Internet|TLS1.2|Server Key Exchange, Server Hello Done|
|20|HAProxy|Internet|TCP|[TCP Out-Of-Order] 443 -> xxx ACK|
|21|HAProxy|Internet|TCP|[TCP Out-Of-Order] 443 -> xxx ACK|
|22|HAProxy|Internet|TCP|[TCP Retransmission] 443 -> xxx ACK|

... 以下Retransmissionが続く

質問

原因となっている場所はどこでしょうか
何を他に試せばよいでしょうか
何を直せば良いでしょうか

前提

現在、自宅にてサーバをたてて検証環境を作っています。

Kubernetes

Host 1-3 で動作
Port 30397（仮）でHTTPSリクエストを受けています。
Port 30402（仮）でHTTPリクエストを受けています。
NGINX ingress Controller & cert-manager でワイルドカード証明書を発行しています (www, *)
L7 バランシング

Haproxy

TCP Mode
80, 443 Listen
80 -> 30402(仮） Forward
443 -> 30397(仮） Forward
Docker-composeでRaspberry-pi上で動作
HOST 1-3にL4 バランシング

Router

ルーターに仮想サーバ機能があるので80, 443 Open
80 -> HAProxy(80) Forward
443 -> HAProxy(443) Forward

構成

      (Internet)
          ↕
       [Router]
          ↕
    [Raspberry Pi] 
    ↕     ↕     ↕
[Host1] [Host2] [Host3]

MW

Raspberry Pi: HAProxy(TCP Mode)
Host[1-3]: Kubernetes Worker(Master がいますがHaproxyから飛ばしていないので略します）

補足

L３レベルの話やNetworkに疎く、TCPやTLSの仕組みに詳しくないので素人構成ですが、なにかヒントをいただけると幸いです。

Umeeeh

2019/11/26 13:46

２台あるうち片方ならクライアント側の問題のような気もしますが、２台の携帯の違いはなんでしょうか？

kkdm

2019/11/26 13:54

早速ありがとうございます。どちらもAndroidです。違いといえばバージョンでしょうか。成功したほう： - Android 8.1.0 - 78.0.3904.62 失敗したほう： - Android 9 - Chrome 72.0.3626.121

行動規範の内容に同意します

回答2件

解決方法

WAN-LAN ルータのmtu サイズ修正
1492 -> 1452

キーワード

DF bit
Don't Fragment
Total Length
mtu

参考サイト

投稿2019/11/27 12:47

kkdm

総合スコア18

ベストアンサー

こういう時はtcpdumpで状況を切り分けるのは結構大変なので、最小限の構成から順に動作確認を怒って行って問題発生源を切り分けるのが結局早いことが多いです。

1台のhostで携帯1,2からアクセス(hostの数だけ繰り返す)
1台のhost+HAproxyで携帯1,2からアクセス(hostの数だけ繰り返す)
1+2のhost+HAProxyで携帯1,2からアクセス
1+3のhost+HAProxyで携帯1,2からアクセス
2+3のhost+HAProxyで携帯1,2からアクセス

くらいでパターンが網羅できるので、単純にhost上のwebサーバのアクセスログ、エラーログ、HAProxyのアクセスログ、エラーログを見ながら確認をしてみるのが良いと思います。

以下、勘による回答

勘ですが、
HAProxy経由&HTTPSのターミネートはhost側で実施（と解釈しました。違っていたらご指摘下さい）
ということなのでhostか、host-HAProxy間の問題である可能性が高いと思います。

HAProxyがStickyCookieでそれぞれのクライアント毎に毎回同じホストにバランシングしている→ダメなホストにアクセスするクライアントが常に失敗するというケースを予想。

私が検証するとしたら、

PCのブラウザでCookieをクリアしながら何度もアクセスして、状況が再現できないか確認する
host側でアクセスログとパケットを監視して、携帯1,携帯2でそれぞれアクセスした際に同じhostにアクセスしていることを確認
1か2が正の場合、ダメなhostのnginxの設定を見直す&HAProxyのバランシングでダメなホストにバランシングしている設定を見直す

と言う感じでまずは確認かなあ。。。

投稿2019/11/26 15:12

tanat

総合スコア18727

kkdm

2019/11/27 12:43

詳細な調査方法やパターン列挙まで提供してくださり、大変助かります。ありがとうございます！！別の方法で自己解決いたしましたのでご報告です。たまたまwireshark のIPパケット（L３）を眺めていたところ、失敗したパケット（再送パケット）は Total Length 1492 と表示されていました。また、DontFragmentとも記載されていました。こちらPPPoE接続のmtu 最大値をルーター側で設定していて、その値と同じだったので、なんとなく気になってググってみたところ、こちらのサイトがトップに出ました。 https://www.sonicwall.com/support/knowledge-base/how-can-i-optimize-pppoe-connections/170505851231244/ 値を１４５２へ修正してみたところ、無事解決しました。 mtuについて深く調べたわけではないのですが、パケットサイズ超過によるパケロスが発生していたようです。成功ていた場合のアクセスは、１４９２を超えるパケットがLAN側で発生していなかったため、ルータを通る際にもドロップされず、mtuのサイズ超過と気づけなかったのかなと思います。ご協力ありがとうございました。