ipv6hackのブログ一覧

最近、ゼロトラストのソリューションとしてZscalerがよくつかわれるが、
アクセスに利用されるIPアドレスは回線のIPアドレスではなくクラウド上の
ZscalerのPROXY経由のIPアドレスになるためルータのフィルターには
注意が必要である
利用者が増えたのかIPアドレスの範囲が大幅に増えていた

Zscalerで2026/2/12で利用されるIPアドレスの範囲は下記である
58.220.95.0/24
64.215.22.0/24
87.58.64.0/18
94.188.131.0/25
94.188.139.64/26
94.188.248.64/26
98.98.26.0/24
98.98.27.0/24
98.98.28.0/24
101.2.192.0/18
104.129.192.0/20
112.137.170.0/24
124.248.141.0/24
128.177.125.0/24
136.226.0.0/16
137.83.128.0/18
140.210.152.0/23
147.161.128.0/17
154.113.23.0/24
165.225.0.0/17
165.225.192.0/18
167.103.0.0/16
170.85.0.0/16
185.46.212.0/22
194.9.96.0/20
194.9.112.0/22
194.9.116.0/24
196.23.154.64/27
196.23.154.96/27
197.98.201.0/24
197.156.241.224/27
198.14.64.0/18
199.168.148.0/23
209.55.128.0/18
209.55.192.0/19
211.144.19.0/24
220.243.154.0/23
221.122.91.0/24
2605:4300::/32
2a03:eec0::/32
2400:7aa0::/32
205.220.0.0/17
167.106.0.0/16
103.215.126.0/24
159.254.0.0/16
98.98.186.0/24
98.98.187.0/24
98.98.169.0/24
175.107.128.0/18
137.31.0.0/16

ご参考に・・・・

現在HGWの単体故障含めて切り分け中のメモです

【原因】
不具合か実装上の制限なのか単体故障かはわからないが
HGWのLAN側のLANポート間では、マルチキャストのレートリミットが
存在するような動きをしているのが原因

【経緯】
NTＴの１０Ｇ　クロス回線のＨＧＷ　XG-100NEのLAN側に
ルータを2台設置し、VRRPを組むとなぜかVRRPのパケットがバックアップ側が
受信できない事象が発生

　　　|
　　　|
　　HGW
　　|　　|
　　R1　R2

というHGW直結構成の場合でR1はRTX1300
R2はRTX1200ですが、なぜかVRRPが最初はいいが、マスターのR1をリブート等して
バックアップ側R2に切り替わった後にR1が復帰後、切戻るはずなのに
R2側のVRRP状態がMASTERのままである
パケットキャプチャーでHGWのLAN側ポートのマルチキャストの状態をみると
R1側が再起動完了してもR1側のVRRPパケットが流れてこない

さらに
　　　|
　　　|
　　HGW
　　|　|
　　|　R2
　SW
　　|
　　R1

としてSWとHGWのLANポートにそれぞれキャプチャーを設置して
マルチキャストの状態を確認
するとR1リブートするとR1のVRRPパケットが停止し
R2のVRRPパケットが送信される
その後、R1が再起動完了するとSWの部分のキャプチャーには
R1のVRRPが流れてきているのがキャプチャーできていたが、
（この時、R2のVRRPパケットも来ていた）
なぜかHGWのキャプチャーにはR2のVRRPしか着ていない
そのためR2にR1のVRRPパケットが到達していないから
切戻らないという動きになっていることが判明
ここでR2のVRRPの送出を止めるとHGWにキャプチャーにR1のVRRPがでてくる動きが見えた
いろいろ試すと一定のレート以上のマルチキャストの入力がHGWのLAN側にあると別ポートへ転送しない（もしくは入力時に破棄している）ようである

YAMAHAのVRRPのインターバルタイマーはデフォルト１秒であるが、一定以上間隔を開けるとVRRPが正常動作するようになった
ただし、例えばR1が再起動して復帰してVRRPパケット送出のタイミングとR2のインターバルとタイミングが合ってしまうと永久に２パケットが短い間隔でバースト入力されてとなり、これもVRRP切戻らない状況になってしまった
ただ、R1、R2ともに同じインターバル感覚に設定しないといけないが、内部時計の精度のためか微妙に一定間隔といってもずれてくることも分かった
そのため、試行錯誤した結果
インターバル　50秒　　ダウンインターバル　60秒
だと切り替え試験を１０回やって１０回切戻った
ちなみに例えば
インターバル　15秒　　ダウンインターバル　20秒
とした場合、
１０回中２回成功、８回は５分以上切戻らなかった

余談ではあるが
　　　|
　　　|
　　HGW
　　|
　　|
　SW
　|　|
R1　R2
この構成であればHGWの変なレートリミットの影響が受けないので
インターバル　1秒　　ダウンインターバル　3秒
でも１００％動作する
が、SWの電気代がもったいないので正直避けたい

【注意喚起】過去に国際電話不取扱センターに申し込んでいても国際電話が着信される

自宅のひかり電話に過去に国際電話不取扱センターに申し込んでいても国際電話が着信される
こと事象が発生！結構ややこしいので注意喚起として記載しました
（コラボ事業者、NTTにはコラボ事業者経由、国際電話不取扱センターには不具合改善を要望済み）
過去に国際電話不取扱センターに申し込んでいる方でも、コラボ回線等を利用の方はご注意ください

【対象者】
・過去に国際電話不取扱センターに国際電話取次停止の申込をしている
・国際電話不取扱センターに申し込み後にコラボ事業者や他社回線に番号ポータビリティで契約を変えている
・PSTN回線からNTTのひかり電話への変更はどうなるかは未確認

