What's New Qiita

20200908のLinuxに関する記事は6件です。

  • 投稿日：2020-09-08T23:50:23+09:00

CentOS 8とopenSUSE(Raspberry Pi)でIPsecゲートウェイVPN構築 - 2.StrongSwan VPN接続確認

前提と準備

Linuxサーバー構築の記事

前回はStrongSwanのソースコンパイルによるIPsec-VPN環境の構築を行いましたが、今回はVPNに実際に接続できるか確認しましょう！(˶ ･ᴗ･ )੭⚐⚑

環境

  • IPsecプログラム：StrongSwan 5.9.0(ソースコンパイル)
  • IPsec交渉受信側：Raspberry Pi 3B+ / openSUSE 15.1 Leap(aarm64)
  • IPsec交渉発信側：Hyper-V(第2世代)のx64仮想機 / CentOS 8.1(x86_64)
  • VPNに接続するクライアントとサーバーを別途用意(私はここではUbuntuとCentOSのWebサーバーを用意しました)

前提

  • OSは最小限のインストール。また、最新の状態でOSをアップデートしていること
  • ユーザーはrootでインストール(私の検証ではadminという管理者アカウントにて、そこからsudoで処理しています)
  • どのディストリビューションでも、ファイアウォールはfirewalldを使う(ディストリビューション方言のファイアウォールよりも、firewalldでディストリビューションで共通の操作をしたい)
  • CentOSについては、セキュリティはファイルシステム組み込みのSELinuxは煩雑になるため使わず(/etc/selinux/config編集後は再起動も必要)、firewalldを使うこと。
CentOS8.1
# vi /etc/selinux/config
/etc/selinux/config
SELINUX=disabled
CentOS8.1
# reboot

サーバー条件

IPアドレスとネットワーク構築図

  • IPsec交渉受信側ゲートウェイ(下の図の左、Raspberry Pi)：

    • インターネット側(eth0)：192.168.1.22
    • VPN領域側(eth1)：192.168.2.1

  • IPsec交渉発信側ゲートウェイ(下の図の右、CentOS 8.1)：

    • インターネット側(eth0)：192.168.1.18
    • VPN領域側(eth1)：192.168.5.1

  • ネットワークセグメント：

    • インターネット接続可能：192.168.1.0/24
    • Raspberry Pi(図の左の交渉受信側)セキュアセグメント：192.168.2.0/24
    • CentOS 8(図の右の交渉発信側)セキュアセグメント：192.168.5.0/24

  • VPNに接続する端末：

    • クライアント(Ubuntu 20.04)：192.168.2.2(192.168.2.0/24に属する)
    • Linux Webサーバー(CentOS 8.1)：192.168.5.2(192.168.5.0/24に属する)

  • IPsec領域関連：

    • トンネリング区間：192.168.1.22 ～ 192.168.1.18間
    • VPN連携：192.168.2.0/24 ～ 192.168.5.0/24をVPN接続 IPsecゲートウェイ以内のVPNに接続する図 ここでは、192.168.2.2のUbuntuクライアントが、192.168.5.2のLinux WebサーバーにVPN接続できるかを試します。なおVPNに接続しているサーバーとクライアントともに、VPNの範囲のみ接続して、インターネットには接続しないこととします。

パッケージを個別ダウンロードしてインストールする機能とバージョン(2020年9月時点)

  • zlib-1.2.11.tar.gz
  • strongswan-5.9.0.tar.gz

それ以外の必要なパッケージは、ディストリビューションの標準パッケージコマンド(dnfやaptなど)でインストールし、個別ダウンロードは不要です。

ダウンロードについては、公式サイトにアクセスして、そこからダウンロードしてFTPで転送するか、ダウンロードファイルのURLさえわかれば、wgetで入手することもできますが、入手方法は省略しています。

作業手順

VPNにサーバーとクライアントを接続する

VPN領域内のIPアドレス割り振り

