Rocky Linux 9で、/dev/sdb1に作成していたパーティションを拡張する

データ置き場として使っていたLinuxマシンのディスクが一杯になってしまい、ディスクの容量自体を拡張したのですが、ファイルシステムへ反映させて拡張した領域を使えるようにするまでに一悶着あったのでメモ程度に。

前提条件

• マシン環境: VMware ESXi上の仮想マシン
• OS: Rocky Linux 9.6
• LVMを使用していない
• パーティションを直に切って、XFSで運用
• データ用ディスクとして、1ディスクに1パーティションのみとしていた
• /dev/sdbに、/dev/sdb1というパーティションが存在していただけ
• ブート用ディスクは別に存在している (今回は出てきません)
• 300GB -> 600GBに増強
• root権限で入って操作しました。 必要に応じて各コマンドにsudoを付けてください。

やったこと

1. ESXi上でディスク容量の変更
2. パーティションの拡張
3. ファイルシステムの拡張

1. ESXi上でディスク容量の変更

詳細は省略します。

ESXiのWebコンソールから容量を打ち直しただけです。

2. パーティションの拡張

先にパーティションを拡張して、ディスク全体を使えるようにしてやりました。

拡張はgrowpartで行いましたので、入っていない場合は先にdnfでインストールします。

dnf install cloud-utils-growpart 

今回のパーティションは/dev/sdb1なので、1番目のパーティションを拡張します。

特に何も指定しなかったので最大容量まで引き上げられているはずです。

growpart /dev/sdb 1 

3. ファイルシステムの拡張

XFSを拡張して、増強した容量を全て使えるようにします。
xfs_growfsコマンドを使用します。マウントポイントを引数で渡す、という感じに指示されていますのでマウントポイントを調べて渡しました。

xfs_growfs /mnt/disk1

※マウントポイントではなく、デバイス名(/dev/sdb1)でも動くようです。当方ではそれでも通りました・・・。

色々調べた限りでは、3のファイルシステムの拡張だけで行ける、という感じで書かれているサイト様が多かったのですが、当方ではダメだったのでgrowpartで拡張する作業を挟みました。

参考資料

• 第13章 XFS ファイルシステムのサイズの拡大 (RHEL8 ドキュメント)

Rocky Linux 8.5にDocker-CE / Docker-Composeをインストールする

RHELクローンのRocky Linuxに、Docker-CEとDocker-Composeを入れてテスト環境を構築しましたので、手順をメモ程度に。

結論は、RHELクローンということで、CentOS向けのインストール手順に従ってインストールすれば良いようです。

今回の条件・手順としては、

• Rocky Linux 8.5を最小構成でインストール
  (ネットワークは有効化し、インストール直後にdnf updateでシステムアップデート・再起動を実施)
• Docker-CEをインストール
• Docker-Composeをインストール

となります。

Kubernetesクラスタで、ノード起動後にDockerが起動せずにReadyにならない場合の確認と対処

Kubernetesクラスタに参加しているマシンを起動した直後に、kubectl get nodesで見えるステータスがNotReadyからReadyに変わるはずであるが、ごくまれにマシンは正常に起動しているにもかかわらず、Docker Daemonが正常に起動せず、それに引きずられてKubeletも起動しないため、Kubernetesクラスタ側からは認識されないという現象が起きるのでメモ書き程度に。

今回の題材にする環境は、おおよそ下記に示すソフトウェアや台数で構成しています。

• Kubernetes 1.17.13
• Ubuntu Server 18.04
• Docker CE 19.03

• Kubernetesクラスタの構築場所： オンプレミスのVMware ESXi ホスト上
• Kubernetes Control-Planeノード x 3台
• ワーカーノード x 5台

この事象が起きるクラスタはPrometheusで監視しているので、この現象が起きると毎回アラートが飛んでくるのであるが、大体いつもマシンは起動しているのに何故？と毎回焦るので…。
ここに書いたことで、この現象はそういえば書いたなという記憶に残ってくれてすぐに対処できたり、焦らなくなることに期待。

