カテゴリー別アーカイブ: 今日のメモ

Windows10でVPN接続&インターネット接続は別経路にする

■ Windows10でVPN接続をしていると・・・

自宅のPCはインターネット専用のようなものだけど、時々VPNで会社などに繋げて仕事をしたりということもある。
しかし、VPNで接続した際、インターネットの接続もVPN接続先にあるデフォルトゲートウェイが窓口になってしまう。
ところが、VPN接続先が必ずしもインターネットに接続されているわけでもないし、インターネットへ抜けられる端末が限定されていたりなんてこともなくはない。

できればインターネットへの接続はVPN接続先ではなく、自宅のプロバイダに向けたい。

 

■まずはグローバルIPの確認

以下のURLでVPN接続前のIPアドレスを確認する。
https://www.cman.jp/network/support/go_access.cgi

続いてVPN接続後のIPアドレスを確認し、インターネット接続もVPN接続先からと鳴っていることを確認する。

 

■VPN設定の変更

続いて
「コントロールパネル」→「ネットワークとインターネット」→「ネットワーク接続」と辿って、該当のVPN接続に関する設定を変更していくので、アイコンを右クリックして「プロパティ」を開く。

 

プロパティが開いたら
「インターネット プロトコル バージョン 4 (TCP/IPv4)」を選択し
「プロパティ」をクリック

ここはVPN接続先によって設定が異なる可能性がある。
けど、そのまま「詳細設定を」開く。

「リモートネットワークでデフォルトゲートウェイを使う」
にチェックが入っているので、このチェックを外し「OK」

ここでVPNに接続したままだと下記メッセージが出るので、この辺りでいったんVPNを切断しよう。

 

■もう少し設定が必要

これで接続先のデフォルトゲートウェイを使わなくなったので、再度VPNに接続すればインターネットへは自宅で契約しているプロバイダを経由して出て行ける。

けど、これだけだとVPNに接続しても相手先が見えないので、VPN接続先にどの通信を向かわせるかを意図的に設定してやる必要がある。

例えばVPN接続先のネットワークアドレス(ローカルのアドレスね)が
192.168.100.0 / 255.255.255.0
ファイルサーバのアドレスが
192.168.100.20
だった場合、エクスプローラーで「\\192.168.100.20」としてもアクセスできない。
というのも自PCが192.168.100.20との通信はどこを経由していけばまだ知らないから。

というわけで、192.168.100.0 / 255.255.255.0 というネットワークにはどの経路を通ればいいか明示してやればいい。

 

■ひと手間の前準備

その前に、VPN接続した際に、自PCにどんなIPアドレスが割り当てられているかを確認しておく必要がある。
「どの経路を通ればいいか」を指定する際、一番最初に通るところが自PCのLANポートとなるため。

再び
「コントロールパネル」→ 「ネットワークとインターネット」→「ネットワーク接続」と辿って、 該当のVPN設定を右クリックして、今度は「状態」を開く。

その中で「クライアント IPv4 アドレス」という部分をメモっておく。

 

■ひと手間の情報確認

これらの情報を元に次の設定に移るが、いったん内容をまとめてみる。

VPN接続先のネットワークアドレス
  → 192.168.100.0 / 255.255.255.0
アクセスするファイルサーバのIPアドレス
  → 192.168.100.20
自PCに割り当てられているVPNのためのIPアドレス
  → 192.168.100.201

 

■ひと手間のおまじない

というわけで最後のひと手間。
それには「コマンドプロンプト」を使う。それも管理者権限で。

「スタートボタン」→「Windows システムツール」→「コマンドプロンプト」を右クリック→「その他」→「管理者として実行」
と辿るとあまり見慣れないであろう黒背景のウィンドウが現れる。
が、その前に1つ下のメッセージが出るので「OK」を。

ここに今まで確認してきた情報を少し使って下記のように打ち込み、「OK!」となんともキャッチーな返信が返ってくれば完了。
route add 192.168.100.0 mask 255.255.255.0 192.168.100.201

これでVPN接続先のファイルサーバ(192.168.100.20)にもアクセスできるし、インターネットには自宅のプロバイダ経由で接続されるようになった。