前回ではeth1はあくまでもネットワークアダプタを追加しただけであって、まだIPアドレスは割り振られていません。openSUSE(Raspberry Pi)の場合はYaSTでeth1にIPアドレスを手動で割り振ることが簡単にできたのですが、CentOS 8.1(Hyper-Vの仮想マシン)の場合はNetworkManagerでやろうとしたら、うまくいかなかったんです( ´•̥̥̥ω•̥̥̥` )

CentOS8.1(Hyper-V/x64)
# nmcli c modify eth1 ipv4.address 192.168.5.1/24
エラー: 不明な接続 'eth1'.

細かく調べるのは今回はあきらめて/etc/sysconfig/network-scripts/の設定ファイルを、eth0のものからコピーして編集することにしました。

CentOS8.1(Hyper-V/x64)
# cd /etc/sysconfig/network-scripts/
# cp ifcfg-eth0 ifcfg-eth1
# vi ifcfg-eth1
/etc/sysconfig/network-scripts/ifcfg-eth1
TYPE="Ethernet"
PROXY_METHOD="none"
BROWSER_ONLY="no"
BOOTPROTO="none"
DEFROUTE="yes"          ← "no"に変更
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_FAILURE_FATAL="no"
IPV6_ADDR_GEN_MODE="stable-privacy"
NAME="eth0"             ← 増設したアダプタ。ここでは"eth1"に変更
UUID="daccf09e-f112-4817-8ade-016524d946d5" ← 行そのものを削除
DEVICE="eth0"           ← 増設したアダプタ。ここでは"eth1"に変更
ONBOOT="yes"
IPADDR="192.168.1.18"   ← 増設したアダプタ。ここでは"192.168.5.1"に変更
PREFIX="24"
GATEWAY="192.168.1.1"   ← 行そのものを削除
DNS1="192.168.1.1"      ← 行そのものを削除
IPV6_PRIVACY="no"
CentOS8.1(Hyper-V/x64)
# systemctl restart NetworkManager
# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether [最初からあるネットワークアダプタのMACアドレス] brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.18/24 brd 192.168.1.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 [最初からあるネットワークアダプタのIPv6アドレス] scope global dynamic noprefixroute
       valid_lft 14373sec preferred_lft 12573sec
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether [増設ネットワークアダプタのMACアドレス] brd ff:ff:ff:ff:ff:ff
    inet 192.168.5.1/24 brd 192.168.5.255 scope global noprefixroute eth1
       valid_lft forever preferred_lft forever
    inet6 [増設ネットワークアダプタのIPv6アドレス] scope link noprefixroute
       valid_lft forever preferred_lft forever

# ip route
default via 192.168.1.1 dev eth0 proto static metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.18 metric 100
192.168.5.0/24 dev eth1 proto kernel scope link src 192.168.5.1 metric 101

今回はこの地道な方法でNetworkManagerに読み込ませて、eth1にIPアドレスを設定しました。もちろんルーティングにも192.168.5.0/24も認識されました。

その一方で、ラズパイのopenSUSEはYaSTで新設のeth1に192.168.2.1を割り振るのが簡単でした！増設したアダプタにもしっかりわかりやすくついていますね！！

openSUSE15.1(RaspberryPi)
# yast
「システム」→「ネットワークの設定」
IPアドレスは192.168.2.1を設定

YaST・IPアドレス設定前

↓私が使用した増設USBネットアダプタは「AX88772B」というデバイス名なので、そこにIPアドレスを設定します。↓

YaST・IPアドレス設定後

openSUSE15.1(RaspberryPi)
# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether [最初からあるネットワークアダプタのMACアドレス] brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.22/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 [最初からあるネットワークアダプタのIPv6アドレス] scope global dynamic
       valid_lft 14373sec preferred_lft 12573sec
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether [増設ネットワークアダプタのMACアドレス] brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.1/24 brd 192.168.5.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 [増設ネットワークアダプタのIPv6アドレス] scope link
       valid_lft forever preferred_lft forever

# ip route
default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.22
192.168.2.0/24 dev eth1 proto kernel scope link src 192.168.2.1

firewalldのゾーンを割り振る

firewalldのデフォルトはゾーンが「public」なので、今まで追加編集してきたfirewall-cmdのルールは、全部publicゾーンに入っているので、publicゾーンはインターネット側のeth0に、VPN領域側のeth1はinternalゾーンを割り振ることにしました。これはHyper-V仮想マシンのCentOSと、ラズパイのopenSUSEとで同じです。

# firewall-cmd --zone=public --change-interface=eth0 --permanent
# firewall-cmd --zone=internal --change-interface=eth1 --permanent
# firewall-cmd --reload

# firewall-cmd --get-active-zones
internal
  interfaces: eth1
public
  interfaces: eth0

VPN領域内のネットワークにサーバーとクライアントをLANケーブル接続する

これは言うまでもないですね。サーバーとクライアントをLANケーブルでつないで、IPアドレスを手動で設定します(DHCPサーバーがVPN領域内にないので、手動設定するしかないです)

「サーバー条件」を参照しての通り、下の図のようなLANケーブル接続でIPアドレスを割り振っていきます。もちろん仮想マシンの場合は仮想スイッチを割り当てるだけでOKです。

  • Ubuntuクライアントをラズパイに接続(192.168.2.0/24)。IPアドレスを192.168.2.2に設定
  • Linux WebサーバーをHyper-V仮想機に接続(192.168.5.0/24)。IPアドレスを192.168.5.2に設定 IPsecゲートウェイ以内のVPNに接続する図

VPNのネットワーク接続動作確認

Pingはこの時点で通っている

IPアドレスが適切なだけでもPingは通る

VPNでのIPアドレスを適切に設定したので、まずはPingで、Ubuntuクライアント(192.168.2.2)から対向のVPN領域にあるWebサーバー(192.168.5.2)に通るか確認したら、あっさり通っていました( ´థ౪థ)

これは、Hyper-V仮想マシンのCentOS 8.1のfirewalldがnftablesを使用している関係で、nftablesの状態を調べたところだが、nftablesのフィルタルールがICMPの転送を常に許可しているようです(nftablesについてはここに詳しくは載せませんが。。。)。

だからといって、Webがその時点でVPN領域越しに見られるというわけじゃないみたいです。

この時点ではIPsec-VPN越しサーバーのwgetは不可
もちろんwgetでも「No route」となってしまっています。。。

firewalldの転送許可をするが、CentOS 8.1のnftablesの連動にハマって断念

IPsecでトンネリングしたパケットも、IPsecゲートウェイのfirewalldでまた転送許可のルールを追加しなければならないので、VPNにあるサーバーとクライアントが通信するポートを開放した。ここでは、クライアントが192.168.2.2、サーバーが192.168.5.2なので、192.168.2.0/24 → 192.168.5.0/24宛ての転送許可をルールに加えるが、firewalldの場合は--directを指定する必要がある。

Webサーバーが使うポートは、Webである80・443・8080・8443なので、当然以下のコマンドを入力すればVPN越しにIPsecゲートウェイが転送してくれるはず。

[192.168.2.0/24 → 192.168.5.0/24 HTTP 許可]
# firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD_direct 1 -s 192.168.2.0/24 -p tcp -d 192.168.5.0/24 --dport 80 -j ACCEPT
[192.168.2.0/24 → 192.168.5.0/24 HTTPS 許可]
# firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD_direct 1 -s 192.168.2.0/24 -p tcp -d 192.168.5.0/24 --dport 443 -j ACCEPT
[192.168.2.0/24 → 192.168.5.0/24 ポート8080 許可]
# firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD_direct 1 -s 192.168.2.0/24 -p tcp -d 192.168.5.0/24 --dport 8080 -j ACCEPT
[192.168.2.0/24 → 192.168.5.0/24 ポート8443 許可]
# firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD_direct 1 -s 192.168.2.0/24 -p tcp -d 192.168.5.0/24 --dport 8443 -j ACCEPT

[確認するには]
# firewall-cmd --direct --get-all-rules
ipv4 filter FORWARD_direct 1 -s 192.168.2.0/24 -p tcp -d 192.168.5.0/24 --dport 80 -j ACCEPT
ipv4 filter FORWARD_direct 1 -s 192.168.2.0/24 -p tcp -d 192.168.5.0/24 --dport 443 -j ACCEPT
ipv4 filter FORWARD_direct 1 -s 192.168.2.0/24 -p tcp -d 192.168.5.0/24 --dport 8080 -j ACCEPT
ipv4 filter FORWARD_direct 1 -s 192.168.2.0/24 -p tcp -d 192.168.5.0/24 --dport 8443 -j ACCEPT

ところが、そこで問題発生( ´•̥̥̥ω•̥̥̥` )
ラズパイ(openSUSE)ではtcpdumpをeth0・eth1の両側でパケットが通過されているのを確認したが、Hyper-V仮想マシンのCentOS 8.1では、eth0で受け取ったパケットが拒否(reject。admin prohibited filterとICMPメッセージがUbuntuクライアントに返ってしまう)されてしまい、wgetでいまだに「No route」となってしまうのだ…

もちろんfirewalldには間違いなく--directでダイレクトフィルタルールを追加した。そこで、CentOS 8.1のfirewalldがバックベースとなっているnftablesを調査してみた。

