ASP.NET 練習帳

国内の ASP.NET サーバーに関して

CentOS 5, CentOS 6 では SLAAC で v6 アドレスを割り当てると、Modified EUI-64 な v6 アドレスが付く。ところが、CentOS 7 では謎な v6 アドレスが付く。この謎な v6 アドレスは RFC 7217 で説明されているらしい。

昔ながらの慣れたタイプにするには ipv6.addr-gen-mode を eui64 にする。謎タイプにするには ipv6.addr-gen-mode を stable-privacy にする。

[root@cent7f ~]# ip link show dev eth0
2: eth0:  mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:15:5d:59:74:16 brd ff:ff:ff:ff:ff:ff
[root@cent7f ~]# ip addr show dev eth0
2: eth0:  mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:59:74:16 brd ff:ff:ff:ff:ff:ff
    inet 192.168.3.6/24 brd 192.168.3.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 2001:db8:1:0:9af6:7ae:fd48:6a6c/64 scope global noprefixroute dynamic ●謎な v6 アドレス
       valid_lft 86347sec preferred_lft 14347sec
    inet6 fe80::b2bf:3b93:6f5b:24bc/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
[root@cent7f ~]#
[root@cent7f ~]#
[root@cent7f ~]# nmcli connection modify eth0 ipv6.addr-gen-mode eui64 ●変更する
[root@cent7f ~]# nmcli connection up eth0
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/2)
[root@cent7f ~]#
[root@cent7f ~]#
[root@cent7f ~]# ip addr show dev eth0
2: eth0:  mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:59:74:16 brd ff:ff:ff:ff:ff:ff
    inet 192.168.3.6/24 brd 192.168.3.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 2001:db8:1:0:215:5dff:fe59:7416/64 scope global noprefixroute dynamic ●Modified EUI-64 な v6 アドレス
       valid_lft 86395sec preferred_lft 14395sec
    inet6 fe80::215:5dff:fe59:7416/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
[root@cent7f ~]#

https://developer.gnome.org/NetworkManager/stable/settings-ipv6.html

https://developer.gnome.org/libnm/stable/NMSettingIP6Config.html#NMSettingIP6Config--addr-gen-mode

+----------+           +----------+           +----------+
|  client  | ========= |  squid   | ========= |  httpd   | 
+----------+           +----------+           +----------+

httpd が 平文でページを提供してくれる場合において client-squid 間を保護(暗号化)するには?

squid の設定にて http_port ではなく https_port を使う。

  • squid は CentOS 7.5 に付属の 3.5.20 を使用
  • curl は Fedora 29 に付属の 7.61.1 を使用 ⇐ これ重要。CentOS 付属のバージョンだと HTTPS proxy に対応していない。

いつもの設定

これだと client と squid の間を保護しない

[root@cent7g ~]# diff /etc/squid/squid.conf.000 /etc/squid/squid.conf
0a1
> visible_hostname CENT7G
59c60
< http_port 3128
---
> http_port 0.0.0.0:3128

squid を起動すると /var/log/squid/cache.log には Accepting HTTP Socket connections と記録される。

Accepting HTTP Socket connections at local=0.0.0.0:3128 remote=[::] FD 11 flags=9

client と squid の間を保護する設定

http_port の代わりに https_port を使う。

[root@cent7e ~]# diff /etc/squid/squid.conf.000 /etc/squid/squid.conf
0a1
> visible_hostname CENT7E
59c60
< http_port 3128
---
> https_port 0.0.0.0:3128 cert=/etc/squid/TLS/service.pem key=/etc/squid/TLS/service-key.pem

squid を起動すると /var/log/squid/cache.log には Accepting HTTPS Socket connections と記録される。

Accepting HTTPS Socket connections at local=0.0.0.0:3128 remote=[::] FD 12 flags=9

case 1

curl http://example.com/ -x 192.168.1.57:3128
  • 192.168.1.57 は http_port を設定している cent7g
  • client と squid 間は平文
  • squid と httpd の間も平文

case 2

curl https://example.com/ -x https://192.168.1.55:3128 --proxy-insecure --insecure
  • 192.168.1.55 は https_port を設定している cent7e
  • client と squid 間は保護されている
  • squid と httpd の間も保護されている
  • --insecure は httpd がオレオレ証明書を使っているから必要
  • --proxy-insecure は squid がオレオレ証明書を使っているから必要

case 3

curl http://example.com/ -x https://192.168.1.55:3128 --proxy-insecure
  • client と squid 間は保護されている
  • squid と httpd の間は平文

case 4

curl https://example.com/ -x 192.168.1.57:3128 --insecure
  • client と squid 間は保護されている。ただし、最初の CONNECT の部分は平文
  • squid と httpd の間も保護されている

その他

気になったから試してみただけで、https_port を使うべきとは思っていません。 case 2 の場合は二重に暗号化されて無駄だ。 http_port で満足。