---

当該マシンにログイン後、下記コマンドでdockerとkubeletの動作状態を確認する。

sudo systemctl status docker
sudo systemctl status kubelet

docker / kubeletどちらのデーモンもinactiveになっているのであれば、dockerとkubeletを下記コマンドで手動で立ち上げてやることにより、とりあえずクラスタ内で機能する状態に戻せるはずです。

sudo systemctl start docker
sudo systemctl start kubelet

これらのコマンドで戻らない、あるいは起動してもinactiveに戻ってしまう場合などは、control-plane側で何か障害が起きているか、あるいはノード自体の情報がクラスタから飛んでしまっているなど別な要因も考えられます。

---

今回の現象がなぜ起こったのかを少し考えてみると、手作業でDocker Daemonを起動した際に時間が掛かっていたので、システム起動時の場合はタイムアウトとなり、Dockerが起動せずにそのまま立ち上がってしまうのが原因ではないかと考えております。
(systemctlコマンドから起動する際は人間が待っていれば良いのですが…)

Dockerが起動していない状態では、Kubeletも当然のように動作できないのでこのような現象が引き起こされるのではないかと推測しています。
(当該のKubernetesクラスタは、開発用の仮想サーバー20台程度を無理やり1台の仮想ホストに押し込んでいる環境下にあるので、多少動作遅延が出てもまぁあり得るよなあとしか思えないような状況)

Kubernetes + Containerdなど、Docker以外のCRIを使用している環境では、同じ現象が起きるかはまだ遭遇したことがありません。
(今回の現象の条件を考えると、似たようなことは起きる可能性はあるんじゃないかと思います)

TrueNAS 12.0でディスクを交換する

 TrueNAS (旧FreeNAS) を入れたマシンをNASとして4年ほど運用しているのですが、先日ディスク1台で不良セクタが見つかったのでディスク交換を行うことにしました。

修理を行う前のNASのだいたいのスペックは下記となります。

• OS: TrueNAS-12.0-U3.1
  (FreeNAS 11.1からアップグレードし続けて運用中)
• CPU: Celeron G3930
• メモリ： 16GB
• ディスク: 3TB HDD x 6 (WD Red)
• ディスク構成: RAID-Z2 (6台すべて使用、スペアなし)

以下、自分自身の備忘録としても手順を書き残しておきます。

管理画面にログイン後、左側のメニューの「ストレージ」から「Pools」を開きます。

プールの一覧が表示されますので、交換したいディスクが含まれているプールを選び、右上の設定ボタンから「Status」を選びます。

Pool Statusが開きますので、交換したいディスク探します。
今回の例のように、すでに故障したディスクを取り外して新しいディスクに取り換えている場合は、以下の画面にあるように特定のディスクだけが「UNAVAIL」の表示になっているので見つけやすいと思います。

交換対象とするディスクの右側のメニューから「Replace」を選びます。

新しいディスクを選び、「REPLACE DISK」をクリックします。

交換が正常に完了すると、以下の画面が表示されます。

この画面は、ディスクの初期化等が完了すると表示されるため、時間はかからずに表示されます。
ですが、その後バックグラウンドでRAIDの再構築作業が行われておりますので、この画面が出たからと言って完了ではありませんので電源を入れっぱなしにしておきます。

また余談ですが、新しいディスクを選ぶ前に、先にディスクの一覧を確認しておいたほうが分かりやすく作業が行えるかもしれません。

左側メニューの「ストレージ」を開き、「ディスク」を開くとこの画面に辿り着けます。

この例では、ada2に新しいディスクを接続したため、この箇所だけ型番と容量が他のディスクと違うのがお分かりいただけるかと思います。