nftables関連でいろいろ参考させていただきました！( ´ •̥ ̫ •̥ ` )- ̗̀ ♡ ̖́-

おそらくfirewalld用に使用されているnftablesのテーブルは「inet firewalld」のようですが、オリジナルのnftablesのフィルタルールは「ip filter」を使っているそうです。そこで、nftablesの操作コマンドである「nft」を使って、firewall-cmdで--directオプションにて追加したダイレクトルールがどこに入っているかを調べてみました。

CentOS8.1(Hyper-V/x64)
[テーブル ip filter にある転送ルール]
# nft list chain ip filter FORWARD
table ip filter {
        chain FORWARD {
                type filter hook forward priority filter; policy accept;
                meta l4proto tcp ip saddr 192.168.2.0/24 ip daddr 192.168.5.0/24 tcp dport 80 counter packets 0 bytes 0 accept
                meta l4proto tcp ip saddr 192.168.2.0/24 ip daddr 192.168.5.0/24 tcp dport 443 counter packets 0 bytes 0 accept
                meta l4proto tcp ip saddr 192.168.2.0/24 ip daddr 192.168.5.0/24 tcp dport 8080 counter packets 0 bytes 0 accept
                meta l4proto tcp ip saddr 192.168.2.0/24 ip daddr 192.168.5.0/24 tcp dport 8443 counter packets 0 bytes 0 accept
        }
}
CentOS8.1(Hyper-V/x64)
[テーブル inet firewalld にある転送ルール。jumpで何度か入れ子になっている]
# nft list chain inet firewalld filter_FORWARD
table inet firewalld {
        chain filter_FORWARD {
                type filter hook forward priority filter + 10; policy accept;
                ct state { established, related } accept
                ct status dnat accept
                iifname "lo" accept
                ip6 daddr { ::/96, ::ffff:0.0.0.0/96, 2002::/24, 2002:a00::/24, 2002:7f00::/24, 2002:a9fe::/32, 2002:ac10::/28, 2002:c0a8::/32, 2002:e000::/19 } reject with icmpv6 type addr-unreachable
                jump filter_FORWARD_IN_ZONES_SOURCE
                jump filter_FORWARD_IN_ZONES
                jump filter_FORWARD_OUT_ZONES_SOURCE
                jump filter_FORWARD_OUT_ZONES
                ct state { invalid } drop
                reject with icmpx type admin-prohibited
        }
}
# nft list chain inet firewalld filter_FORWARD_IN_ZONES
table inet firewalld {
        chain filter_FORWARD_IN_ZONES {
                iifname "eth0" goto filter_FWDI_public
                iifname "eth1" goto filter_FWDI_internal
                goto filter_FWDI_public
        }
}
# nft list chain inet firewalld filter_FWDI_public
table inet firewalld {
        chain filter_FWDI_public {
                jump filter_FWDI_public_pre
                jump filter_FWDI_public_log
                jump filter_FWDI_public_deny
                jump filter_FWDI_public_allow
                jump filter_FWDI_public_post
                meta l4proto { icmp, ipv6-icmp } accept
        }
}
# nft list chain inet firewalld filter_FWDI_public_deny
table inet firewalld {
        chain filter_FWDI_public_deny {
        }
}
# nft list chain inet firewalld filter_FWDI_public_allow
table inet firewalld {
        chain filter_FWDI_public_allow {
        }
}

このコマンド結果から言えることというと、firewall-cmdで--directでルールを追加したにも関わらず、inet firewalldテーブルには何もそのルールが適用されず、ip filterに入ってしまう。さらに、ip filterにある転送ルールが無視されてしまい、inet firewalldのルールだけが実行されてしまい、その結果inet firewalldの転送ルールをたどったところ「reject with icmpx type admin-prohibited」のrejectルールに入ってしまうという動作をしてしまっているらしい。

優先順位は確かにip filter(0)のほうがinet firewalld(+10)より先に参照されるはずだが、なぜip filterが無視される原因がわからず、大本のルールを参照するconfigファイルすら見当たらなかった(モジュールをコンパイルしたものにあらかじめ組み込まれていて直接viで編集できない？？)。

おそらく、現時点ではnftablesのdirectインターフェースとfirewalldとは相性が悪いバグのようで、泣く泣くLinux起動時に手動でnftで、inet firewalldのテーブルに転送ルール(細かくいうと許可対象を記述するfilter_FWDI_public_allow)を追加するしかなかった。。。( ´•̥̥̥ω•̥̥̥` )

なお実行した2020/9/7時点では、nftablesのバージョンはv0.9.3、firewalldのバージョンはv0.8.0となっている。

CentOS8.1(Hyper-V/x64)
# nft add rule inet firewalld filter_FWDI_public_allow meta l4proto tcp ip saddr 192.168.2.0/24 ip daddr 192.168.5.0/24 tcp dport 80 accept
# nft add rule inet firewalld filter_FWDI_public_allow meta l4proto tcp ip saddr 192.168.2.0/24 ip daddr 192.168.5.0/24 tcp dport 443 accept
# nft add rule inet firewalld filter_FWDI_public_allow meta l4proto tcp ip saddr 192.168.2.0/24 ip daddr 192.168.5.0/24 tcp dport 8080 accept
# nft add rule inet firewalld filter_FWDI_public_allow meta l4proto tcp ip saddr 192.168.2.0/24 ip daddr 192.168.5.0/24 tcp dport 8443 accept

# nft list chain inet firewalld filter_FWDI_public_allow
table inet firewalld {
        chain filter_FWDI_public_allow {
                meta nfproto ipv4 ip saddr 192.168.2.0/24 ip daddr 192.168.5.0/24 tcp dport 80 accept
                meta nfproto ipv4 ip saddr 192.168.2.0/24 ip daddr 192.168.5.0/24 tcp dport 443 accept
                meta nfproto ipv4 ip saddr 192.168.2.0/24 ip daddr 192.168.5.0/24 tcp dport 8080 accept
                meta nfproto ipv4 ip saddr 192.168.2.0/24 ip daddr 192.168.5.0/24 tcp dport 8443 accept
        }
}

Webサーバーにアクセスできるか確認

firewalldとnftablesの相性の悪さが足を引っ張っていたが、今回のところはnftablesは手作業でファイアウォールを転送許可することにした(´-ε-｀) 無事IPsecゲートウェイの両方で転送を許可できたら、VPN越しにUbuntuクライアントからVPN内のサーバーにアクセスできるかやってみました。

サーバーアクセス成功

