投稿

YAMAHA ルータ実機によるIPoE IPv6時代のVPN性能比較

イメージ
RTX1300が発売されてすっかりヤマハルータの世代交代が進んだような感覚があります。インタフェースが10Gですからね。内部の設計やCPUなどの使われているチップもずいぶん性能が上がったようです。値段も10-20万円と事業所なら頑張れば買える値段ですよね。ぼくも今回とうとう通販サイトのセールで買ってきました。もちろんポケットマネーです。2台用意して最新RTX1300のテストをしました!そしておなじみの現行機種RTX1220/1210/RTX830と、おまけで旧機種RTX1200/RTX810での性能比較テストです。 結果からは、IPoE系のプロバイダでインターネットをしたりVPNを組んだりするには旧機種RTX1200やRTX810ではぜんぜん足りていなくて、RTX1220/1210やRTX830を買ってこないといけないということをわかっていただけるかなと思います。もちろん予算があるならRTX1300ですね。 環境 1Gbpsでのテスト 機種 CPUとメモリ CPUのPassmark (Single/Multi) メモ IPアドレス Lenovo M75q-1 Ryzen 5 Pro 3400GE MEM:16GB 2255/8297 クライアント側 192.168.100.2 Lenovo M75q-2 Ryzen 5 Pro 5650GE MEM:16GB 3177/18461 サーバ側 192.168.200.2 10Gbpsでのテスト 機種 CPUとメモリ CPUのPassmark (Single/Multi) メモ IPアドレス Fujitsu TX1320-M3 E3-1240 V6 MEM:16GB 2370/8669 クライアント側 192.168.100.2 Fujitsu TX1320-M3 E3-1240 V6 MEM:16GB 2370/8669 サーバ側 192.168.200.2 方法 iperfコマンドをダウンロードして使います。 アプリケーション名 ダウンロード先 iperf3 https://iperf.fr/iperf-download.php コマンド文字列 通常のPPPoE接続ではMTU=1454、nuroのDHCPではMTU=150

Microsoft 365(企業版)を契約してメールとOfficeアプリを使うための5つのポイント

イメージ
  今どき なんでもスマホポチーっで使えるサービスばかりなのに、企業版Microsoft 365はこんなに手間がかかるんだろう? もっとカジュアルに 使えるようにできなかったのかなーと思いますよね。やっぱり従来のオンプレADとWindows端末の関係とやり方をそのまま、365でも使えるようにしてみました! ということにあるんでしょう。 365と比較されるGoogleWorkspaceはしがらみがないので導入と運用はやっぱり手軽なんですよね.....。でも365も従来のオンプレはオンプレ。365は365で管理するというようにさっぱり分けてしまえばマウスポチポチだけで手軽に導入できます。ITにかかわっていると365は避けて通れない道です。 親切なことに、お試し期間は一ヶ月用意されています。期間終了時に延長申請をするとさらに一カ月使えるようになっていますので合計2ヶ月間は試せることになります。ただこれだと少し短い。。。しっかり検証するには半年ほど欲しいところです。途中で別のプランに変わっても良ければなのですが、別のプランの試用を開始してやれば実質的に期間を延長することもできました。 たぶん最大半年くらい無料で使えるかも しれませんが保証はしません(笑)。1アカウントだけ継続契約してもBusiness StandardのメールとOfficeアプリで年間約2万円、Business Basicのメールだけなら年間約1万円です。あれ? ぜんぜん高くない ?!個人の365も1万5千円になったのでほとんど変わらないじゃないですか。ここはひとつぜひ(笑) 申し込みはここから。 (アフィリエイトリンク張ってませんので安心してください) >>> https://www.microsoft.com/ja-jp/microsoft-365/business よくあるシナリオ:企業ドメインのメールをMicrosoft 365に移行してOfficeアプリも従業員に使ってもらう。 企業メールは 従来レンタルサーバでホームページを作った時に付いてきたものを使っているのも中小では多いですが、そういうおまけのメールアドレスはSPAMやフィッシングメールが多くて困っているかと思います。なんとかならないかと上司に言われたり出入りのSIerから提案されて、FortiGateなどのUT

Postfixでドッペルゲンガードメイン(gmai.com/iclud.com)宛のメール送信を禁止する