今回の故障をきっかけに、現在問題なく稼働しているディスクも順次入れ替えて容量を拡大することにしましたので、準備が整い次第Poolの容量拡大編も書こうと思います。

NEC IX2215でPPPoEとMAP-EによるIPv4接続を共存させてみた

外へのインターネット接続を、いい加減PPPoE方式による接続から、MAP-E方式による接続に切り替えたいと思っていたところ、思わぬ形でNECのIX2215というルーターをゲットしましたので早速やってみました。

my new gear pic.twitter.com/rHFfgT33q3

— Y.Tsurui (@tsuruiy) May 9, 2021

NECの公式の方にMAP-E方式で接続する場合の設定例もアップされているため、MAP-Eでのインターネットへの接続自体は割とあっさりと行けました。

しかし、MAP-E方式では、一つのグローバルIPアドレスのうち、一部のポートのみが割り当てられる仕様のため、ポート開放は行えないためにサーバー用途での利用は事実上厳しいので、そのあたりをクリアするためには従来のPPPoE方式も併用する必要が出てきます。
(PPPoE方式ではプロバイダにもよりますが、グローバルIPアドレスが1つ割り当てられ、自由にポート開放したりできるため)

最初は、今回買ったIX2215でMAP-E接続を行い、外界との通信は基本的にそちらに流れるようにして、一部の通信のみは今までのルーター側に流してPPPoE接続側を通るようにしようかとも考えておりましたが、IX2215の設定をあれこれ弄り回すうちに、これって両方のセッションを一台で共存させて振り分けられるのでは？と思ったので試してみました。

イメージとしては下記となります。

• GigaEthernet0 (GE0)をFlets回線へ接続
• GigaEthernet1 (GE1)は外部公開しないマシン用のネットワークとして、別のスイッチに接続
• GigaEthernet2 (GE2)をポートベースVLANで分割し、ポート1から4を外部公開するサーバー用に、ポート5から8を内部用に設定
• 外部公開するサーバーは、「10.168.0.0/24」のネットワークに設置し、このネットワーク範囲から外部へのアクセスをIPv4アクセスリストで認識し、PPPoE側へと流す。
  (interface: GigaEthernet2:1.0 / route-map: pppoe-route / access list: local-filter)
• それ以外のネットワークから外部にアクセスする場合、すべてIPoE側に流れるようにデフォルトルートを設定する。
  (デフォルトルート: Tunnel0.0)

大雑把に言うと、特定のネットワーク範囲のマシンから外部に通信する場合のみPPPoE側に流し、それ以外はすべてIPoE側に流すという動作をするように設定します。

構成例は下記となります。

ip ufs-cache max-entries 20000
ip ufs-cache enable
ip route default Tunnel0.0
ip dhcp enable

ipv6 ufs-cache max-entries 10000
ipv6 ufs-cache enable
ipv6 dhcp enable

proxy-dns ip enable
proxy-dns ip request both

ipv6 access-list block-list deny ip src any dest any
ipv6 access-list dhcpv6-list permit udp src any sport any dest any dport eq 546
ipv6 access-list dhcpv6-list permit udp src any sport any dest any dport eq 547
ipv6 access-list icmpv6-list permit icmp src any dest any
ipv6 access-list tunnel-list permit 4 src any dest any
ipv6 access-list other-list permit ip src any dest any
ipv6 access-list dynamic cache 65535
ipv6 access-list dynamic dflt-list access other-list

ip access-list reject-outgoing deny udp src any sport eq 135 dest any dport any
ip access-list reject-outgoing deny udp src any sport any dest any dport eq 135
ip access-list reject-outgoing deny tcp src any sport eq 135 dest any dport any
ip access-list reject-outgoing deny tcp src any sport any dest any dport eq 135
ip access-list reject-outgoing deny udp src any sport eq 445 dest any dport any
ip access-list reject-outgoing deny udp src any sport any dest any dport eq 445
ip access-list reject-outgoing deny tcp src any sport eq 445 dest any dport any
ip access-list reject-outgoing deny tcp src any sport any dest any dport eq 445
ip access-list reject-outgoing deny ip src any dest 10.0.0.0/8
ip access-list reject-outgoing deny ip src any dest 172.16.0.0/12
ip access-list reject-outgoing deny ip src any dest 192.168.0.0/16
ip access-list reject-outgoing permit ip src any dest any