「プロキシの設定」ダイアログに入力欄が二つ、HTTP と Secure がある。この二種の使い分けに関して。 proxy 上の画像のように設定した場合は下記動作になった。
  • http://example.com/page1.html を要求するときは 192.168.1.55 に設置したプロキシを使う
  • https://example.com/page1.html を要求するときは 192.168.1.57 に設置したプロキシを使う

  • 謎なのが Firefox である。Windows の Firefox、CentOS 7 の Firefox、いずれも上記のような使い分けを行わないのである。

VirtualBox に Use Host I/O Cache (ホストの I/O キャッシュを使う) というチェックボックスがありまして、それをオンするとパフォーマンスが大きく向上しました。

use host io cache

私が使うホスト機は SSD ではなく HDD を使用しておりストレージの性能は低い。一方で、RAM は 64 GB 積んでおり、常に余っているという、そういうホストです。

最初にホストにて測定



host

ゲストにて測定



cache_nashi

ゲストにて Use Host I/O Cache をオンにして測定


cache_ari

ごちガストの戦果発表。
2018/7/19 から 9/26 まで。
53 回のうち、3 回が無料。
当選確率は 1/20 らしいので、上出来だ。


2018/10/8 月曜日、体育の日に合格。

以前から citrix のオンライン ドキュメントはクソだと思っていたが、最近はリンク切ればかりでクソさが増しているのが試験準備の際に腹立たしかった。

NetScaler と戯れるために Windows 10 の Hyper-V を使っている。 スナップショットに二種類あるのを見つけて困惑。 なにこれ? checkpoint type 動かして挙動を観察してみた…多分こういうこと(以下を参照)だろう。

運用チェックポイント / Production Checkpoints

  1. ゲストにてメモ帳を起動する。
  2. メモ帳に一行目を入力する。
  3. メモ帳に入力した内容をファイルに保存することなく、運用チェックポイントを作成する。
  4. メモ帳に二行目を入力する。
  5. チェックポイントを「適用」すると、ゲスト の Windows OS が起動するところから開始する。運用チェックポイント作成時に存在したプロセス (この例ではメモ帳) は存在しない。
  • 運用チェックポイントは Windows Server 2016 から利用可能な新機能らしい。
  • このチェックポイントには、メモリー上の情報は保持されないようだ。
  • ゲストの VSS (もしくは LVM スナップショット) を用いて、ファイルシステムとしては一貫性のある状態を作り出しているようだ。
  • チェックポイントを対象にバックアップを実行してよいのだろう。⇐ おそらくこれが運用チェックポイントの存在理由

標準チェックポイント / Standard Checkpoints

  1. ゲストにてメモ帳を起動する。
  2. メモ帳に一行目を入力する。
  3. メモ帳に入力した内容をファイルに保存することなく、標準チェックポイントを作成する。
  4. メモ帳に二行目を入力する。
  5. チェックポイントを「適用」すると、メモ帳に一行目があり、二行目が消えた状態で再開する。
  • 標準チェックポイントは馴染みのあるタイプだ。
  • ホストが力業で一貫性のある状態を作り出しているようだ。

振り分け接続の数は svcEstablishedConn で取得できるようだ。 似た項目で svcActiveConn があるが、それとこれとでどう違うのかは謎。 svcEstablishedConn
snmpwalk -v2c -c citrix80386 192.168.1.2 svcEstablishedConn
show ns connectiontable 'CONNECTION.TCPSTATE.EQ(ESTABLISHED) && CONNECTION.DSTPORT.EQ(25)'
show ns connectiontable は実際の状況を即座に反映する。 ところが、snmp 経由だと反映まで5秒ほどの遅れがあるようだ。 グラフを描画するには、cli より snmp のほうが楽だと思うので、5秒なら我慢だな。

各種パフォーマンス情報を入手したい。以下に示すのは、requests per second を入手する例である。 svcRequestRate NetScaler SNMP OID Reference
svcRequestRate (1.3.6.1.4.1.5951.4.1.2.1.1.42)
Request rate in requests per second for this service or virtual server.
stat service
snmpwalk -v2c -c citrix80386  192.168.1.2 svcRequestRate
zabbix

ふと、その存在を思い出したので、思い出のサルベージを開始。
店舗の場所は憶えているが、店舗の名は憶えておらず。
google ストリートビューで見ると、店舗は映っているが、看板は見えない。
難易度高い!
やっと見つけました。

セレパーク中之島 - Google マップ

【閉店】パイン - 新福島/喫茶店 [食べログ]

中之島の老舗喫茶店がリニューアルオープン「喫茶パイン」[2017年12月末閉店] – 中之島の地域情報サイト「中之島スタイル.com」(Nakanoshima-Style.com)〜中之島の気になるお店やイベント、ビル情報をご紹介!

数か月間、ほぼ毎日昼食をここで頂いておりました。
昼食時に混むと困るから、どこにも書かなかったんだよ。
閉店したのか。
ありがとう

↑このページのトップヘ