スキーも年に2～3回なので20年近く前に購入したLANG XR9 DEMOを履いていました。
さすがにこれだけ古いとインナーブーツもボロボロで履くのも一苦労です。
熱成型したインソールまで入れて大事に使っていたので思い入れも強かったのですが
体同様さすがにくたびれてしまったので、購入を考えました。
これからはシルバーのお気楽スキー用にそれなりのスキーブーツにしようと思いました。
そこで選択したのは、量販店の中級モデル、還暦スキーヤーには最適な選択でしょうか？
さよならLANGE
カント調整ネジがあったので店員さんに使い方を聞いたら”上級モデルの部品の使いまわし
なのでこのモデルではカントの調整は出来ません”だそうです。
なんちゃってカント調整はこれです
スマホで外出先から光電話で通話して、本当にアリバイが
証明されるのでしょうか?検証してみました。
ここからは素人のなんちゃって脚本になりますが・・・笑
会社社長のA氏は、倒産寸前の会社を立て直す為に、保険金殺人を企てました。
妻B子に多額の保険金を掛け、妻を自宅から300km離れた別荘で殺害します。
その直後、妻の携帯にスマホde光電話を利用して電話をし数十秒通話後切ります。
話をしている途中に来客があり、妻が”後で電話すると言って電話を切った”と証言する為です。
その後車で自宅に戻りながら、妻の携帯に数回スマホde光電話で着信履歴を残します。
明朝、隣人に”別荘に行った妻と連絡が取れなくなった”と話してから別荘に行き
妻を発見し、警察に通報する・・・・とドラマでよくありそうな設定です。
ドラマでは敏腕刑事がアリバイを崩していくわけですが・・・・・・
まず光電話ルータにはどのようなログが残るのでしょうか
実際に177あてに電話してみます。
光電話ルータPR-400NEの通話ログは、管理画面から見る事が出来ます。
通話に関するログは 、以下の2行です。
こちらから発信したときのログで、”自切断”とは自ら電話を切ったということでしょうか？
2012-12-18 09:47:32 voip -28.ntc: 通話 [自宅電話番号] [通話先電話番号]
2012-12-18 09:48:01 voip -30.ntc: 通話切断 [自宅電話番号] [相手先電話番号] 自切断
どの電話機から発信したかのログはありませんので、証拠は残りませんね！
次にルータRTX1200のログを見てみます。
2012/12/18 09:45:59: TUNNEL[20] PPTP connection is established: [スマホのグローバルIP]
2012/12/18 09:46:00: PP[ANONYMOUS01] PPTP Connect
2012/12/18 09:46:04: PP[ANONYMOUS01] Call detected from user ‘ユーザー名’
2012/12/18 09:46:07: PP[ANONYMOUS01] PPP/IPCP up (Local:[RTX1200のIP], Remote: [スマホに払い出されたIP])
2012/12/18 09:48:30: TUNNEL[20] PPTP connection is closed: [スマホのグローバルIP]
PPTPに関するログは以上です。PPTPで接続したグローバルIPと接続ユーザー名はわかります。
ここから先は、私には調べる手段はありませんが・・・・
問い合わせれば、そのグローバルIPが払い出されていたスマホの特定は出来るかもしれません。
また特定したスマホがどこの基地局を使用していたかも分かるかもしれません。
しかし用意周到な犯人Aがそのようなログを消さずに残しているでしょうか？
素人ではこの辺までの推理しか出来ません。
しかし犯罪レベルではなく、家庭や、恋人へのアリバイ工作には使えるかもしれません。
あくまでもご自分の責任で・・・・・・・・・・
以前”RTX-1200配下nat越で”スマホdeひかり電話”を使う”という投稿をしましたが、
これをPPTP(L2TP)で外出先から使用すれば自宅にいなくても家電からの発着信が
出来てしまいます。
TVドラマで、家電での発着信履歴が不在証明となるシーンがありますが成り立たなくなりますね~
nat越えでスマホdeひかり電話が動作していれば、PPTPで同IPを割り当てるだけで使用できます。
VPNルータ（PPTP orL2TP)は、ひかり電話ルータの内部に設置することになりますので
natの設定は必須事項となります。
PPTPの設定はこちらの投稿を参照してください。
家から車で１分足らずでLTEエリアです。iPhone+iPadでテザリング時のスピードテスト
をしてみました。テストサイトはBNRの画像読み込みタイプです。
http://www.musen-lan.com/speed/
結果は、くだり15.03Mbpsのぼり2.29Mbps
十分なスピードですね。
多いときは毎日”Rebooted by XTLB unmatch”というログを残してrebootしていた
RTX1200がここ数日は、安定しています。
設定変更したことといえば
1：pp2はIPv6用なのでIPv4をすべてフィルタリングした
2：pp3(PPPoE)を追加、ルーティングの設定を変更 http://www.hstech.jp/?p=390
思い当たるのはそれくらいです。
まだ5日目なのでもう少し様子を見ないと分かりませんが･･･
以前の設定変更時にも、reboot回数が減ったのですがいつの間にか元に戻ってしまったので
しかしこの情報は、ネットで検索しても少ないですね～
ルーター(RTX1200)のPPTP,L2TP設定はこちらを参照してください。
今日からソフトバンクiPhone5のテザリング接続サービスが、開始しました。
待ちきれず早速テストしてみました。
設定⇒一般⇒モバイルデータ通信とたどってインターネット共有をオンにします。
その後は設定⇒インターネット共有でオン・オフが出来ます。
インターネット共有をオンにして、iPadの設定⇒Wi-Fiとたどると一覧にiPhone5の名前が
表示されます。WiFiマークではなく、くさりのマークです。
これを選択するとiPhone5側に”インターネット共有：1台接続中”の表示が出ます。
この状態でiphone5でPPTPの接続をしてみました。
結果は問題なく、SPモードのような事はないようです、ホット一安心！
次にiPadでのVPN接続のテストをしました。
PPTP、L2TPともに問題なく接続できます。
VPN接続時には、iPadの左上にくさりのマークとVPNの文字が出ますので一目瞭然です。
それぞれの状態でENV確認サイトでHOST名の確認をして見ました。
http://www.cybersyndrome.net/evc.html
問題ないようです。
感想：
LTEサービスエリアの境界のロケーションなので、2階ではLTE、1階では３Gでの接続環境です。
LTE接続時は、フレッツネクストとのスピード差は、感じられませんでした。
自宅でテザリングすることはないので、支障はありませんが３Gの遅さを改めて感じました。
現在契約している光ポータブル+ぷららモバイルは解約することになりますが、
契約解除料15,750円（税込）が痛い!!。
IPv4とIPV6の２つのPPPoEセッションでデュアルスタック運用してますが
フレッツ光ネクストが3セッション可能な契約なので、もうひとつISPを追加する為
RTX1200の設定を変更しました。
現状、IPv4(PP1)は/29でもらっているので、サーバー用にIP2つ、2つのローカルエリアネットワークから
それぞれNATで出る為に2IP使用しています。IPv6(PP2)はRAまかせです。
そこにPP3を追加するわけですが、ルーティングをどうするかです。
そこでデフォルトルートにフィルターかけて家庭用のLANをpp3に向けることにしました
現状のルーティング（他の拠点へのルートはIPsecトンネルへ向けています。）
ip route default gateway pp 1
ip route 192.168.0.0/24 gateway tunnel 1
ip route 192.168.1.0/24 gateway tunnel 2
ip route 192.168.2.0/24 gateway tunnel 3
ip route 192.168.3.0/24 gateway tunnel 4
ip route 192.168.4.0/24 gateway tunnel 5
ip route 192.168.5.0/24 gateway tunnel 6
ip route 192.168.6.0/24 gateway tunnel 7
ip route 192.168.7.0/24 gateway tunnel 8
新設定
新しく新ISP用にPP3を作成する
pp select 3
略
ip pp nat descriptor 100
pp enable 3
デフォルトルートに追加設定
ip route default gateway pp 1 gateway pp 3 filter 100
フィルター100に合致したものはPP3にルーティングされます。
ip filter 100 pass 192.168.99.2-192.168.99.254 * * * *
この設定では、192.168.99.0/24のネットワークからのルートがPP3にルーティングされます。
nat descriptor address inner 100 192.168.99.2-192.168.99.254
natの設定も必要ですが、nat descriptor address inner の設定だけで動作しています。
本日iPhone5にキャリアアップデートの通知がありました。
これを適用すると、13.1⇒13.2にアップデートされます。
12月15日にならないと使用できないようですが。
PPTPによるVPN接続が出来るか?テザリング接続した端末からも同様のことが出来るのか
興味津々ですが・・・・
そもそもDKIMの導入メリットとは何でしょうか?
2012年5月に総務省が取りまとめた、ISP４社（YAHOO!、ビッグローブ、IIJ、ニフティ）の
DKIM＝passとなったメールの割合は25％です。
http://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/pdf/120726_3.pdf
DKIM署名をしているISPでもこの割合ですので他のISPではもっと下がるでしょう。
この程度の普及率では、DKIM＝pass以外のメールを拒否したり迷惑メールとすることは
とても出来ません。
では何の為？といわれたらDKIM認証が通らないメールはSPAM扱いですよ～っというISPが
今後増えてこないとも限りませんのでそのための対策です。
自メールサーバーは、DKIMでフィルタリングするつもりは毛頭ありません。
数年前からS25Rというスパム対策をしていてこれが高い効果を得ております。
これは送信元のメールサーバのアドレスからメールサーバがエンドユーザー回線（動的IP）から
発信しているか判断し450を返すという仕組みで⇒S25Rインタビュー記事
これを導入してから高いspamメールフィルタ効果を得ております。
こちらもご覧になってみてください。送信ドメイン認証はスパムに勝てないだろう
最後にyahoo.co.jpあてに送ったメールのヘッダーを記して終了します。
ヤフー宛メールのヘッダー（DKIM署名付けても迷惑メール扱いです笑）
From =?iso-2022-jp?B?GyRCI0gjUyVGJUMlLxsoQiAbJEJMWkI8GyhC?= Mon Dec 3 22:53:43 2012 X-Apparently-To:ikuko_kimura@yahoo.co.jp via 183.79.100.204; Mon, 03 Dec 2012 22:53:47 +0900 Return-Path:<yoshio@hstech.net> X-YahooFilteredBulk:219.105.37.35 Originating-IP:[219.105.37.35] Received-SPF:pass (dns2.hstech-net.com: domain of yoshio@hstech.net designates 219.105.37.35 as permitted sender) receiver=dns2.hstech-net.com; client-ip=219.105.37.35; envelope-from=yoshio@hstech.net; Authentication-Results:mta505.mail.kks.yahoo.co.jp from=hstech.net; domainkeys=pass (ok); dkim=pass (ok) header.i=@hstech.net Received:from 219.105.37.35 (EHLO dns2.hstech-net.com) (219.105.37.35) by mta505.mail.kks.yahoo.co.jp with SMTP; Mon, 03 Dec 2012 22:53:46 +0900 Received:from dns2.hstech-net.com (localhost [127.0.0.1]) by dns2.hstech-net.com (Postfix) with ESMTP id 5EB706203FA for <ikuko_kimura@yahoo.co.jp>; Mon, 3 Dec 2012 22:53:48 +0900 (JST)> DKIM-Signature:=1; a=rsa-SHA256; c=relaxed; d=hstech.net; h=message-id :from:to:subject:date:mime-version:content-type :content-transfer-encoding; s=hstech; bh=cm3wifXTQb1BDJmgLrqwHaa Kt7jTusy9rHJ3pkuNlJs=; b=BF8VIXEciEo2HIIImrwQsbLKwuW40OV1McyGZrJ 9AjPMIyPq1gSPruzvF8g4Edh1m8ZOlJoeynXIlsCmoq1RIY1dvZSZHDXFRHH8qmS LgSNhg/z8eLqWZhneS75mGNNc1HC74NOd96JgLjiBP/V+kSsl72zXdCbSWE7Of2Z E73U= DomainKey-Signature:a=rsa-SHA1; c=nofws; d=hstech.net; h=message-id :from:to:subject:date:mime-version:content-type :content-transfer-encoding; q=dns; s=hstech; b=UY4o/qSUkaQLAfMtn PtvnHwHzCiNkkYC2uTKB5HeMEJddRjYe4ctqASTr9BoCy7qkH1q6zyp/VMJGsJxW yJqADBiDvZOcit/UyBO439/wJgkVYbJu58H4dqNIs6JeuGlAZgI8MfR+XS0OP8nn w3/mpwlyjDHZ4RPieRw0EaBz+w=Received: from hstechPC1 (unknown [192.168.120.101]) by dns2.hstech-net.com (Postfix) with ESMTP id 49EBF6203DA for <ikuko_kimura@yahoo.co.jp>; Mon, 3 Dec 2012 22:53:48 +0900 (JST) Message-ID:DDEA1A44372E4F12B8A8CCB8553D6E96@hstechPC1> From:=?iso-2022-jp?B?GyRCI0gjUyVGJUMlLxsoQiAbJEJMWkI8GyhC?= yoshio@hstech.net
いよいよ署名を付けてみます。
他の設定は済んでいるので、postfixのmaster.cfに記述するだけです。
参考サイト： http://dkimproxy.sourceforge.net/postfix-outbound-howto.html
sasl-authで587番ポートを使用しているのでこのポートに来たメールのみ署名をします。
# # modify the default submission service to specify a content filter
# and restrict it to local clients and SASL authenticated clients only #
submission inet n - n - - smtpd
-o smtpd_etrn_restrictions=reject
-o smtpd_sasl_auth_enable=yes
-o content_filter=dksign:[127.0.0.1]:10027
-o receive_override_options=no_address_mappings
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
マイネットワーク以外からの送信が出来ないのでこの行を追加しました。
-o smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
#
# specify the location of the DKIM signing proxy
# Note: we allow "4" simultaneous deliveries here; high-volume sites may
# want a number higher than 4.
# Note: the smtp_discard_ehlo_keywords option requires Postfix 2.2 or
# better. Leave it off if your version does not support it.
#
dksign unix - - n - 4 smtp
-o smtp_send_xforward_command=yes
-o smtp_discard_ehlo_keywords=8bitmime,starttls
#
# service for accepting messages FROM the DKIM signing proxy
#
127.0.0.1:10028 inet n - n - 10 smtpd
-o content_filter=
-o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o smtpd_authorized_xforward_hosts=127.0.0.0/8
さていよいよ送信テストです。sa-test@sendmail.net へメールを送信します。
程なく返信メールが来ました、さて結果は、
sendmail.net Sender Authentication Auto-Responder $Revision: 1.19 $ This service runs at <sa-test@sendmail.net> and allows remote users to perform a simple, automated test to see if different Sender Authentication schemes are working. Mail sent to this service is checked by our Sender Authentication filters for any valid credentials or signatures. A script receives the message, checks for a special header with the results of the tests, and composes this response message based on what it finds. This response is also signed with DomainKeys Identified Mail (DKIM). Please note that the DKIM filter signing this reply message conforms to the latest IETF standard version, and thus may not be successfully verified by older implementations. If you are using dkim-filter from Sendmail, Inc., upgrade to OpenDKIM to be compatible with the most recent version of DKIM. Note that DomainKeys has been removed in favor of DKIM. Sites still using DomainKeys should upgrade to DKIM ASAP. We hope this service has been helpful to you. Authentication System: DomainKeys Identified Mail (DKIM) Result: DKIM signature confirmed GOOD Description: Signature verified, message arrived intact Reporting host: services.sendmail.com More information: http://dkim.org/ Sendmail milter: http://opendkim.org/ Authentication System: Sender ID Result: SID data confirmed GOOD Description: Sending host is authorized for sending domain Reporting host: services.sendmail.com More information: http://www.microsoft.com/senderid Sendmail milter: https://sourceforge.net/projects/sid-milter/ Authentication System: Sender Permitted From (SPF) Result: SPF data confirmed GOOD Description: Sending host is authorized for sending domain Reporting host: services.sendmail.com More information: http://openspf.org/
あれっ!
DKIM signature confirmed GOOD
ということは、DNSのドメインキーレコードは正常ということになりますね？？？
ためしにこちらのサイトで再検証してみました。
http://dkimcore.org/tools/dkimrecordcheck.html
結果は This is a valid DKIM key record
DNSの設定はこのままで良さそうです？？？あの一日はなんだったんだろう