ip access-list local-filter deny ip src any dest 10.0.0.0/8
ip access-list local-filter deny ip src any dest 172.16.0.0/12
ip access-list local-filter deny ip src any dest 192.168.0.0/16
ip access-list local-filter permit ip src any dest any

route-map pppoe-route permit 10
  match ip address access-list local-filter
  set default interface GigaEthernet0.1
  set interface GigaEthernet0.1

ip dhcp profile dhcpv4-sv
  dns-server 10.168.6.1
  

ipv6 dhcp client-profile dhcpv6-cl
  information-request
  option-request dns-servers

ipv6 dhcp server-profile dhcpv6-sv
  dns-server dhcp

ppp profile ppp_profile
  authentication myname hoge@fuga.com
  authentication password hoge@fuga.com password

interface GigaEthernet0.0
  no ip address
  ipv6 enable
  ipv6 address autoconfig receive-default
  ipv6 dhcp client dhcpv6-cl
  ipv6 filter dhcpv6-list 1 in
  ipv6 filter icmpv6-list 2 in
  ipv6 filter tunnel-list 3 in
  ipv6 filter block-list 100 in
  ipv6 filter dhcpv6-list 1 out
  ipv6 filter icmpv6-list 2 out
  ipv6 filter tunnel-list 3 out
  ipv6 filter dflt-list 100 out
  no shutdown

interface GigaEthernet0.1
  ppp binding ppp_profile
  ip address ipcp
  ip napt enable
  ip tcp adjust-mss auto
  no shutdown
  ip napt service http 10.168.0.80 none tcp 80
  ip napt service softether 10.168.0.30 none tcp 5555
  ip filter reject-outgoing 1 out

interface GigaEthernet1.0
  ip address 10.168.7.254/24
  no shutdown

device GigaEthernet2
  vlan-group 1 port 1 2 3 4
  vlan-group 2 port 5 6 7 8

interface GigaEthernet2:1.0
  ip address 10.168.0.254/24
  ip policy route-map pppoe-route
  no shutdown

interface GigaEthernet2:2.0
  ip address 10.168.6.1/24
  no shutdown

interface Tunnel0.0
  tunnel mode map-e
  ip address map-e
  ip tcp adjust-mss auto
  ip napt enable
  ip filter reject-outgoing 1 out
  no shutdown

ハマりやすいところとしては、GigaEthernet2:1.0からの通信をIPv4アクセスリストなしですべてroute-mapで処理してしまうと、外部公開するサーバーと内部のマシンがルーターを介して一切通信できなくなってしまいます。
そのため、アクセスリストでプライベートIPアドレスの範囲を検出して、route-map適用除外を行ってやる必要があります。

また、アクセスリストの最後に「ip access-list local-filter permit ip src any dest any」を書かないと、すべてのパケットがroute-map適用除外になってしまい、MAP-E側に流れてしまうのでこれまた失敗となってしまいます。

ルーター交換工事だいたい完了。
旧ルーターはお役御免になったのと同時に、跡地に去年末に買って放置してたサーバーが入居。

旧ルーター、欲しい人が居たら売りつけてしまおうか… pic.twitter.com/nOZ5smt2Bn

— Y.Tsurui (@tsuruiy) May 16, 2021

結果的にこのようになり、安定して稼働しております。

上記の設定に更に追加で、ポートベースVLANの上にタグVLANも乗っけて動くように構成してあります。