【結論】
一度、国際電話不取扱センターに申し込んでいても、コラボ事業者変更や他社回線等に契約を変えた場合、
国際電話不取扱の設定がリセットされるので、再申し込みが必要
ただし、ステータス管理が雑なのか漏れがあり一見して申込済みのような状態が発生（実際は着信される）

【経緯】
1.私自身はTeamsやAmazonの二段階認証で、スマホが故障時にも対応できるようにと予備番号として登録していたので、
国際電話の着信が逆に必要なのですが、同居している祖父祖母用の追加電話番号は着信されないようにしたいと思って国際電話不取扱センターにTEL

2.国際電話不取扱センターの自動音声でひかり電話等は契約事業者へTELしてくださいとあり

3.契約しているコラボ事業者にTELすると既に契約している２番号とも国際電話不取扱が「締結済」であるというステータスだと返答あり

4.そういえば、今の番号を新規に引いたときに、怪しいことはとめるように国際電話不取扱申請したような記憶が・・・・
　今とは事情が異なりますが、1990年代のダイアルアップ時代、勝手にダイアルアップの設定を書き換えられて国際電話のISPにダイアルアップするような
　ウイルスとかもあったので、それのを警戒してADSL時代PSTN回線で申し込んだ経験があったので、
　今の番号を初めて引いたフレッツ光プレミアムのひかり電話の時にも同じようにように申し込んだ遠い記憶が・・・

5.しかし、ここで気が付く！だとしてもAmazonやTeamsでの２段階認証の国際電話着信はちゃんと着信履歴にある

6.コレボ事業者に質問しても「締結済」でも国際電話の着信があるようでしたら、国際電話不取扱センターに相談してくれと案内有

7.国際電話不取扱センターに相談するが一次受付のオペレータでは埒が明かなかったためか、別のものに対応が変わる（上司？）

8.確認できた事実として
　・過去５年以内に申し込みがされた形跡はない（申込データは５年しか保持しないとのこと）
　・現在は、国際電話受付可能状態になっている
　とのこと
　コラボ事業者の「締結」というのが何をもっての情報かはセンター側では不明
　現在のコラボ回線はフレッツ光クロスが提供可能エリアになってからのため、少なくとも５年以内であることは確実
　なのに申込データに履歴がないが、コラボ事業者には「締結」という申込済みという情報がある
　その矛盾を質問したところ、こういった回答があった
　「コラボ等契約事業者を変えた場合、国際電話不取扱の申込はリセットされて元に戻る。そのため、
　　契約事業者を変更時は再度、国際電話不取扱の申込が必要」・・・・と

9.再度、コラボ事業者に確認すると国際電話不取扱の「締結済」ステータスはNTTのコラボ事業者用の情報システムから引っ張ってきており
　そのコラボ事業者がローカルでかんりしているものでないと

　つまり、契約事業者を変えると国際電話不取扱のステータスはリセットされるのにNTTの管理DBのようなものに反映はされずに
　申込済みの「締結済」のステータスが残り、実体と乖離が発生するようです

以上のことが、今回経験したことです（本当、疲れました）

自分の契約している事業者に確認して「締結済」等いわれても、実際のステータスが違う場合があります
心配の方は、改めて国際電話不取扱センターに申し込むようにしてください
なお、国際電話の着信の可否を動作確認したい場合は、例えばAMAZONの２段階認証の電話番号を固定電話にして、
音声での番号通知にすれば、国際電話の着信になってかかってきます
Teamsでも同様です


これからコラボや他社回線に契約事業者を変更する方は、ご注意ください



　

https://minkara.carview.co.jp/userid/354569/blog/48292200/
ここで投稿したCloudflareのゼロトラストがXPASSだと不安定
ですが解決しました！

結論としてはやはり当初怪しいと思っていたMTUでした
NTTのフレッツADSL初期の時代のMTUの情報があまり広まってなくて
適切にしてなかったときのIPSEC　VPNの挙動とそっくりだったので
怪しいとは思っていたが・・・・

犯人：RTX1300

原因：YAMAHAのXPASSのHP
http://www.rtpro.yamaha.co.jp/RT/docs/xpass/index.html
ではIP TUNNELのMTUの設定はされていません
これはデフォルト値である1280でということらしいです（YAMAHAにTELして聞きました）
https://www.rtpro.yamaha.co.jp/RT/manual/rt-common/ip/ip_interface_mtu.html
これまで1280でも問題なかったのですが、今回VPNで引っ掛かりました
VPNソフト側のMTUを下げたのですが、うまくいってなかったようです
XPASSのMTUを調べたら1460と分かったので
https://www.biwako.ne.jp/support/xpass/rtx1200/
RTX1300にそれを設定したら問題が解決
安定動作となりました

メーカーのサンプルコンフィグが動作不良の原因とは・・・・・
やられました・・・

あ・・・ありのまま
今起こった事を話すぜ！

『CloudflareのVPNクライアントWARPで接続をするが
XPASS経由IPv4の場合だと不安定になるんだ！
ネイティブのIPv6のみとかスマホのテザリング経由のIPv4のみなら
大丈夫なんだよ！』

な・・・なにを
言っているのかわからねーと思うが

おれも何をされたのか
わからなかった・・・
頭がどうにかなりそうだった・・・


ということで、原因がわかりません・・・
MTUかと思って、XPASSのMTUが1280なので手動でCloudflareのMTUを
標準の1280から220下げて1060や1000にしたのに事象変わらず
VPNパススルーがないからかと思って、固定IPの契約のXPASSでやっても安定性かわらず不安定・・・・・・・・・・

マジで原因がわからん・・・・