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

 

 

ヤフオク 終了したオークションの再出品ツール作成メモ Selenium編

< 目的 >

落札者のありなしに関わらず、自動再出品の回数も消化して終了となったオークションの再出品を行う。
管理は社内PCに限りたいとのことで、クラウド型の管理ツールは使用不可。
「○○にて出品」といったようなツール名称が入るのもNGの理由らしい。
APIの提供は2018年2月で終了している。そもそも出品関連のAPIはなかった模様。

 

< 必要なもの >

・ヤフオクとのストア契約
・Yahoo!IDとパスワード

 

< 手順概要 >

APIの提供がないので若干力業的なところあり。

「マイ・オークション」の「出品終了分」内「落札者あり」または「落札者なし」のページを開く
ログインページに遷移してしまったらログインする
「落札者あり/なし」のHTMLを取得
オークションIDやリンク、タイトル、再出品ボタンのリンク先URLを収集
再出品ボタンのリンク先URLに移動して再出品処理

 

< 詳細 >

VisualStudioの該当プロジェクトに対するSelenium.WebDriverの導入は済んでいて、ブラウザごとのドライバはプログラム本体がある場所に SeleniumDriver というフォルダを作りそこに保存する、という前提。

 

もしログインされていない場合やセッションが切れていたりするとログイン画面に飛ばされるので、その際にはログインする。
ただし、状況によっては画像認証が必要となることがあるため、そのページでは60秒間待つ。
その間に手動で画像認証を行う。

 

落札者あり/なしのページが開いたらHTMLを取得し、必要な情報を収集する。

※ここではオークションIDしか取得していないけど、本来はURLなども対象。

 

再出品ボタンのURLに遷移して出品処理を行う。

尚、終了時間や自動再出品の回数などを再設定したいという要望もあったので、そのような作業も含めている。
aucEndTimeStringやautoReUpNumが該当するが、再出品に当たって共通して他にも再設定したい項目などがあればここで作業。

 

ところで、こうした自動化について回るのは「クリックしたい要素が出ていないのに処理が先に進んでしまい思う通りの動作をしない」ということがある。

今回もIEでは問題ないけどChromeだとそうした状況が発生した。

そこで、ドライバのインスタンスに対して下記のような設定を行うとタイムアウトまでの時間を変更できる。(デフォルトでは0だったような・・・)

 

 

楽天API 楽天ペイで受注情報の取得についてメモ

< 目的 >

特定の注文詳細データを取得する。
ex)ステータスが「発送待ち」となっている受注分から商品名(IDや管理番号なども)を取得したい
ex)ある一定期間内で「あす楽」の受注件数を取得したい

 

< 必要なもの >

・店舗URL
・serviceSecret
・licenseKey

 

< 手順概要 >

認証キー(AuthKey)の作成
リクエストパラメータをJSON で作成
エンドポイントにリクエストを投げる
レスポンスもJSONなので望むように処理

 

< 詳細 >

まずはserchOrderを使って受注番号を取得する。
デフォルトでは30件しか取得できないので、下記でリクエスト用のクラスにて件数を最大の1000件に変更。

認証キーの作成

 

リクエストパラメータをJSONで作成
パラメータは別途パラメータ設定用のクラスを用意。日付はUI上にデータピッカーをおいて設定。

尚、パラメータは下記のようなイメージでクラスを用意しておく。

 

エンドポイントにリクエストを投げる

 

受け取った結果もJSONなので、今回はデシリアライズしてオブジェクトにする。

デシリアライズのためには下記のようなクラスを用意。

 

SearchOrderResponseクラスのorderNumberListに最大1000件分の受注番号が取得できるので、次はその受注番号を使って受注情報を取得する。

受注情報の取得も基本的な手順は同じなので、「認証キー(AuthKey)の作成」「リクエストパラメータをJSON で作成」「エンドポイントにリクエストを投げる」「レスポンスもJSONなので望むように処理」で作業を行う。

尚、受注情報の取得にはgetOrderを利用するが、serchOrderは最大1000件の受注番号リストを取得できるのに対して、100件までとなっているので、対象の受注番号を絞り込む必要も出てくるかと。

 

Jelly Pro で バーコードリーダー

最近のスマホはどれも大きくなる一方で小さいものがなかなかない。

普段使いでは今使ってる502SHの5.3インチがちょうど片手で操作しきれる最大サイズで何をやるにしても便利だけど、一部用途で4インチ以下が欲しくなり、探してみたところ辿り着いたのが 「 Jelly Pro