IX2105やIX2106など、ポート数が少ない機種で試す場合はインターフェース名などを適宜変更すれば動くかもしれません。

Kea DHCPv4 ServerをDocker上で動作させる

DHCPサーバーをローカルで立ち上げる場合、Linux上にISC DHCPやKea DHCPをインストールして運用することが多いかと思います。

今回はDHCPサーバーをコンテナ化してDocker上で動かし、ローカルネットワークにIPアドレスを配布できるようにします。

コンテナ化することで、使用するOSや環境ごとに微妙に異なる手順を統一して展開できたり、バックアップを取るのも設定ファイルだけで済んだり、あるいはマシンを変える場合も設定のみをtarで固めて、移行先のマシンで展開・起動するだけで済むなど、何かとメリットがあります。

今回使用するファイルはすべてgithubに置いてありますので、こちらを使用して進めていきます。

https://github.com/ytsurui/kea-dhcp4-docker-simple

前提条件

今回の記事は、下記のソフトウェアが事前にホスト上にインストールされていることを前提としています。

• docker-ce
• docker-compose

また、コマンドを実行する場合、必要に応じてsudoコマンドを併用してroot権限で行ってください。
docker、docker-composeコマンドの実行には、インストール後に権限を触ってない場合は、root権限で実行しないとエラーが出るかと思います。

動作確認は、ubuntu server 20.04 x64で取っていますが、arm版のubuntuや、CentOSなど他の環境にdockerをインストールした環境でも動くと思います。

ファイルの準備

最初に、gitコマンドで上記リポジトリの内容をすべてローカルにクローンするか、あるいは下記に示すファイルのみをテキストレベルでコピーします。

• gitコマンドを使用する場合
  

git clone https://github.com/ytsurui/kea-dhcp4-docker-simple

• ファイルをコピーする場合
• Dockerfile
• docker-compose.yaml
• conf/kea-dhcp4.conf

設定の修正

ファイルの準備ができたら、conf/kea-dhcp4.confを自身の環境に適合するように、必要に応じて書き換えます。
初期状態では、下記に示す設定となっています。

• DHCPリクエストを受け付けるネットワークインターフェイス名:
  　　ens192
• IPアドレスの配布対象とするネットワーク： 192.168.4.0/24
• プール範囲： 192.168.4.11 - 192.168.4.200
• デフォルトゲートウェイ: 192.168.4.1
• DNSサーバー: 192.168.4.1
• ドメイン名: your-domain.local

それぞれ、下図で示す箇所に対応しています。

特に明言はされていませんが、設定ファイルの書式はJSON形式になっていますので、JSONの取り扱い経験がある場合はすんなりと触れると思います。

配布対象のネットワークを増やす場合は、31行目から始まるsubnet4の配列に含まれている配布対象とするネットワーク、IPアドレス配布プール、デフォルトゲートウェイの固まりを増やしていけば幾らでも追加できます。

また、ローカルドメイン名などが不要な場合は、その項目を中括弧ごと消し込むことで配布されなくなります。

ネットワークインターフェイス名の確認

ネットワークインターフェイス名は、DHCPコンテナを動作させるホストマシンのネットワークインターフェイス名を指定します。

最近のLinux環境では、ip addr showで入れるとマシン上で使用可能なネットワークインターフェイス一覧が出てきます。

環境によって、上図のようにens192と出てきたり、eth0と出てきたりしますので、必要に応じて書き換えます。

コンテナの起動

設定の変更が完了したら、DHCPコンテナを起動します。

今回は、docker-composeを利用してお手軽にコンテナを起動していきます。

下記の順番でコマンドを実行し、DHCPコンテナイメージのビルド、DHCPコンテナの起動を行います。

docker-compose build
docker-compose up -d

正しく起動できているかは、「ss -anu」を実行し、DHCPポート(UDP 67)が待ち受けを開始しているか見ることで確認が取れます。