もう一度確認ですが、Ubuntuクライアントは192.168.2.2で、そこからIPsecトンネリングで192.168.1.0/24のネットワークセグメントを越えた対向のVPNにあるサーバー(192.168.5.2)にアクセスしている画面です。ついでにSSHで接続できるかも試しました(˶ ･ᴗ･ )੭⚐⚑

tcpdumpでも平文のパケットをESPでトンネル化している様子が見られます。

セキュリティ確認

IPsecゲートウェイをまたぐパケットは暗号化されている？？

ここがまずIPsec-VPNでのポイントだと思う。IPsecなんだから、インターネット側を通る192.168.1.0/24で暗号化されず平文でトンネリングされたら盗聴される危険性が増します；；

パケットがIPsec暗号化されている！

うんっ、暗号化されているね！！(˶ ･ᴗ･ )੭♡♡

わかりやすくHTTP(ポート80)で「QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ…」をHTTPSで暗号化させずにクライアントでサーバーからページをアクセスしてみたけど、IPsecゲートウェイ間のトンネリングでそれを拾ってみてみると、暗号化されていました！！

VPN領域内から外側にアクセスできる？？

実際に、Ubuntuクライアント(192.168.2.2)から192.168.1.0/24の外側のセグメントにアクセスできるかもチェックしてみた。

セキュア外部は接続不可
セキュア外部は接続不可

VPN領域内の端末は、192.168.1.0/24宛てはすべてVPNの入り口であるIPsecゲートウェイにパケットが送出されるので、それがIPsecゲートウェイでは許可していないからだ(192.168.2.0/24 → 192.168.5.0/24しか許可していない)。逆に許可しているとしても、192.168.2.2 → 192.168.1.0/24の端末は、Ubuntuクライアントもデフォルトゲートウェイとして、入口たるIPsecゲートウェイに送出させ、IPsecゲートウェイから目的の端末までの往路は届くが、復路は逆に受け取った192.168.1.0/24内の端末が192.168.2.0/24に返すためのルーティングを知らないため、VPN領域内のネットワークセグメントをルーティングテーブルに加えない限り、通信が成り立たないのだ。

外部からVPN領域にアクセスできてしまわないか？？

