ゴールデンウィーク休暇に一所懸命ぐうたらしたはずなのに、ものすごく疲れてたのか、めっちゃ寝てたのが業務開始日の今朝ってのは面白い、しょっさんです。

運動しすぎたのか、座りづかれたのか、まぁいい。このゴールデンウィークも地道に、DS-lite の制限に立ち向かってました。

tunneling サーバを別立てすることで、ポート数制限の上限を相当数クリアすることができます。しかし、なんか納得いきません。プロバイダに金払ってるのに、そこの制限によって別のなにかで料金や工数がかかるのは、いささか不愉快です。

ということで、Edgerouter の conntrack timeout をチューニングしたら、制限とうまく向き合えるのでは？と考えました。

こまけぇことは別におまかせしますが、NAT変換テーブルを保持する時間を transix の保持時間と同じにすれば、余計なポートが新たに生み出されることが少なくなるのではないかという判断です。

NAT変換テーブルは、「tcp」「udp」「icmp」でそれぞれに timeout の時間が細かく定義されています。この timeout の値が上位の transix と、下位となる我が家のローカルルータとで時間がずれていると、絶妙なハーモニーで transix でのポート数が増える可能性が高い可能性があります。

transix の timeout > ローカルのtimeout 

ローカル側の timeout が短い場合には、すでにtransix のNATで利用されているテーブルの再利用性が低くなります。そのため transix 側の NATテーブルが芋づる的に増えていく可能性が高い。

transix の timeout < ローカルのtimeout

ローカル側の timeout が長い場合には、上位である transix の NAT変換テーブル内にはないはずの通信が再利用される可能性があります。TCP の場合はセッションを維持したまま再利用することになります。したがって、ローカルにまだセッションが残っているのに、上位のtransixからはぶっちぎられた状態です。この場合、上位からは「そんなセッション知らない」とReject でも返ってくれば分かりやすいですが、今回実験している感じでは Drop です。keep-alive の信号をこっちから積極的に打ち込んでいかない限りは、セッションがなくなったかどうかを判断できず、クライアント側はだんまりする傾向にあります。keep-alive で timeout や ttl を設定していれば、気がつくのが早い感じです。

しかしですね、おそらく初期状況だとこの傾向だと思われ、自分の環境もその様になっていました。しかし、この場合に ICMP host unreachable されるような状況が生み出される可能性は低い気がしてます。これが現時点で、まだ納得行っていない点です。ただ、乖離が大きいことで、影響が大きいだろうことは想像ができました。とは言え、ローカルのNAT変換テーブルが増えても、transix 側の変換テーブルが増えるだろうか、についてはまだ実験中です。transix 側がどういったメカニズムで NAT変換テーブルを保持しているか、それが分かっていないので困ってます。このへんは、transix の AFTR が何ものかをもう少し調べてから、次の実験へ進みたいと考えています。

ということで、この NAT変換テーブルの保持時間をさまざまな方法で検証してみました。tcp は時間が長いので、検証回数があまり取れず正確な値は取れていませんが、だいたいこのへんってのは突き止めました。

結果

tcp established timeout ... 305秒 (およそ)
udp timeout ... 4秒
icmp timeout ... 2秒

tcp の established セッションを維持可能なのは 300秒であればほぼほぼ確実。304〜305あたりだと切れたり維持されたままだったりなので、おおよそこのへんではないかというあたりです。ネットワークの通信状況やパケットの再送具合などにより、ある程度の誤差は生まれるはずなので、305秒程度と判断しました。

現在、二日前にこの設定に定義を変更し、壮大な実験中です。もう少し、transix の AFTR の動作が分かってきたら、また追記します。