赤枠で囲んだ箇所のように、UDP 67番ポートが待ち受けを開始していれば起動には成功しています。

コンテナ内部で動いているkea-dhcpの動作ログを見たい場合は、「docker-compose logs」で確認できます。
エラーで起動しない場合は、何か変なメッセージが出ているかと思います。

ファイアウォールの開放

dockerホスト上にファイアウォールがインストールされている場合、UDP 67番への着信を許可する必要があります。
firewalldで構成されている場合は、下記のコマンドを実行し、ポート開放を行います。

firewall-cmd --add-port 67/udp --permanent && firewall-cmd --reload

自作ソフトのページを引越ししました

ここ2年程はほぼ放置状態でしたが、実はフリーソフトをちまちま作っては公開しておりました。

しかし、数日ほど前にあまりの放置のし過ぎでホームページスペースが閉鎖されてしまい、ダウンロードできない状態となっていることが発覚しました。
このまま公開終了でも良いかなとは思ったのですが、せっかく作り続けてきたソフトですので、新たにこのブログにページを作成して残しておくことにしました。


本ブログの右側に、自作ソフトのページというリンクを作成しましたので、当面はそちらに置いておくことにします。



どちらのソフトも最終更新は2年前ですが、そろそろWindows10が出てきたりもしているので、少しばかり時間を取って最低限認識するようにする位の対応はしようかな、と思います。

Linux (CentOS7)で、2台目以降のディスクにパーティションを作って使えるようにする

CentOS 7のインストーラで、LVMを組まないと複数ディスクに対してパーティション設定が出来なかったので、インストール後に手動でパーティションとマウントポイントを作成しました.

この説明文中では、パーティション設定を行うディスクを/dev/sdbとし、パーティションは一つのみで進めていく.

一連の作業は、下記の順番で進めていく.

1. fdiskでパーティションテーブルを作成する
2. fdiskでパーティションを作成する
3. ファイルシステムを作成する
4. マウントポイントを作成し、読み書きできるようにする

１、fdiskでパーティションテーブルを作成する

fdiskというコマンドに続いて、パーティション設定を行うディスクを続けて記述することで、fdiskを起動する.

CentOS 7をVMware環境にインストールし、VMware Toolsの代わりにopen vm toolsを使用する

以前、CentOS 7をVMware環境にインストールし、VMware Toolsをインストールするという記事を書きましたが、その後いろいろと調べていくうちに、CentOS 7ではopen-vm-toolsというパッケージをインストールすることで、VMware Toolsの代わりになるということが分かりました。

open-vm-toolsとは、Open Virtual Machine Toolsというもので、どうやらVMware Toolsのオープンソース版ということのようです。

こちらをインストールした方がお手軽ではないだろうかと思って試してみましたが、やはりとてもお手軽に導入できました。


以下のコマンドを実行し、必要に応じて仮想マシンを再起動するだけで導入が完了します。

yum install open-vm-tools

最小インストールの環境であっても、これ以外にパッケージを入力せずにインストールできました。
依存しているパッケージが、2つほど自動的に追加されましたが。

今までみたいにインストールスクリプトを走らせたり、gccの環境を整えたりする必要はありません。

動作に関しても、パワーオフボタンでのOSシャットダウンとリセットボタンでのOS再起動程度しか見ていませんが、これらに関してはきちんと動作しました。

ですので、CentOS 7環境をVMware上で動かす場合、open-vm-toolsで十分そうです.
(sourceforgeでBetaロゴが付いているのがちょっと怖いですが...)

参考:
CentOS 7をVMware環境にインストールし、VMware Toolsをインストールする
http://ytsrvlog.blogspot.jp/2014/07/centos-7vmwarevmware-tools.html

CentOS 7をVMware環境にインストールし、VMware Toolsをインストールする

CentOS 7がリリースされたので、とりあえずVMwareの仮想マシンに入れてどんなものか触ってみた。