イメージ
最近のビルトインガスコンロはかけっぱなしでも過熱防止センサーで自動停止するんですね。ずいぶん安心になったと思います。工場勤務の経験がある方だと、両手で押さないと起動しないスイッチ、人が危険エリアに入るとセンサーで停止する機械などミスを防止して安全を図るための方法がいくつも取られていることにお気づきだと思います。ふりかえってパソコンやサーバではどうかというとまだまだかもしれません。セキュリティインシデントの内容によっては社会的に立場を失ってしまうことからも、ぜひシステム側でフォローできることはしておきたいです。 今回はPostfixでドッペルゲンガードメイン(gmai.com/iclud.com)宛のメール送信を禁止してみようと思います。 設定 /etc/postfix/transportの内容 宛先ドメイン error: メッセージ と記述するとここに書いたドメイン宛を禁止できます。メッセージにはダブルクオーテーションで囲んで"Incorrect Domain Name."としましたがダブルクオーテーションは無くてもいいですし、もっと直接的に "Doppelganger Domains ."と書いてもいいかもしれませんね。 gmai.com error: "Incorrect Domain Name." iclud.com error: "Incorrect Domain Name." /etc/postfix/main.cfの内容 transport_maps = hash:/etc/postfix/transport ハッシュ化して再読み込みさせます。一度transportファイルを作って有効化していれば2度目からは再ハッシュ化だけで、postfixのリロードなしで反映されるようです。 postmap transport systemctl reload postfix 送信できなくなっているか確認する メールソフトにOutlookの場合 『このメールは、受信者全員または一部に届きませんでした。』『以下の受信者にメールを配信できません』っていうメッセージはOutlookが作っているんですね。サーバの応答メッセージじゃありません。Outlookを使

Proxmox VE 7.x(3)- VLANの使い方

イメージ
Proxmox-VEでVLANを扱うにはいくつか方法がありますが 物理インタフェースにブリッジ(VLAN-aware)を作る方法 物理インタフェースにVLANインタフェースを作ってその上にブリッジインタフェースを作る方法 の2通りを紹介します。最初の方が管理が楽なように感じますね。耐障害性や性能差についてはどうなんでしょう。検証用途ですし気にすることもないかと思います。 ブリッジを作るとき、「Linux-Bridge」「OVS-Bridge」のどちらかを選べますが、普通に使うには「Linux-Bridge」を選んでおけば良いようです。 参考 https://openstackdays.com/archive/2016/wp-content/uploads/2016/07/G7_OpenStackDays2016.pdf OVSとLinux Bridgeでの性能差は無い ■ 物理インタフェースにブリッジ(VLAN-aware)を作る方法 出来上がりはこのようになります。 vmbr0は物理インタフェースeno1(デフォルトのブリッジ)で作られています。VLANなしでシステムもvmbr0を使っています。 vmbr1は物理インタフェースeno2で作ります。「VLAN aware」が「はい」として設定されるとこのブリッジにはすべてのVLANがタグ付きで流れます。 詳しく見ていきましょう。 デフォルトで作成されているvmbr0ブリッジ 物理インタフェースeno1で作られています。これはVLANなしで作られていてシステムもvmbr0を使っています。 作っていきます。ネットワーク>作成>Linux Bridge VLAN用にvmbr1ブリッジを「Vlan aware」にチェックを入れて作ります 物理インタフェースeno2を指定して作ります。するとこのブリッジにすべてのVLANがタグ付きで流れるようになりますので、あとは仮想マシンでこのブリッジとを使うときに使いたいVLANを指定してあげればいい。というのがポイントです。 設定は以上です。ではゲストになる仮想マシンの設定について見ていきましょう。もちろん仮想マシン自体の設定ではVLAN設定は不要です。   ゲストにvmbr1を割り当てインタフェースにタグを指

Proxmox VE 7.x(2) - ゲストOSにWindows10/Windows11の導入

イメージ
Windows10/Windows11のインストールにはVirtIOドライバの読み込みが必要です。 VirtIOドライバISO取得 Proxmox VE 公式手順(Windows VirtIOドライバ) https://pve.proxmox.com/wiki/Windows_VirtIO_Drivers こちらからダウンロードして、Windowsのインストール用ISOとあわせてProxmox-VEのISOフォルダにアップロードしておきます。 https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso 「local(pve)」>「ISOイメージ」にアップロードします。実際に置かれる場所は/パーティションの/var/lib/vz/template/iso ディレクトリです。前半のBlogに書きましたがデフォルトで/パーティションは約100GB(96GB)で、うちシステムOSが3-4GB使っています。 ISOのアップロード先。(日本語名のISOはアンダースコア_に置換されています) 実際は仮想マシンを作ってからですがこのあと、Windows11仮想マシン作るとVMのディスクイメージはLVMボリュームで作成されます。 Windows仮想マシン作成 左ペインで右クリックまたはツールバーの「VMを作成」をクリックします。 全般。VMに名前を付けます。VMwareと違ってほかの仮想マシンの名前と重複しても、100から始まる通し番号で区別されていますので大丈夫です。 OS。ここでISOイメージとOS種類を指定します。 システム。Windows10ではデフォルトで大丈夫ですが、Windows11ではBIOSに「OVMF(UEFI)」、TPMストレージは「local-lvm」、バージョンは「v2.0」を指定します。TPMは書き込み可能なストレージ領域が必要なためです。また忘れずにQEMUエージェントにもチェックを入れ有効にします。ゲストOSでエージェントプログラムを動かしていると、仮想ホストから仮想ゲストのIPアドレスを取得できるなど状態を取得できるようになります。 ディスク。virtioを選択します。容量は適