難点は「route add」というコマンドをVPNに接続するたびに実行しなければならないこと。
慣れれば1,2分の作業だけど、自動化したいよね~・・・

念のため、冒頭の「まずはグローバルIPの確認」で見たように、きちんと自宅プロバイダのIPアドレスで繋がっているかを確認しておこう。

AmazonMWS 受注リストの取得

< 目的 >

受注状況のみの確認を行いたい。
(セラーセントラルの動作が若干重く、そして若干使いづらいので)

 

< 必要なもの >

Amazonとの出品契約(大口出品者)
MWSアカウント(登録は https://services.amazon.co.jp/services/mws.html から)
C#クライアントライブラリ(AmazonマーケットプレイスWebサービス(MWS)の「API&ドキュメント」、「注文」よりダウンロード)

 

< 手順概要 >

ダウンロードした「C#クライアントライブラリ」を解凍しプロジェクトに下記二つのファイルへの参照を追加する。
・MWSClientCsRuntime-1.0.dll
・MWSOrders_2013-09-01_v2015-09-24.dll

srcフォルダにサンプル等があるので適宜プロジェクトに導入。
尚、他のAPIについても基本手順は同様。

 

< 詳細 >

基本的にはsrcフォルダにある以下4つのファイルをそのままプロジェクトに組み込めばよい。

・MarketplaceWebServiceOrders.cs
・MarketplaceWebServiceOrdersClient.cs
・MarketplaceWebServiceOrdersConfig.cs
・MarketplaceWebServiceOrdersException.cs
・MarketplaceWebServiceOrdersSample.cs

尚、namespaceやMarketplaceWebServiceOrdersSample辺りは名称を変えても良いでしょう。

他、accessKeyやsecretKeyなどを取得したMWSアカウントに従って入力しておく。

が、「注文」APIだけでなく「商品」APIなどでもアカウント情報は使用するので、別のクラスにまとめる。
が、staticにするかシングルトンパターンにするか迷い、結局、シングルトンを採用し、以下のように。

 

尚、サンプルはコンソールアプリとして作られているので、MarketplaceWebServiceOrdersSample.cs 内の下記部分は変更が必要。

そもそもSampleという名称にある通り、上記に限らず、目的に応じてこのファイルに該当する部分は変更または新規に作成していくことになるでしょう。

 

 

C#を始めて見たんだけど・・・ビルドしたものがWinXPで動かない・・・

Visual Studio Express 2013 for Windows Desktop

これ、無料で使えるのね。すごいわ。

てことで、javaでもなくC++でもなく、C#を始めてみた。なぜC#なのかは謎だけど・・・

さて、Visual Studio をインストールしたのはWindows7の64bit。

出来上がったプログラムはこの環境で使うのはもちろん、32bitなWindowsXPでも使ってみたいな、と。
ふとそう思って出来上がったものをXPにコピーして実行してみたら・・・動きません・・・

「アクティブソリューションプラットフォーム」という項目を「AnyCPU」から「x86」にしてみたりもしたけれど動きません。

というか、調べると「AnyCPU」でも32bitで動くようにビルドされるとのこと。

はて、32bitでも動くようにビルドされるなら32bitなXPで動作しないのはなぜだろう・・・

VS2013_Cpp_forXP_01
調べてみると、C++だとプロジェクトのプロパティから「プラットフォームツールセット」を変更することで出来る模様。

 
 
しかし、C#ではこんな設定項目はない。。。
というわけで、もう少し調べてみると・・・

VisualStudio2013で
「対象のフレームワーク」の変更が必要だった。
というのも、.NET Framework 4.5はWindows7にインストールされてるんだけど、WindowsXPにはインストールされていないから。

というよりも、WindowsXPには4.0までしかインストールできない。

なので、ここを「.NET Framework 4」に変更する。

これでOK。

信書が話題だけど・・・(メモ)

郵便局の人がちょいと会社に来た。

ゆうメールは「新書」「物品」は送れない。管轄は国土交通省。

ゆうパケットは「新書」は送れないが「物品」は送れる。管轄は国土交通省。

定形郵便・定形外郵便は「新書」「物品」も送れる。管轄は総務省。

ゆうパックは「新書」「物品」も送れる。管轄は総務省。

とのこと。

なんだ、改めてみれば簡単な話で、ゆうメールはともかくゆうパケットも総務省じゃなくて国土交通省が監督省庁だったのか・・・

ま、信書は郵便か宅配便を使っておけ、ということですかね。

C#のメモ

VSCSharp_CoreTweet_01
VisualStudio の右上にある 「クイック起動(Ctrl+Q)」に「coretweet」と入力しエンター。
VSCSharp_CoreTweet_02
「インストール」をクリック

あとは、CSファイルで

using CoreTweet;

と追加すればOK。


string TW_API_KEY = “xxxxxxxxxxxxxxxxxxxxxxxxxxxx”;
string TW_API_KEY_S = “xxxxxxxxxxxxxxxxxxxxxxxxxxxx”;
string TW_ACC_TKN = “xxxxxxxxxxxxxxxxxxxxxxxxxxxx”;
string TW_ACC_TKN_S = “xxxxxxxxxxxxxxxxxxxxxxxxxxxx”;

StringBuilder Tweet_text = new StringBuilder();

var tokens = CoreTweet.Tokens.Create(TW_API_KEY, TW_API_KEY_S, TW_ACC_TKN, TW_ACC_TKN_S);

foreach (var status in tokens.Statuses.HomeTimeline(count => 10).Where(x => x.Text.Length > 60))
{
Tweet_text.Append(status.Text + “\r\n\r\n”);
}
TweetArea.Text = Tweet_text.ToString();


節電のためにサンワサプライの700-TAP017を買った

前回、電気代が前年比10%高で反省し、サンワサプライの700-TAP017を注文した。

Amazonで注文したわけだけど、発送はサンワダイレクト。
そして、翌日に当たる今日、到着。 早いね。

さて、一般家庭で使える電力計としては同社の「TAP-TST8」が定番で間違いない。
でも、同じものじゃなにか面白くないので、あえてまだあまり見ない「700-TAP017」にしてみたわけで、その違いは以下の通り。

TAP-TST8

測定は0.3Wから
1時間あたりの電気代表示なし
出力コンセントは下
電気料金換算レートが変更できる
差し込まれたプラグを金属板1枚で保持
金属板の対面はプラスチック
つまり、接触面積が小さく発熱しやすい
トラブルのほとんどはこれが原因
なので、大電力を使うには向かないのかも
エアコンに使うな、と書かれているのにもかかわらず、使っている人も多いし、発熱したとか焦げたとかの原因は製品にも問題があるけど、ユーザー側にもある模様
700-TAP017

測定は1Wから
1時間あたりの電気代表示あり
出力コンセントは横
電気料金換算レートが変更できる
差し込まれたプラグを金属板で挟むタイプ
TAP-TST8が金属板1枚だから、この辺は安心感が高い

結論、やっぱりどっちを買ってもそんなに大差はないと思う。

強いて言うなら、プラグを差し込んだ時に銅板のような金属板で挟み込むように保持する点がメリットかな。

というわけで、以下、画像をダラダラと。。。

700-TAP017_01
箱。飾りっ気もなにもない、ただの、箱
700-TAP017_02
製品を取り出してみた
700-TAP017_03
右側面にコンセント出力
700-TAP017_04
裏面。(株)カスタムの文字がありますな
700-TAP017_05
銅色をした金属板が2枚ずつ
700-TAP017_06
とりあえずコンセントに挿すが、当然0W
700-TAP017_07
PC、モニタ、アンプ、DACの待機電力は5W
700-TAP017_08
PC電源オンで150W強
700-TAP017_09
モニタの電源オンで+90W(モニタ、喰い過ぎ)
700-TAP017_10
アンプオンでさらに+30W
700-TAP017_11
DACオンで+12W

なんと、モニタが異常なくらい消費してんな~

最大で8割削れそうだ。
悪くても5割は削れる。

・・・え?
バックライトがLEDな最近のモニタってずいぶんと省エネなのね・・・

ん~、それならとっとと買い換えた方が良いな、モニタ。