CentOS 7ではネットワーク周りが色々と変更になっており、最小構成でインストールすると「ifconfig」などのコマンドが標準で入らなくなっており、そのままではVMware Toolsをインストールする際にエラーとなる。

そのため、CentOS 7の最小構成環境にVMware Toolsをインストールするには以下のコマンドを実行し、必要なパッケージをインストールする。

yum install gcc make kernel-headers perl net-tools

これにより、ifconfigなども含めた必要なパッケージが全てインストールされ、VMware Toolsのインストールが可能となる。
但しifconfigの出力が変わったことによるためか、ESXi Clientでは仮想マシンのIPアドレスが表示されない模様。
(上: CentOS7環境 / 下: CentOS6環境)

 

CentOS 7におけるネットワーク周りの変化はそのうち気が向いたら書きます。

CentOS 7をVMware環境にインストールし、VMware Toolsの代わりにopen vm toolsを使用する
http://ytsrvlog.blogspot.jp/2014/10/centos-7vmwarevmware-toolsopen-vm-tools.html

CentOS 6にVMware Toolsを入れる場合:
http://ytsrvlog.blogspot.jp/2013/07/centos6vmware-tools.html

CentOS 5にVMware Toolsを入れる場合:
http://ytsrvlog.blogspot.jp/2013/07/centos5vmware-tools.html

CentOSのSELinux有効/無効を切り替える方法

CentOSに搭載されている、SELinuxというLinuxのセキュリティ機能を無効にする方法をまとめてみます。
SELinuxの詳細については、探せば幾らでも情報が出てくるので割愛します。

・SELinuxを一時的に無効にする手法
 端末上で、下記コマンドを実行する。

setenforce permissive

 この方法で無効にした場合は、OSを再起動すると有効となる。
 無効の状態を維持するには、下記方法を実行する必要がある。

SoftEtherでVPNを構築した際に、ローカル側ネットワークにアクセスできなくなる問題を回避してみる (3)

前回と前々回の記事

SoftEtherでVPNを構築した際に、ローカル側ネットワークにアクセスできなくなる問題を回避してみる (1)
SoftEtherでVPNを構築した際に、ローカル側ネットワークにアクセスできなくなる問題を回避してみる (2)

までで、VPNを構築した際にローカル側ネットワークにアクセスできなくなる場合があること、およびそれの回避方法についてまで書きました。

前回の記事までで、この現象は

「VPNセッションを張った際に、DHCPによって自動的にIPアドレスやデフォルトゲートウェイの情報が割り振られることによって、VPN Server側のルータを経由して通信するように設定されてしまうこと」

が原因であると書き、それの対策にはDHCPの通信をブロックしてしまえば良いと書きました。

しかし、このような手法を取った場合、VPNクライアントはIPアドレスを手動で入力しないと通信できない状態になります。

今回は、VPNクライアント用のDHCPサーバを設置して、VPNクライアントに自動的にIPアドレスが割り当てられるように設定します。

恒久的なルーティング情報 / スタティックルートを追加する (CentOS / RedHat系、IPv4)

CentOSなどのRedHat系Linuxでルーティング情報を設定するには、routeコマンドを使用する。
routeコマンド使用例:

route add -net (宛先ネットワークアドレス) netmask (ネットマスク) gw (ルータアドレス)

route add -net (宛先ネットワークアドレス)/{プレフィックス} gw {ルータアドレス}

入力例:

route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.0.254

route add -net 192.168.1.0/24 gw 192.168.0.254

これらのうち、どちらかの形式を入力します。
Windowsのrouteコマンドと違って、プレフィックス表記が使えます。

しかし、routeコマンドで登録したスタティックルートは、マシンを再起動すると設定が消えます。

設定を消さないためには、以下の設定を行う必要があります。

SoftEtherでVPNを構築した際に、ローカル側ネットワークにアクセスできなくなる問題を回避してみる (2)