◇製品ページ
https://www.unihertz.com/ja/jelly.html

◇メーカートップページ
https://www.unihertz.com/ja/

◇日本公式ツイッター
https://twitter.com/UnihertzJapan

◇本国ツイッター
https://twitter.com/unihertz

尚、2017年12月31日時点で技適は取得されていないので、日本国内ではWi-FiやBluetoothは使用できない。
とはいえ、メーカーが日本の技適取得に向けて動いてはいるみたいなので、そのうちアップデートされて技適マークが表示されるようになるかも?

 

さて、そんなJellyProですが、もう箱からして小さい。
502SHと並べても(厚みはともかく)一回り大きい程度。

 

中を空けると、本体の他にはUSBケーブルと液晶保護フィルムと青いブーメラン。
このフリスビーのようなブーメランのような、ギターのピックのようなものでJellyProの’裏蓋を外す。
その裏蓋、固い固いとネット上では言われてたけど、確かに固かった。
また、以前はUSB-ACアダプタも付属していた?ようだけれど、今は省略されいる。

 

もう一度502SHと比較。
ホント、小さい。

 

裏蓋には「Open Here」と親切に開け口が案内されている。
もちろんこれはシールなのですぐに剥がしてしまうけど。

 

裏蓋を外すと・・・
これもよくネットで見かけたけど、
「バッテリーは本体に入っている。しかも袋にくるまれて」
という状態。

「バッテリーが入っていない!」とか「USBケーブルつなげても充電しない!」という記載が見られるのはこれを見逃しているからなのだとか。

 

そしてこのバッテリー950mAhなので、あまりゴリゴリ使うようだとそれほど保たない。
しかも、代替えとなるバッテリーも今のところないので、モバイルバッテリーがひとつあると安心でしょう。
最近はスマホ用にモバイルバッテリーを持ち歩くことも多いので、それで兼用しても950mAhくらいなら問題もないと思うので。

 

さて、一通り開封と設定が終わったところで、当初の目的のバーコードリーダー化。

バーコードを読むに当たって何か最適なアプリがあれば良かったんだけど、なかなか見つからないので自作。
(アプリそのものは豊富だけど、高機能すぎたり重かったり動かなかったりで・・・)

コードは下記のような感じで、ZXingというライブラリの ZXing.Net Mobile を使うのがどうやら定番らしい。

 

これを Jelly Pro で実行すると・・・

こんな感じで読み込めます。
※今はまだ読み込むだけ。あとで実務に合うよう処理を追加する予定。

そして、横向きでも使えます。
端末が小さいので、縦向きよりも横向きの方が捉えやすい。

それにしても、認識の速さは想像以上。
しかも、赤いラインからバーコードが多少外れてていても問題ない。
(おかげで撮影は面倒だったけど・・・)

これで棚卸しが少し楽になるかな。

AmazonのFBAへの納品も、商品選定→JAN読込を繰り返して梱包箱が一杯になった等、作業の区切りでそのリストをPCに取り込み、納品プランの作成に持っていけば納品ミスもなくなるだろうし。

 

バーコードリーダー自体は安いのだけれどパソコンが必要だし、かといって単独で使えるハンディターミナルとなると高いし汎用性がない。

JellyProならAndroid7.0だし、手のひらサイズだし、スマホだし、求めていた用途をかなり満たしてくれる1台になりそうだ。

C#、ネットワークドライブ存在チェックの不思議

ちょっとメモがてら。

Yドライブをネットワークドライブとして割り当てている。
アドレスを仮に 192.168.100.1 とする。
割り当てられているフォルダは \\192.168.100.1\common ということで。

この時、C#でディレクトリの存在をチェックを行うと、

は Ture

しかし、

は False

ここまではいい。納得。
 
 
そこで次に、前回のエントリでやってみたC#で作ったDLLをExcelから使えるようにしてみたケースで試してみる。

DLLは下記のような単純なコード。

これでExcelのVBAで下記のようにすると True が返ってくる。
Cドライブなので納得。

そして、下記のようにすると・・・

やはり True が返ってくる・・・
(違いはCheckDirectory内の文字が C か Y かだけ)

もちろん、他の未使用のドライブレターで試すとFalseが返ってくる。

Yドライブはネットワークドライブで Directory.Exists(@”Y:\”) ではFalseとなるのに、なぜこの場合はTrueと返ってくるのか・・・

用途としてはこの方が助かりはするけれども。