特にこれは一番気になるところだ…♆ (⃔ `꒳´* )⃕↝
でも前述のとおり、実際は192.168.1.0/24の端末がVPNへの経路を知らなければ、ルーティング上は問題ないはず

VPN外部からVPN内部にアクセスしようとすると…

192.168.1.0/24というVPN外部から、192.168.2.0/24と192.168.5.0/24の2つのVPN領域内のサーバーやクライアントに、PingやWebアクセスしようとしても、接続されることはないことを確認。

インターネットに直結する192.168.1.0/24内のフレッツ光集約などのモデムにそのようなVPN領域へのセグメントを教えなければ、基本的に外部からVPNにアクセスされることはまずない面では安全だと思う。でもVPN領域を区切るIPsecゲートウェイで、通過を許可すべきポート番号と宛先・送信元の両方をしっかりファイアウォールで制限すべきだと、私はそう思う。

まとめ

StrongSwanでRaspberry Pi(openSUSE)とHyper-V仮想マシンのCentOS 8.1で、IPsecゲートウェイの構築を行い、IPsec-VPNとしての用途を満たせるかを検証してみたけど、外部での盗聴を防止するという面では有効性は高いが、VPN領域に適当にアクセス許可しているとあとで痛い目に合うところは要注意ではないかと感じた。

できればVPNにアクセスできる外部領域の端末はIPsecゲートウェイに限定して、VPNにあるSSHも公開鍵方式であるなど、ファイアウォールとIPsecに限らず、複合的なセキュリティを選択しなければやはり限界があるのかな…とも思う

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-08T15:39:04+09:00

LinuxやMacのシェルを切り替える方法

まずは今のシェルを確認

現時点のシェルを確認するコマンド

% echo $SHELL

/bin/bash

続いて、現時点でどのシェルがインストールされているか確認

% cat /etc/shells
/bin/bash
/bin/csh
/bin/ksh
/bin/sh
/bin/tcsh
/bin/zsh

早速変更

下記コマンドを入力してください

chsh

※パスワード求められるので入力してください。

シェルを再起動します。

exec $SHELL

参考記事

https://castleobj.com/shell-change/

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-08T11:53:47+09:00

CentOS 8とopenSUSE(Raspberry Pi)でIPsecゲートウェイの簡易VPN構築 - 1.StrongSwan導入

前提と準備

Linuxサーバー構築の記事

個人でもLinuxのコマンドさえこなせば、最低7～8時間で接続やインストールができちゃいます✩°｡⋆⸜(* ॑꒳ ॑* )⸝ 1人で作業して1時間2000円かかるものとすると、だいたいかかる作業費用は16000円か…【複数台を同時に作業したほうが効率がよさそうだな…1人2～3台くらいは同時進行できそうな気がする】

IPsecゲートウェイはStrongSwanのソースコンパイルさえできれば、Raspberry Piと中古のノートPCでできるので、ぜひともネットワークを安全なVPN領域にとどめたい場合には、この構築の方法が最適かもしれないので、ぜひやってみました！(˶ ･ᴗ･ )੭⚐⚑

環境

  • IPsecプログラム：StrongSwan 5.9.0(ソースコンパイル)
  • IPsec交渉受信側：Raspberry Pi 3B+ / openSUSE 15.1 Leap(aarm64)
  • IPsec交渉発信側：Hyper-V(第2世代)のx64仮想機 / CentOS 8.1(x86_64) Raspberry Pi＋openSUSE

前提

  • OSは最小限のインストール。また、最新の状態でOSをアップデートしていること
  • ユーザーはrootでインストール(私の検証ではadminという管理者アカウントにて、そこからsudoで処理しています)
  • どのディストリビューションでも、ファイアウォールはfirewalldを使う(ディストリビューション方言のファイアウォールよりも、firewalldでディストリビューションで共通の操作をしたい)
  • CentOSについては、セキュリティはファイルシステム組み込みのSELinuxは煩雑になるため使わず(/etc/selinux/config編集後は再起動も必要)、firewalldを使うこと。
CentOS8.1
# vi /etc/selinux/config
/etc/selinux/config
SELINUX=disabled
CentOS8.1
# reboot

サーバー条件

IPアドレスとネットワーク構築図

  • IPsec交渉受信側ゲートウェイ(下の図の左、Raspberry Pi)：

    • インターネット側(eth0)：192.168.1.22
    • VPN領域側(eth1)：192.168.2.1

  • IPsec交渉発信側ゲートウェイ(下の図の右、CentOS 8.1)：

    • インターネット側(eth0)：192.168.1.18
    • VPN領域側(eth1)：192.168.5.1

  • ネットワークセグメント：

    • インターネット接続可能：192.168.1.0/24
    • Raspberry Pi(図の左の交渉受信側)セキュアセグメント：192.168.2.0/24
    • CentOS 8(図の右の交渉発信側)セキュアセグメント：192.168.5.0/24

  • IPsec領域関連：

    • トンネリング区間：192.168.1.22 ～ 192.168.1.18間
    • VPN連携：192.168.2.0/24 ～ 192.168.5.0/24をVPN接続 sswan00_IPsecGW図.png

パッケージを個別ダウンロードしてインストールする機能とバージョン(2020年9月時点)

  • zlib-1.2.11.tar.gz
  • strongswan-5.9.0.tar.gz

それ以外の必要なパッケージは、ディストリビューションの標準パッケージコマンド(dnfやaptなど)でインストールし、個別ダウンロードは不要です。

ダウンロードについては、公式サイトにアクセスして、そこからダウンロードしてFTPで転送するか、ダウンロードファイルのURLさえわかれば、wgetで入手することもできますが、入手方法は省略しています。

作業手順

準備

makeやcmake、パッケージ解凍機能のインストール

Hyper-V仮想マシンとラズパイでディストリビューションごとのインストールをします(ソースコンパイルは両方とも同じ)

CentOS8.1(Hyper-V/x64)
# dnf -y install make cmake tar bzip2
openSUSE15.1(RaspberryPi)
# zypper -n install make cmake tar bzip2

GCCとC++コンパイラのインストール

CentOS8.1(Hyper-V/x64)
# dnf -y install gcc gcc-c++
openSUSE15.1(RaspberryPi)
# zypper -n install gcc gcc-c++

zlibのソースインストール

zlibの配置場所はデフォルトのまま変えないでインストールしました。ソースコンパイルはHyper-V仮想マシンとラズパイで同じです

# cd [zlibの書庫ファイルが置いてあるディレクトリ]
# tar zxvf zlib-1.2.11.tar.gz
# cd zlib-1.2.11/
# ./configure
# make
# make install

IP転送の有効化

IPsecゲートウェイとして動作するためには、IP転送を有効化しなければならないので、有効化します。Hyper-V仮想マシンのCentOS 8.1では以下のコマンドを実行することで転送を有効化します。ラズパイのopenSUSEはYaSTで設定することができます。

CentOS8.1(Hyper-V/x64)
# cat /proc/sys/net/ipv4/ip_forward
0
# vi /etc/sysctl.d/01-ipv4fwd.conf
/etc/sysctl.d/01-ipv4fwd.conf(CentOS)
# Controls IP packet forwarding
net.ipv4.ip_forward = 1
openSUSE15.1(RaspberryPi)
# yast
[あとはYaSTの設定に従ってネットワークやセキュリティの設定から、IPv4の転送を有効化する]

VPN領域のネットワークアダプタの増設

Hyper-V仮想マシンとRaspberry Piともに、IP転送の有効化＋ネットワークアダプタを増設するため、いったん電源を切ります。私の場合は、ラズパイはUSBでVPN向けの有線LANアダプタを増設し、Hyper-Vは設定で、ネットワークアダプタを増設しました。

増設後は「eth1」が追加されているか確認しますが、もちろんIPアドレスはまだ割り振られていません。

# ip addr

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether [最初からあるネットワークアダプタのMACアドレス] brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.18/24 brd 192.168.1.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 [最初からあるネットワークアダプタのIPv6アドレス] scope global dynamic noprefixroute
       valid_lft 14373sec preferred_lft 12573sec
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether [増設ネットワークアダプタのMACアドレス] brd ff:ff:ff:ff:ff:ff
    inet6 [増設ネットワークアダプタのIPv6アドレス] scope link noprefixroute
       valid_lft forever preferred_lft forever

# ip route

default via 192.168.1.1 dev eth0 proto static metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.18 metric 100

CentOSの場合は、コマンドでIP転送の有効化を操作しているので、有効(ip_forwardが1)になっているか確認をします。

CentOS8.1(Hyper-V/x64)
# cat /proc/sys/net/ipv4/ip_forward
1

# sysctl --system
…(中略)
* Applying /etc/sysctl.d/01-ipv4fwd.conf ...
net.ipv4.ip_forward = 1
…(中略)

StrongSwanをコンパイルするために必要なパッケージをディストリビューション標準パッケージコマンドでインストール

注意：面倒くさくても実行しないと、パッケージがない、とエラーが出てコンパイルが中止されるんです(´•ω•̥`)

CentOS8.1(Hyper-V/x64)
# dnf -y install gmp-devel openssl-devel
openSUSE15.1(RaspberryPi)
# zypper -n install gmp-devel libopenssl-devel

StrongSwan 5.9.0のソースコンパイルのインストール

Hyper-V仮想機とラズパイ共通です。この作業は結構時間がかかりました(特にRaspberry Piだと、20～30分かかりました)

configureとmake

# cd [strongswan-5.9.0.tar.gzが置いてあるディレクトリ]
# tar xvzf strongswan-5.9.0.tar.gz
# cd strongswan-5.9.0/
# ./configure --prefix=/usr --sysconfdir=/etc --enable-openssl
# make
# make install

エラーなくコンパイルできれば、インストールは完了です♪(*˘︶˘*).｡.:*♡

StrongSwanの環境設定

ソースコンパイルでStrongSwanをインストールすると、設定ファイルは/etc/ipsec.confに格納されるので、その中にIPsecの接続設定を行います。

[Apacheの基本設定]
# vi /etc/ipsec.conf

IPsecを確立する側(確立を発信する方)、そう、まずはHyper-VのCentOS 8.1の設定を行います。「サーバー条件」の項にある通り、Hyper-Vマシン側からは、自分のIPアドレスが192.168.1.18、確立相手のRaspberry Piが192.168.1.22になるので、その対を設定ファイルに書き込みます。

「left」は確立を交渉発信する自分を、「right」は確立相手の情報を書き込むとのことです(StrongSwan公式のマニュアルから)

CentOS8.1(Hyper-V/x64)
…
# 以下を追記する
conn [識別名 例：linux-2-linux]
      authby=secret
      auto=start                # IPsec交渉を発信する
      closeaction=restart
      dpdaction=restart
      left=192.168.1.18         # leftは自分側のIPsecゲートウェイ
      leftid=192.168.1.18       # IPsec交渉するのに自分を識別するID
      leftsubnet=192.168.5.0/24
      right=192.168.1.22        # rightは相手側のIPsecゲートウェイ
      rightid=192.168.1.22      # IPsec交渉相手を識別するID
      rightsubnet=192.168.2.0/24