前回の記事

SoftEtherでVPNを構築した際に、ローカル側ネットワークにアクセスできなくなる問題を回避してみる (1)

において、VPNを構築した際にローカル側ネットワークにアクセスできなくなる問題が発生する場合があることについて記載しました。

この現象の原因は、VPNセッションを張った際にDHCPによって自動的にIPアドレスやデフォルトゲートウェイの情報が割り振られることによって、VPN Server側のルータを経由して通信するように設定されてしまうことが原因であると前回書きました。

つまり、VPN Server上を通過するDHCPの通信を遮断できれば、この問題は発生しないことになります。

今回は、SoftEtherの機能を用いてこの機能を実現してみます。

SoftEtherでVPNを構築した際に、ローカル側ネットワークにアクセスできなくなる問題を回避してみる (1)

SoftEtherでVPNを構築する際に、既存のローカルネットワークにブリッジするか、あるいは仮想NAT機能を用いて構築することが多いと思います。

これらの手法でVPNを構築した場合、ほとんどの場合インターネットへのパケットは必ずVPNサーバを経由して通信されることになります。
以下にインターネットにパケットを送信する際の流れ方を示します。

実のことを言いますと、インターネットだけではなく、VPN接続元のクライアントPCが属しているネットワーク以外へのアクセスがVPNサーバ経由になります。

仮想化サーバのメモリ増強

・Before

・After

16GB → 24GBに増やしました.
増強前は結構ギリギリで動いてましたが、増強後はかなり余裕ができました.
これでまた仮想マシンをどこからともなく生やせますね.

AMDのグラフィックボードにHDMI接続したモニタで、スケーリングの設定をして黒い枠を消す

AMDのグラフィックボードを用いている環境で、パソコン用のモニタをHDMI接続した際に、モニタで表示可能な最大解像度を指定しているにもかかわらず、周りに黒い枠が出来て、実際の画面が縮小表示されることがあります。
(右：縮小されてしまった画面　左：正常な画面)



この黒い枠は、スケーリングオプションを調節することで、簡単に消すことができます。

Windowsのファイル共有のユーザ権限設定あれこれ (匿名アクセスなど) (1)

Windowsでファイルサーバ的なものを構築する際、初期設定ではクライアントからアクセスする度にユーザ名とパスワードを求められる...はずです。

 

 

 

しかし、アクセスするユーザが限定されているなど、安全性が十分に確保されているような用途によっては、アクセス時にユーザ名とパスワードを求められない匿名アクセスを可能にして、サーバのアドレスを入力するだけでアクセス可能にしたいこともあると思います。

まずは、Windows共有で匿名アクセスを可能にする方法について説明します。

ESXi 5.5にe1001eドライバ (Intel 82579LMドライバ) を組み込む

メインサーバのディスクをSSDに交換したのを機会に、ESXi5.5をインストールしたが、相変わらずe1001eドライバがデフォルトで入っていなかったので、手動インストールしました.

e1001eドライバが入っていないと、intel 82579LMチップをESXiがネットワークアダプタとして認識することが出来ず、ネットワークアダプタとして使用することはできません. (パススルーなんかは可能)


結論から言うと、ESXi 5.0とかESXi 5.1と同じ方法でネット上に公開されているドライバを組み込んでやることで動かすことが出来るようになります.
コミュニティベースのツールで、e1001eドライバのパッケージを作成し、それをESXiのデータストアにアップロードした上で、ESXiのコンソールをSSHで操作してインストールしてしまうって方法です.


以下に詳細な方法を示します.

CentOS6上のnginxでphpを動作させる (nginxの設定)

高速ウェブサーバである、nginx上でPHPが動作するように環境構築を行ってみたので、その際の手順の記録。

前回までの記事
・CentOS6にnginxをインストールする手順
・CentOS6上のnginxでphpを動作させる (php-fpmインストール、設定)