ipv6hackのブログ一覧

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

自宅のひかり電話に過去に国際電話不取扱センターに申し込んでいても国際電話が着信される
こと事象が発生！結構ややこしいので注意喚起として記載しました
（コラボ事業者、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でやっても安定性かわらず不安定・・・・・・・・・・

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

自宅の有線LANを収容しているスイッチングハブを変えたらPanasonicのお部屋ジャンプリンクで「サーバーが見つかりません」になりました

結果としては、IGMPスヌーピングを無効化したら解決しました
交換前のスイッチのコンフィグを見ても、どうやら意図的に無効化していて昔にも同じことになったようでしたが、完全に忘却の彼方に行っていて、同じトラブルで同じように悩んでました

情報元
https://av.jpn.support.panasonic.com/support/hdd/connect/ap/e10_ap.html

※2 お部屋ジャンプリンク利用にあたっては、「IGMPスヌーピング」機能を「無効」に設定してください。

上記のURLの機器ではないが、IGMPスヌーピングが有効だとどうやらうまく動作しないと上記のURLから推測した結果です

AMAZONは便利だが、AMAZON業者の配送は本当にこまる
遅配や誤配がこの１週間で５回あり、怒髪天状態でした

ここ最近、見ていてあることに気が付きました
時間帯指定による配達を指定する場合、
AMAZON業者は再配達に14：00-16：00という時間帯枠が
指定対象にないということです
ひょっとして最初から配達を時間帯指定で14：00-16：00にすれば
AMAZON業者にならないのでは！？と思い試してみましたら１０回やって１０回ともヤマト運輸が配送してきました

ということで、今のところ試した限りでは
時間帯指定配送で14：00-16：00にすればAMAZON業者以外になる可能性が非常に高いようです
ただ、枠が少ないようで翌日の14:00-16:00枠とかはそもそも選択しに表示されない場合が多いため、その場合は２日あととかの日付を見てみるとあったりします

よろしかったらご参考ください