…

ちなみにIDは、私の場合は簡単のためIPアドレスを使用しましたが、文字列でもOKです。そんでleftsubnetとrightsubnetというのは、自分側と相手側の受け持つVPN領域なので、leftsubnetは自分の持っているVPN領域なので192.168.5.0/24を、rightsubnetは相手のラズパイのVPN領域なので192.168.2.0/24を入れました。

続いて、ラズパイのopenSUSEの設定も行います。「サーバー条件」の項にある通り、確立を受ける自分のIPアドレスが192.168.1.22、確立してくる相手側のHyper-V CentOS 8が192.168.1.18になるので、Hyper-V(CentOS8)とは逆の内容を設定ファイルに書き込みます。

openSUSE15.1(RaspberryPi)
# 以下を追記する
conn [識別名 例：linux-2-linux]
      authby=secret
      auto=add              # IPsec交渉を受信する
      closeaction=clear
      dpdaction=clear
      left=192.168.1.22
      leftid=192.168.1.22
      leftsubnet=192.168.2.0/24
      right=192.168.1.18
      rightid=192.168.1.18
      rightsubnet=192.168.5.0/24

要は、auto=addとすることで、IPsec確立交渉を受信する側に設定し、leftの内容とrightの内容を真逆にするというところだね。そうすれば、識別名(connの後ろの文字列)が一致すれば、IPsecの接続を確立できる、ということ

StrongSwanのデフォルトでは、PSK方式で、標準でAES/SHA暗号方式を採用しています。それ以外の暗号方式を設定する必要がある場合はまた別途設定するが、ここでは省略。

余談ですが、この時点でのStrongSwanはNAT-Tに対応していて、IPsecをNATに適用させることもできる(かつてはIPsecをNATに適用することができなかった)ので、インターネットでNATが使われている空間でさえも、StrongSwanで構築されたVPNをインターネット越しに通信できるそうです(実験したことはありませんが…)

[StrongSwanの鍵の設定]
# vi /etc/ipsec.secrets
/etc/ipsec.secrets
…
: PSK "[適当な文字列：例…kazumi75kitty]"
…

デフォルトのPSK方式を使っているので、Hyper-V仮想マシンとラズパイともに同じにします。

StrongSwanの起動

サービスの起動スクリプト作成＆有効化

StrongSwanに必要な環境設定がそろったので、起動できるようにしたいと思います。起動スクリプトはSystemdなので、/etc/systemd/systemに作成します

# cd /etc/systemd/system
# vi strongswan.service
strongswan.service
[Unit]
Description=strongSwan

[Service]
Type=forking
ExecStart=/usr/sbin/ipsec start
ExecStop=/usr/sbin/ipsec stop

[Install]
WantedBy=multi-user.target

ここではSystemdのスクリプトは詳しく説明しませんが、起動と停止は親プロセスからはバックグランドで実行されるため、strongSwanでは[Service]のTypeはforkingとなっています。

firewalldの設定

続いて、firewalldの設定で、IPsecを受け付けます(IPsecでやりとりされる暗号化データそのものと、IPsecの交渉が受け付けることができる)。ただしここでの設定だと、トンネリングをかます192.168.1.0/24内部限定を明記していなく、ほかのネットワークセグメントからもIPsecのパケットが通行可能であれば受信できてしまいます。しかしここまで対策すると煩雑になるので今回は簡単のためIPsecの許可のみとします。

# firewall-cmd --permanent --add-service=ipsec
# firewall-cmd --reload

# firewall-cmd --list-all

public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources:
  services: cockpit dhcpv6-client ipsec
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
        rule family="ipv4" source address="192.168.1.0/24" port port="12345" protocol="tcp" accept

Hyper-V仮想マシンとラズパイの両方で共通のコマンドです。

起動と動作確認

それでは、起動します。enableでの常時起動有効化＆statusで「Active」「Running」になっていることを確認。

まずはIPsec確立交渉を受信する側からStrongSwanを起動したのちに、IPsec確立を発信する側の順に起動させています。ここではラズパイのStrongSwanを起動後に、Hyper-V仮想マシンのStrongSwanを起動させています。

# systemctl start strongswan
# systemctl enable strongswan
# systemctl status strongswan

起動成功

Hyper-V仮想マシンとラズパイで「Active」「Running」になっていることを確認し、いよいよIPsecトンネリングが確立されているかをチェック。

CentOS8.1(Hyper-V/x64)
# /usr/sbin/ipsec status
Security Associations (1 up, 0 connecting):
linux-2-linux[1]: ESTABLISHED 2 minutes ago, 192.168.1.18[192.168.1.18]...192.168.1.22[192.168.1.22]
linux-2-linux{1}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: ********_i ********_o
linux-2-linux{1}:   192.168.5.0/24 === 192.168.2.0/24

# ip xfrm policy
src 192.168.5.0/24 dst 192.168.2.0/24
        dir out priority 375423 ptype main
        tmpl src 192.168.1.18 dst 192.168.1.22
                proto esp spi 0x******** reqid 1 mode tunnel
src 192.168.2.0/24 dst 192.168.5.0/24
        dir fwd priority 375423 ptype main
        tmpl src 192.168.1.22 dst 192.168.1.18
                proto esp reqid 1 mode tunnel
src 192.168.2.0/24 dst 192.168.5.0/24
        dir in priority 375423 ptype main
        tmpl src 192.168.1.22 dst 192.168.1.18
                proto esp reqid 1 mode tunnel
openSUSE15.1(RaspberryPi)
# /usr/sbin/ipsec status
Security Associations (1 up, 0 connecting):
linux-2-linux[1]: ESTABLISHED 2 minutes ago, 192.168.1.22[192.168.1.22]...192.168.1.18[192.168.1.18]
linux-2-linux{1}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: ********_i ********_o
linux-2-linux{1}:   192.168.2.0/24 === 192.168.5.0/24

# ip xfrm policy
src 192.168.2.0/24 dst 192.168.5.0/24
        dir out priority 375423 ptype main
        tmpl src 192.168.1.22 dst 192.168.1.18
                proto esp spi 0x******** reqid 1 mode tunnel
src 192.168.5.0/24 dst 192.168.2.0/24
        dir fwd priority 375423 ptype main
        tmpl src 192.168.1.18 dst 192.168.1.22
                proto esp reqid 1 mode tunnel
src 192.168.5.0/24 dst 192.168.2.0/24
        dir in priority 375423 ptype main
        tmpl src 192.168.1.18 dst 192.168.1.22
                proto esp reqid 1 mode tunnel

IPsecトンネリングが、Hyper-V仮想マシンとラズパイでちゃんと確立されてました(˶ ･ᴗ･ )੭⚐⚑

おまけ(ipsec.confのIDにドメインなど文字列を指定)

StrongSwanの設定ファイル/etc/ipsec.confで、leftidやrightidで、IPアドレスではなく文字列を使った場合もキャプチャ画面を載せておきます(*´꒳`*)

たぶんこっちのほうがわかりやすいかもしれません。
例では「raspberrypi」と「testonly@kazumi-jam」を識別させています
ipsec.confのIDに文字列やドメインを指定する

補足(IPsecトンネリングがNATを経由する場合)

わかりやすい画像はまだないけど、ipsec.confでのleftとrightのIPアドレスは、それぞれ自分自身のIPアドレスと、自分から見たNAT変換後の相手のIPアドレスを入れます。その際、leftidとrightidは、必ず自分と相手で対に一致していることが必要になります。

例：
192.168.1.0/24 → 192.168.120.0/28 がNATで仕切られている場合

IPsecGW-1(192.168.1.0/24内)
　left=192.168.1.22
　leftid="gw1"
　right=192.168.1.18
　rightid="gw2"
IPsecGW-2(192.168.120.0/28内)
　left=192.168.120.1
　leftid="gw2"
　right=192.168.120.3
　rightid="gw1"

という風に、IPアドレスはNATを考慮したものを入れることでIPsecが確立できるけど、詳しくはまた後で載せてみます。

次回

一通りのStrongSwan導入で、Raspberry PiとHyper-V上のCentOS 8.1で、IPsecゲートウェイの構築が完了しました。次はそのIPsecゲートウェイにつながったVPNにクライアントとサーバーを接続して、互いに接続できるかを試します( ˶˙ᵕ˙˶ )

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-08T10:11:27+09:00

Linuxサーバーコマンド

Linuxサーバーコマンド

実行環境：Centos7 on Virtualbox , ユーザ名 vagrant

topコマンド: CPU、メモリ、プロセスを表示する
top - 09:48:52 up 2 min,  1 user,  load average: 0.18, 0.14, 0.06
Tasks: 109 total,   2 running, 107 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.2 sy,  0.0 ni, 99.7 id,  0.0 wa,  0.0 hi,  0.2 si,  0.0 st
KiB Mem :   468520 total,   253376 free,    89544 used,   125600 buff/cache
KiB Swap:  1040380 total,  1040380 free,        0 used.   297560 avail Mem


PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
  353 root      20   0       0      0      0 S   0.3  0.0   0:00.07 xfsaild/dm-0
 1255 vagrant   20   0  139184   2108    912 S   0.3  0.4   0:00.23 sshd
    1 root      20   0   41272   3704   2428 S   0.0  0.8   0:01.25 systemd
    2 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kthreadd
    3 root      20   0       0      0      0 S   0.0  0.0   0:00.02 ksoftirqd/0
    4 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kworker/0:0
    5 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:0H
    6 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kworker/u4:0
    7 root      rt   0       0      0      0 S   0.0  0.0   0:00.50 migration/0
    8 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcu_bh
    9 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcuob/0
   10 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcuob/1
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-08T01:57:41+09:00

Centos8 + Universal Media Server で家庭内音楽サーバを作成

構成

  • [サーバ] Centos8 + Universal Media Server (UMS)
  • [クライアント]
    • 古い Android 携帯 + foobar2000 mobile + 古いミニコンポ (音楽を聴く)
    • iPhone + foobar2000 mobile (音楽を聴く)
    • DLNA対応テレビ (REGZA) (動画を見る)

仮想マシン作成

$ sudo dnf install virt-manager
$ systemctl is-enabled libvirtd
enabled

gui で仮想マシンマネージャー起動
新しい仮想マシンを作成

ローカルのインストールメディア(ISOイメージまたはCDーROMドライブ)
-> こちら1からダウンロードしたisoイメージ選択 (CentOS-8.2.2004-x86_64-dvd1.iso)

  • Memory: 2048
  • CPU: 2
  • 仮想マシン用にディスクイメージを作成する -> 必要な容量を指定
  • ネットワークの選択
    • ホストデバイス xxxxxx (enp6s0 など) : macvtap
    • ソースモード: Bridge
  • インストール先
    • 手動パーティション設定
      • swap : 2 GiB
      • /boot : 1024 MiB
      • / : のこり全部
  • ネットワーク設定
    • Ethernet: オン
    • IPv4設定
      • メソッド: 手動
      • 固定IPを指定 ex)192.168.xxx.xxx

仮想マシンに UMS インストール

dependencies インストール 2 

$ sudo dnf install epel-release
$ sudo dnf install java-1.8.0-openjdk

mediainfo 入れるには PowerTools レポジトリ有効化必要

$ dnf repolist all
repo id                        repo の名前                                状態
AppStream                      CentOS-8 - AppStream                       有効化
AppStream-source               CentOS-8 - AppStream Sources               無効化
BaseOS                         CentOS-8 - Base                            有効化
....
PowerTools                     CentOS-8 - PowerTools                      無効化
....

$ sudo vi /etc/yum.repos.d/CentOS-PowerTools.repo
CentOS-PowerTools.repo
....
#enabled=0
enabled=1
....

$ dnf repolist all
repo id                        repo の名前                                状態
AppStream                      CentOS-8 - AppStream                       有効化
AppStream-source               CentOS-8 - AppStream Sources               無効化
BaseOS                         CentOS-8 - Base                            有効化
....
PowerTools                     CentOS-8 - PowerTools                      有効化
....

$ sudo dnf install mediainfo

オプションの DCRaw, VLC, tsMuXeR, P7Zip は内容もわからないので保留。なにか問題が起きたら考える。

UMS インストール3

公式サイト Universal Media Serverから UMS をダウンロード

展開、/optに配置

$ tar -zxvf UMS-9.8.0-x86_64.tgz ums-9.8.0/
$ sudo mv ums-9.8.0/ /opt/

シンボリックリンク

$ sudo ln -s /opt/ums-9.8.0/ /opt/ums

/etc/ums を作成してconfigファイルをコピー

$ sudo mkdir /etc/ums
$ sudo cp /opt/ums/UMS.conf /opt/ums/WEB.conf /etc/ums

ユーザ作成、ファイル所有者変更

$ sudo useradd -s /sbin/nologin ums
$ sudo chown -R ums:ums /opt/ums-9.8.0/
$ sudo chown -R ums:ums /etc/ums/

shared folder 作成

$ sudo mkdir /home/ums/Music
$ sudo mkdir /home/ums/Videos
$ sudo mkdir /home/ums/Picture

サービス登録用ファイル

$ sudo vi /etc/systemd/system/ums.service
ums.service
[Unit]
Description=Universal Media Server

[Service]
Type=simple
Environment="UMS_PROFILE=/etc/ums/UMS.conf"
User=ums
Group=ums
ExecStart=/bin/bash /opt/ums/UMS.sh

[Install]
WantedBy=multi-user.target

configファイル編集

$ sudo vi /etc/ums/UMS.conf
UMS.conf
# (4行だけ編集)
....
# (クライアントに表示する名前)
server_name = xxx xxx xxx  
....
minimized = true
....
# インタフェース名。enp1s0 など
network_interface = xxxxxx  
....
# 公開するフォルダ
folders = /home/ums/Music, /home/ums/Pictures, /home/ums/Videos  
....

サービス起動、登録

$ sudo systemctl start ums
$ sudo systemctl enable ums

ファイアウォールにサービスを登録。使う port は 5001, 9001。

$ sudo vi /usr/lib/firewalld/services/ums.xml
ums.xml
<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>UMS</short>
  <description>Universal Media Server</description>
  <port protocol="tcp" port="5001"/>
  <port protocol="tcp" port="9001"/>
</service>

$ sudo firewall-cmd --add-service=ums --zone=public --permanent
$ sudo firewall-cmd --reload

使いたいクライアント用の config ファイルを用意

foobar2000 mobile 用の config ファイル

/opt/ums/renderers/ の中の適当なファイルをコピーして foobar2000_mobile.conf をつくる
細かいところは適当。問題が起きたら考える。

$ sudo cp /opt/ums/renderers/xxx.conf /opt/ums/renderers/foobar2000_mobile.conf
$ sudo vi /opt/ums/renderers/foobar2000_mobile.conf
foobar2000_mobile.conf
#----------------------------------------------------------------------------
# Profile for foobar2000 mobile.
# See DefaultRenderer.conf for descriptions of all the available options.
#

RendererName = foobar2000-mobile 
# Use the built-in factory icon
RendererIcon =

# ============================================================================
# This renderer has sent the following string/s:
#
# User-Agent: foobar2000-mobile/1.x
# ============================================================================
#

UserAgentSearch = foobar2000-mobile
UpnpDetailsSearch = foobar2000-mobile

Video = false
Audio = true
Image = false

#DefaultVBVBufSize = true
#H264Level41Limited = false
MediaInfo = true
#MuxDTSToMpeg = true
TranscodeAudio = WAV
#TranscodeFastStart = true

# Supported audio formats:
Supported = f:aiff                      m:audio/aiff
Supported = f:flac                      m:audio/flac
Supported = f:m4a|3ga   a:alac          m:audio/x-m4a
Supported = f:m4a|3ga   a:aac-lc|he-aac m:audio/x-m4a
Supported = f:m4a|mp4                   m:audio/mp4
Supported = f:mpc                       m:audio/x-musepack
Supported = f:mp3                       m:audio/mpeg
Supported = f:opus                      m:audio/opus
Supported = f:wav                       m:audio/wav
Supported = f:wavpack                   m:audio/x-wavpack
#Supported = f:adts      a:aac-lc|he-aac m:audio/aac

$ sudo chown ums:ums /opt/ums/renderers/foobar2000_mobile.conf

regza 用configファイル

https://sourceforge.net/projects/pmsforregza/files/Config/for%20UMS/
から REGZA.conf をダウンロードして renderers に配置

$ sudo mv Downloads/REGZA.conf /opt/ums/renderers/
$ sudo chown -R ums:ums /opt/ums/renderers/

  1. The CentOS Project ↩

  2. Linux install instructions · UniversalMediaServer/UniversalMediaServer Wiki · GitHub ↩

  3. Centos7 Universal Media Server インストール – XEN blog ↩

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-08T00:08:40+09:00

OpenWRT(LEDE)使いこなし : NASとしてsamba共有するまで

はじめに

OpenWRT/LEDEはワイヤレスルーター向けのLinuxディストリビューションですが、
NASとして運用する場合のTipsとして、
samba設定について情報を残しておきます。

尚、中華NASキットBS-U35WFにOpenWRT/LEDEをインストールするまでのTipsは以下です。

参考 :

samba install

基本的にほげぴよさんのwikiの通りです。
違いと言えば、Webインターフェース luci-app の日本語版を入れたくらいです。

root@LEDE:~# opkg list | grep samba
luci-app-samba - git-19.271.72080-7b230b0-1 - Network Shares - Samba SMB/CIFS module
・・・
luci-i18n-samba-ja - git-19.271.72080-7b230b0-1 - Translation for luci-app-samba - 日本語 (Japanese)
・・・
samba36-client - 3.6.25-8 - Samba 3.6 SMB/CIFS client
samba36-server - 3.6.25-8 - The Samba software suite is a collection of programs that implements the SMB protocol for UNIX systems, allowing you to serve files and printers to Windows, NT, OS/2 and DOS clients. This protocol is sometimes also referred to as the LanManager or Netbios protocol.


root@LEDE:~# opkg install samba36-server luci-app-samba luci-i18n-samba-ja

home作成

openWRT/LEDEは、標準では /home すら作られていない為、作成します。

root@LEDE:/# cd /mnt/sda1
root@LEDE:/mnt/sda1# mkdir home
root@LEDE:/# ln -s /mnt/sda1/home/ /home

上手くsambaへ繋がらない場合

私の場合、sambaが正しく起動しても、外部から上手く接続できませんでした。
結論としては、/etc/samba/smb.conf ではなく、
/etc/samba/smb.conf.template を修正する必要があります。

/etc/samba/smb.conf.template
root@LEDE:~# vi /etc/samba/smb.conf.template
      interfaces = |INTERFACES|
↓
#      interfaces = |INTERFACES|
    bind interfaces only = no

ゲストアカウント追加

家庭内NAS運用の場合、家族の共有ディレクトリを運用する場合等は、ゲストアカウントで運用します。

/etc/samba/smb.conf.template
    guest account = nobody

シンボリックリンク対策

公開ディレクトリからシンボリックリンクを辿りたい場合は、
以下の設定が必要です。

/etc/samba/smb.conf.template
    unix extensions = no
    wide links = yes

luci-appからの設定

ここまでの/etc/samba/smb.conf.templateに対する設定は、
GUIのluci-app経由からも設定出来ます。
image.png

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