Skip to content

Instantly share code, notes, and snippets.

@private-yusuke

private-yusuke/qvf.md

Created March 5, 2023 09:27
Show Gist options
  • Save private-yusuke/8121662d08758646cebd27b9e271d1c0 to your computer and use it in GitHub Desktop.
Save private-yusuke/8121662d08758646cebd27b9e271d1c0 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
qvf.md

お世話になっております。 チーム word-unknown-tsukuba-otaku です。

ユーザー alice で ssh および su でのログインができない問題について調査いたしました。

まず、サーバー 192.168.13.1 にて /etc/passwd にレコードが入っているユーザー user では正常に ssh でログインすることができました。このときの /var/log/auth.log を見てみると、以下のように pam_unix による認証のハンドリングが発生していることがわかります。

Mar  4 10:33:56 ldap-server sshd[1021]: Accepted publickey for user from 192.168.255.254 port 36332 ssh2: ED25519 [REDACTED]
Mar  4 10:33:56 ldap-server sshd[1021]: pam_unix(sshd:session): session opened for user user(uid=1002) by (uid=0)
Mar  4 10:33:56 ldap-server systemd-logind[421]: New session 45 of user user.
Mar  4 10:33:56 ldap-server systemd: pam_unix(systemd-user:session): session opened for user user(uid=1002) by (uid=0)

一方、同様にユーザー alice で ssh をしようとすると、以下のようなログが流れていることを確認しました。

Mar  4 10:49:33 ldap-server sshd[1628]: Invalid user alice from 127.0.0.1 port 40304
Mar  4 10:49:34 ldap-server sshd[1628]: pam_unix(sshd:auth): check pass; user unknown
Mar  4 10:49:34 ldap-server sshd[1628]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=127.0.0.1
Mar  4 10:49:34 ldap-server sshd[1628]: pam_ldap: could not open secret file /etc/ldap.secret (No such file or directory)
Mar  4 10:49:34 ldap-server sshd[1628]: pam_ldap: error trying to bind as user "uid=Alice,ou=people,dc=ictsc,dc=net" (Invalid credentials)
Mar  4 10:49:36 ldap-server sshd[1628]: Failed password for invalid user alice from 127.0.0.1 port 40304 ssh2
Mar  4 10:49:47 ldap-server sudo:     user : TTY=pts/1 ; PWD=/home/user ; USER=root ; COMMAND=/usr/bin/tail -f /var/log/auth.log
Mar  4 10:49:47 ldap-server sudo: pam_unix(sudo:session): session opened for user root(uid=0) by user(uid=1002)
Mar  4 10:49:50 ldap-server sshd[1628]: Failed password for invalid user alice from 127.0.0.1 port 40304 ssh2
Mar  4 10:49:53 ldap-server sshd[1628]: pam_unix(sshd:auth): check pass; user unknown
Mar  4 10:49:53 ldap-server sshd[1628]: pam_ldap: error trying to bind as user "uid=Alice,ou=people,dc=ictsc,dc=net" (Invalid credentials)
Mar  4 10:49:55 ldap-server sshd[1628]: Failed password for invalid user alice from 127.0.0.1 port 40304 ssh2
Mar  4 10:49:57 ldap-server sshd[1628]: Connection closed by invalid user alice 127.0.0.1 port 40304 [preauth]
Mar  4 10:49:57 ldap-server sshd[1628]: PAM 1 more authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=127.0.0.1

このことから、ユーザー認証時にまず pam_unix で認証を試みて、それが失敗した際に pam_ldap を利用するところまでの設定はできているようですが、pam_ldap と LDAP サーバーの繋ぎ込みが正常にできていないものと推察されます。

ここで、認証時に認証情報を得るソースを指定するための設定ファイル /etc/nsswitch.conf を見てみると、passwd や group, shadow, gshadow の箇所では files systemd または files のみだけが指定されていました。 LDAP での認証を行うためにはここに ldap と追記する必要があります。

具体的には、以下のような差分が生じるように変更を加えます。

--- nsswitch.conf.bak   2023-03-04 11:00:16.966357758 +0900
+++ nsswitch.conf       2023-03-04 10:58:26.041750866 +0900
@@ -4,10 +4,10 @@
 # If you have the `glibc-doc-reference' and `info' packages installed, try:
 # `info libc "Name Service Switch"' for information about this file.

-passwd:         files systemd
-group:          files systemd
-shadow:         files
-gshadow:        files
+passwd:         files systemd ldap
+group:          files systemd ldap
+shadow:         files ldap
+gshadow:        files ldap

 hosts:          files dns myhostname
 networks:       files

このようにすると、ssh alice@localhost コマンドでパスワード alice を入力した際に LDAP サーバーを利用した認証が正常に完了し、ログインができてシェルへのアクセスを得ることができるようになりました。

よろしくお願いいたします。

Raw
rct.md

お世話になっております。 チーム word-unknown-tsukuba-otaku です。

サーバー bastion で curl -H 'Host:blog.example.jp' 192.168.255.9 を実行した際に応答がない問題、およびそれに付随する nginx とブログの設定に関する問題について調査いたしました。

まず、サーバー host01 で nginx.service の状態を確認したところ、以下のようなエラーが発生して異常終了していることがわかりました。

$ user@blog-server:~$ sudo systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Sat 2023-03-04 04:55:46 JST; 6h ago
       Docs: man:nginx(8)
    Process: 297 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=1/FAILURE)

Mar 04 04:55:46 blog-server systemd[1]: Starting A high performance web server and a reverse proxy server...
Mar 04 04:55:46 blog-server nginx[297]: nginx: [emerg] open() "/etc/nginx/sites-enabled/blog.example.jp" failed (40: Too many levels of symbolic links) in /etc/nginx/nginx.conf:62
Mar 04 04:55:46 blog-server nginx[297]: nginx: configuration file /etc/nginx/nginx.conf test failed
Mar 04 04:55:46 blog-server systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Mar 04 04:55:46 blog-server systemd[1]: nginx.service: Failed with result 'exit-code'.
Mar 04 04:55:46 blog-server systemd[1]: Failed to start A high performance web server and a reverse proxy server.

この出力から、/etc/nginx/nginx.conf から参照しているファイル /etc/nginx/sites-enabled/blog.example.jp を読み込もうとした際、シンボリックリンクを辿る深さの上限に到達したことによってエラーが発生したことがわかりました。そのため、当該ファイルはシンボリックリンクであると考え、その実体はどこにあるのかを以下のように確認いたしました。

$ user@blog-server:/etc/nginx$ ls -lah sites-enabled/
total 8.0K
drwxr-xr-x 2 root root 4.0K Feb 14 03:46 .
drwxr-xr-x 8 root root 4.0K Feb 14 01:49 ..
lrwxrwxrwx 1 root root   17 Feb 14 03:46 blog.example.jp -> ./blog.example.jp
lrwxrwxrwx 1 root root   34 Feb 14 01:49 default -> /etc/nginx/sites-available/default

/etc/nginx/sites-enabled/blog.example.jp にあるシンボリックリンクは自分自身を指してしまっており、このリンクを解決しようとした結果、nginx.service のログに 40: Too many levels of symbolic links が出力されたことがわかりました。

おそらく、本来は /etc/nginx/sites-available/blog.example.jp -> /etc/nginx/sites-enabled/blog.example.jp のようなシンボリックリンクを貼りたかったのだと推察されます。この作業を行い、nginx.service のリロードを実施したところ、正常に nginx が起動するようになりました。作業過程は以下の通りです。

user@blog-server:/etc/nginx$ sudo unlink /etc/nginx/sites-enabled/blog.example.jp
user@blog-server:/etc/nginx$ sudo ln -s /etc/nginx/sites-available/blog.example.jp /etc/nginx/sites-enabled/blog.example.jp
user@blog-server:/etc/nginx$ sudo systemctl restart nginx.service
user@blog-server:/etc/nginx$ sudo systemctl status nginx.service
● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2023-03-04 11:36:05 JST; 5s ago
       Docs: man:nginx(8)
    Process: 1235 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
    Process: 1246 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
   Main PID: 1247 (nginx)
      Tasks: 2 (limit: 1111)
     Memory: 2.7M
     CGroup: /system.slice/nginx.service
             ├─1247 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
             └─1248 nginx: worker process

Mar 04 11:36:05 blog-server systemd[1]: Starting A high performance web server and a reverse proxy server...
Mar 04 11:36:05 blog-server systemd[1]: Started A high performance web server and a reverse proxy server.

さて、この段階でサーバー bastion からサーバー host01 への curl コマンドでの HTTP リクエストはレスポンスが帰ってくるようになりましたが、HTTP status code は 502 Bad Gateway となっていました。これは、nginx がリバースプロキシとして動作する際、nginx からブログへのリクエストが正常にできなかったようであることが推察されます。

/etc/nginx/sites-available/blog.example.jp の内容の一部には proxy_pass http://localhost:8080; という記述があることから、nginx は localhost すなわち 127.0.0.1 というループバックアドレスに対して HTTP リクエストを送信しようとしていることがわかります。

一方、blog.service では ExecStart で npm run start -- --port 8080 --host 192.168.255.9 を指定しています。そのため、ブログでは 192.168.255.9 に対するアクセスを待ち受けますが、127.0.0.1 に対するアクセスは受け取らないようになっています。したがって、nginx でアクセスする先の IP アドレスと、ブログで listen するホストの IP アドレスを一緒にする必要があります。ここでは、外部から 192.168.255.9:8080 でブログにアクセスできるよりは curl -H 'Host:blog.example.jp' 192.168.255.9 だけでアクセスできるようになっていた方が良いだろう、と作業者が考えたため、blog.service に以下のような変更を加えました。

--- blog.service.bak    2023-03-04 11:56:49.220707906 +0900
+++ blog.service        2023-03-04 11:56:32.776689816 +0900
@@ -5,7 +5,7 @@
 [Service]
 Type=simple
 WorkingDirectory=/home/user/ictsc-blog
-ExecStart=npm run start -- --port 8080 --host 192.168.255.9
+ExecStart=npm run start -- --port 8080 --host localhost
 ExecStop=/bin/kill -WINCH ${MAINPID}
 Restart=always

その後、以下のような操作を実施し、ブログの設定内容の変更を反映しました。

user@blog-server:/etc/systemd/system$ sudo systemctl daemon-reload
user@blog-server:/etc/systemd/system$ sudo systemctl restart blog

この状態で、サーバー bastion から curl -H 'Host:blog.example.jp' 192.168.255.9 を実行すると、HTTP status code 200 のレスポンスが帰ってきて、正常にブログにアクセスできるようになりました。

また、サーバー host01 にて sudo reboot を実行し、サーバーの再起動を実施した後でも同様にブログにアクセスできることを確認いたしました。

よろしくお願いいたします。

Raw
sjq.md

お世話になっております。 チーム word-unknown-tsukuba-otaku です。

AS65001 の BGP ルーター bgp-rt-01（192.168.17.1）から AS65002 の BGP ルーター 192.168.17.2 のピアリングの実施および bgp-rt-01 の FIB への経路情報の登録を完了いたしましたので、その作業について報告いたします。

まず、BGP のピアリングの設定をする前に、対向の BGP ルーター 192.168.17.2 との疎通が取れていることを確認しました。

user@bgprt01:~$ ping 192.168.17.2
PING 192.168.17.2 (192.168.17.2) 56(84) bytes of data.
64 bytes from 192.168.17.2: icmp_seq=1 ttl=64 time=0.601 ms
64 bytes from 192.168.17.2: icmp_seq=2 ttl=64 time=0.181 ms
^C
--- 192.168.17.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1027ms
rtt min/avg/max/mdev = 0.181/0.391/0.601/0.210 ms

次に、FRRouting で AS65002 の BGP ルーター 192.168.17.2 とのピアリングを行うための設定を追加します。

bgprt01# configure
bgprt01(config)# interface eth0
bgprt01(config-if)# ip address 192.168.17.1/25
bgprt01(config-if)# exit
bgprt01(config)# router bgp 65001
bgprt01(config-router)# bgp router-id 192.168.17.1
bgprt01(config-router)# no bgp ebgp-requires-policy
bgprt01(config-router)# neighbor 192.168.17.2 remote-as 65002
bgprt01(config-router)# exit
bgprt01(config)# exit
bgprt01# exit
bgprt01# write memory
Note: this version of vtysh never writes vtysh.conf
Building Configuration...
Integrated configuration saved to /etc/frr/frr.conf
[OK]
bgprt01# show running-config
Building configuration...

Current configuration:
!
frr version 8.4.2
frr defaults traditional
hostname bgprt01
log syslog informational
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
interface eth0
 ip address 192.168.17.1/25
exit
!
router bgp 65001
 bgp router-id 192.168.17.1
 no bgp ebgp-requires-policy
 neighbor 192.168.17.2 remote-as 65002
exit
!
end

no bgp ebgp-requires-policy を設定に加えることによって、受け取った経路情報を accept するようになり、FIB への登録も完了します。

This command requires incoming and outgoing filters to be applied for eBGP sessions as part of RFC-8212 compliance. Without the incoming filter, no routes will be accepted. Without the outgoing filter, no routes will be announced.

https://docs.frrouting.org/en/latest/bgp.html#clicmd-bgp-ebgp-requires-policy

このように設定を完了すると、以下のように 192.168.17.2 にある AS65002 の BGP ルーターとのピアリングの BGP state が Established になっており、かつ IPv4 Unicast について 1 つの prefix を accept していることが確認できます。

bgprt01# show bgp neighbors 192.168.17.2
BGP neighbor is 192.168.17.2, remote AS 65002, local AS 65001, external link
  Local Role: undefined
  Remote Role: undefined
Hostname: bgprt02
  BGP version 4, remote router ID 192.168.17.1, local router ID 192.168.17.1
  BGP state = Established, up for 00:04:52
  Last read 00:00:52, Last write 00:00:52
  Hold time is 180 seconds, keepalive interval is 60 seconds
  Configured hold time is 180 seconds, keepalive interval is 60 seconds
  Configured conditional advertisements interval is 60 seconds
  Neighbor capabilities:
    4 Byte AS: advertised and received
    Extended Message: advertised and received
    AddPath:
      IPv4 Unicast: RX advertised and received
    Long-lived Graceful Restart: advertised and received
      Address families by peer:
    Route refresh: advertised and received(old & new)
    Enhanced Route Refresh: advertised and received
    Address Family IPv4 Unicast: advertised and received
    Hostname Capability: advertised (name: bgprt01,domain name: n/a) received (name: bgprt02,domain name: n/a)
    Graceful Restart Capability: advertised and received
      Remote Restart timer is 120 seconds
      Address families by peer:
        none
  Graceful restart information:
    End-of-RIB send: IPv4 Unicast
    End-of-RIB received: IPv4 Unicast
    Local GR Mode: Helper*
    Remote GR Mode: Helper
    R bit: True
    N bit: True
    Timers:
      Configured Restart Time(sec): 120
      Received Restart Time(sec): 120
    IPv4 Unicast:
      F bit: False
      End-of-RIB sent: Yes
      End-of-RIB sent after update: Yes
      End-of-RIB received: Yes
      Timers:
        Configured Stale Path Time(sec): 360
  Message statistics:
    Inq depth is 0
    Outq depth is 0
                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:                2          2
    Keepalives:             5          5
    Route Refresh:          0          0
    Capability:             0          0
    Total:                  8          8
  Minimum time between advertisement runs is 0 seconds

 For address family: IPv4 Unicast
  Update group 1, subgroup 1
  Packet Queue length 0
  Community attribute sent to this neighbor(all)
  1 accepted prefixes

  Connections established 1; dropped 0
  Last reset 00:04:53,  Waiting for peer OPEN
  External BGP neighbor may be up to 1 hops away.
Local host: 192.168.17.1, Local port: 49414
Foreign host: 192.168.17.2, Foreign port: 179
Nexthop: 192.168.17.1
Nexthop global: fe80::9ea3:baff:fe32:2318
Nexthop local: fe80::9ea3:baff:fe32:2318
BGP connection: shared network
BGP Connect Retry Timer in Seconds: 120
Estimated round trip time: 7 ms
Read thread: on  Write thread: on  FD used: 25

また、以下のようにして 192.168.17.102/32 を AS65002 の BGP ルーターを経由してアクセスするようになったことを確認できます。

user@bgprt01:~$ ip route get 192.168.17.102
192.168.17.102 via 192.168.17.2 dev eth0 src 192.168.17.1 uid 1002
    cache

また、以下のようにして 192.168.17.102 への HTTP GET リクエストを送信すると、レスポンスとして i c t s c という文字列を得ることができることを確認しました。

user@bgprt01:~$ curl -v 192.168.17.102
*   Trying 192.168.17.102:80...
* Connected to 192.168.17.102 (192.168.17.102) port 80 (#0)
> GET / HTTP/1.1
> Host: 192.168.17.102
> User-Agent: curl/7.81.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx
< Date: Sun, 05 Mar 2023 02:58:27 GMT
< Content-Type: text/html
< Content-Length: 11
< Last-Modified: Wed, 15 Feb 2023 12:44:54 GMT
< Connection: keep-alive
< ETag: "63ecd3c6-b"
< Accept-Ranges: bytes
<
i c t s c
* Connection #0 to host 192.168.17.102 left intact

よろしくお願いいたします。

Raw
vzx.md

お世話になっております。 チーム word-unknown-tsukuba-otaku です。

Host01 から Host02 への ping が飛ばない問題について調査いたしました。

まず、Host01 にて Host02 の IP アドレス 172.17.0.1 へのルーティング情報が格納されているかを確かめるため、以下の作業で確認を行いました。

user@vzx-host1:~$ ip route get 172.17.0.1
RTNETLINK answers: Network is unreachable

このように、Host01 から Host02 へ通信を行う際の next hop を決めるための情報が格納されていないことがわかりました。これを解決するために、Host01 ではデフォルトゲートウェイとしてルーター 172.16.255.254 を以下のようにして設定しました。

user@vzx-host1:~$ configure
[edit]
user@vzx-host1:~$ set protocols static route 0.0.0.0/0 next-hop 172.16.255.254
[edit]
user@vzx-host1# commit
[edit]
user@vzx-host1# save
Saving configuration to '/config/config.boot'...
Done
[edit]
user@vzx-host1# exit
exit

このようにすると、ルーター 172.16.255.254 を介して ICMP Echo Request を 172.17.0.1 に送信するようになりますが、ICMP Echo Reply が帰ってきませんでした。このことは、Host02 で tcpdump をしてみると、以下のようなログを見ることができたことからもわかります。

user@vzx-router:~$ tcpdump -i eth1 port not 22
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:34:31.048899 IP 172.16.0.1 > 172.17.0.1: ICMP echo request, id 14502, seq 1, length 64
13:34:32.091004 IP 172.16.0.1 > 172.17.0.1: ICMP echo request, id 14502, seq 2, length 64

172.17.0.1 からの ICMP Echo Reply が帰ってこない原因のひとつに、Router で firewall の設定が不適切になされている可能性が考えられました。これを検証するため、Router にて次のように firewall 設定の確認を行いました。

user@vzx-router:~$ show firewall
Rulesets Information

---------------------------------
IPv4 Firewall "ETH1-OUT"

Active on: (eth1,out)

Rule     Action    Protocol      Packets    Bytes  Conditions
-------  --------  ----------  ---------  -------  ----------------
10       accept    tcp                 0        0  meta l4proto tcp
default  drop      all                37     3108

icmp のパケットを accept するような設定を入れなければ、default のルールで drop されてしまうことがわかったため、そのような設定を以下のようにして追加しました。

user@vzx-router:~$ configure
[edit]
user@vzx-router# set firewall name ETH1-OUT rule 20 action accept
[edit]
user@vzx-router# set firewall name ETH1-OUT rule 20 protocol icmp
[edit]
user@vzx-router# compare
[edit firewall name ETH1-OUT]
+rule 20 {
+    action accept
+    protocol icmp
+}
[edit]
user@vzx-router# commit
[edit]
user@vzx-router# save
Saving configuration to '/config/config.boot'...
Done
[edit]
user@vzx-router# exit
exit

このようにすると、Host01 から Host02 への ping が通るようになりました。その様子は以下の通りです。

user@vzx-host1:~$ ping 172.17.0.1
PING 172.17.0.1 (172.17.0.1) 56(84) bytes of data.
64 bytes from 172.17.0.1: icmp_seq=1 ttl=63 time=0.732 ms
64 bytes from 172.17.0.1: icmp_seq=2 ttl=63 time=0.458 ms
64 bytes from 172.17.0.1: icmp_seq=3 ttl=63 time=0.416 ms
^C
--- 172.17.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2064ms
rtt min/avg/max/mdev = 0.416/0.535/0.732/0.140 ms

また、Host01 と Router それぞれで sudo reboot を実施し、再起動後にも ping が通ることを確認しました。これは、configure で設定を commit した後に save を実施することで設定が永続するようにしたことで実現できました。

Raw
wsm.md

お世話になっております。 チーム word-unknown-tsukuba-otaku です。

wsmhost で DHCP サーバーを動作させ、中古のマシン（計算機 X, 以下 machine-x）に 10.0.0.0/24 のアドレスを割り振ることで wsmhost からの ping での疎通確認および ssh での接続を行うことができましたので報告いたします。

まず、目的を実現するための DHCP サーバーの設定ファイル自体はすでに /etc/dhcp/dhcpd.conf に格納されており、おそらく編集前のファイルのバックアップとして /etc/dhcp/dhcpd.conf.bk も配置されていたため、その差分を見ることにしました。以下はその差分となります。

--- /etc/dhcp/dhcpd.conf.bk     2023-02-25 21:26:20.102898452 +0900
+++ /etc/dhcp/dhcpd.conf        2023-02-25 21:30:16.838433348 +0900
@@ -6,60 +6,14 @@
 # configuration file instead of this file.
 #

-# option definitions common to all supported networks...
-option domain-name "example.org";
-option domain-name-servers ns1.example.org, ns2.example.org;
-
-default-lease-time 600;
-max-lease-time 7200;
-
-# The ddns-updates-style parameter controls whether or not the server will
-# attempt to do a DNS update when a lease is confirmed. We default to the
-# behavior of the version 2 packages ('none', since DHCP v2 didn't
-# have support for DDNS.)
-ddns-update-style none;
-
-# If this DHCP server is the official DHCP server for the local
-# network, the authoritative directive should be uncommented.
-#authoritative;
-
-# Use this to send dhcp log messages to a different log file (you also
-# have to hack syslog.conf to complete the redirection).
-#log-facility local7;
-
-# No service will be given on this subnet, but declaring it helps the
-# DHCP server to understand the network topology.
-
-#subnet 10.152.187.0 netmask 255.255.255.0 {
-#}
-
-# This is a very basic subnet declaration.
-
-#subnet 10.254.239.0 netmask 255.255.255.224 {
-#  range 10.254.239.10 10.254.239.20;
-#  option routers rtr-239-0-1.example.org, rtr-239-0-2.example.org;
-#}
-
-# This declaration allows BOOTP clients to get dynamic addresses,
-# which we don't really recommend.
-
-#subnet 10.254.239.32 netmask 255.255.255.224 {
-#  range dynamic-bootp 10.254.239.40 10.254.239.60;
-#  option broadcast-address 10.254.239.31;
-#  option routers rtr-239-32-1.example.org;
-#}
-
-# A slightly different configuration for an internal subnet.
-#subnet 10.5.5.0 netmask 255.255.255.224 {
-#  range 10.5.5.26 10.5.5.30;
-#  option domain-name-servers ns1.internal.example.org;
-#  option domain-name "internal.example.org";
-#  option subnet-mask 255.255.255.224;
-#  option routers 10.5.5.1;
-#  option broadcast-address 10.5.5.31;
-#  default-lease-time 600;
-#  max-lease-time 7200;
-#}
+subnet 10.0.0.0 netmask 255.255.255.0 {
+  range 10.0.0.128 10.0.0.254;
+  option routers 10.0.0.1;
+  option subnet-mask 255.255.255.0;
+  option broadcast-address 10.0.0.255;
+  default-lease-time 600;
+  max-lease-time 7200;
+}

 # Hosts which require special configuration options can be listed in
 # host statements.   If no address is specified, the address will be

10.0.0.0/24 で、ホスト部が 128 から 254 のものについて DHCP で IP アドレスの自動割り当てをするような設定になっていることがわかります。 また、削除された行は 10.0.0.0/24 での DHCP サーバーの設定に移植された、またはコメント行のみであることがわかります。

wsmhost 自身が持つ IP アドレスは、ip a の実行結果より 10.0.0.1/24 であることがわかります。

user@wsmhost:~$ ip a
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 fq_codel state UP group default qlen 1000
    link/ether 9c:a3:ba:32:06:32 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.1/24 brd 10.0.0.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::9ea3:baff:fe32:632/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 9c:a3:ba:32:dc:78 brd ff:ff:ff:ff:ff:ff
    inet 192.168.12.128/24 brd 192.168.12.255 scope global dynamic noprefixroute eth1
       valid_lft 106sec preferred_lft 106sec
    inet6 fe80::9ea3:baff:fe32:dc78/64 scope link
       valid_lft forever preferred_lft forever

この状態で既に準備万端だと思い、sudo systemctl start isc-dhcp-server を実行すると、wsmhost の eth1 に割り当てられている IP アドレス 192.168.12.128 を指定して作業のために確立した SSH コネクションも途切れてしまうという問題があることがわかりました。このことから、isc-dhcp-server.service もとい dhcpd を実行する際に現状のネットワーク設定に意図しない変更が加えられていると考えられました。なお、この問題が発生してしまうと wsmhost への SSH が不能となるため、以下の議論に進む前に再展開を実施し、上記 netplan の設定作業をやり直しました。

ここで、wsmhost に割り当てられている 10.0.0.1/24 がどこで設定されたものであるかを調べようとしました。wsmhost ではネットワークインターフェイスへの IP アドレスの割り当ての設定は netplan で行っているようでしたので、/etc/netplan 以下にある 99-netcfg.yaml の中を確認しました。以下はその内容です。

network:
  ethernets:
    eth1:
      dhcp4: true
  renderer: NetworkManager
  version: 2

eth1 のアドレスは DHCP で割り当てを受けていることがわかりましたが、eth0 のアドレスに関する記述はありませんでした。そこで、以下のように変更を加えました。

--- 99-netcfg.yaml.bak  2023-03-05 10:36:29.174671989 +0900
+++ 99-netcfg.yaml      2023-03-05 10:19:00.571279974 +0900
@@ -2,5 +2,8 @@
   ethernets:
     eth1:
       dhcp4: true
+    eth0:
+      dhcp4: false
+      addresses: [10.0.0.1/24]
   renderer: NetworkManager
   version: 2

その後、sudo netplan apply でネットワークの設定を反映しました。ip a の実行結果は先程のものとほぼ同一であり、eth0 の点では変わったことはなく、eth1 の valid_lft 以降の秒数が変化しているだけでした。 この状態で sudo systemctl start isc-dhcp-server.service を実行してみると、wsmhost との SSH 接続が途切れないまま DHCP サーバーの起動をすることができました。 DHCP で配布している範囲の最初の IP アドレス 10.0.0.128/24 が machine-x に割り振られていると推察し、これと疎通が取れることを ping で確認しました。

user@wsmhost:/etc/netplan$ ping -c 3 10.0.0.128
PING 10.0.0.128 (10.0.0.128) 56(84) bytes of data.
64 bytes from 10.0.0.128: icmp_seq=1 ttl=64 time=0.297 ms
64 bytes from 10.0.0.128: icmp_seq=2 ttl=64 time=0.171 ms
64 bytes from 10.0.0.128: icmp_seq=3 ttl=64 time=0.235 ms

--- 10.0.0.128 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2027ms
rtt min/avg/max/mdev = 0.171/0.234/0.297/0.051 ms

また、user@10.0.0.128 に SSH し、ユーザー認証が成功してシェルにアクセスできることも確認しました。

user@wsmhost:/etc/netplan$ ssh 10.0.0.128
user@10.0.0.128's password:
 _____  _____  _____  _____  _____  _____  _____  _____  _____
|_   _|/  __ \|_   _|/  ___|/  __ \/ __  \|  _  |/ __  \/ __  \
  | |  | /  \/  | |  \ `--. | /  \/`' / /'| |/' |`' / /'`' / /'
  | |  | |      | |   `--. \| |      / /  |  /| |  / /    / /
 _| |_ | \__/\  | |  /\__/ /| \__/\./ /___\ |_/ /./ /___./ /___
 \___/  \____/  \_/  \____/  \____/\_____/ \___/ \_____/\_____/
Last login: Sun Mar  5 10:20:56 2023 from 10.0.0.1
user@machine-x:~$ ls
congrats.txt
user@machine-x:~$ cat congrats.txt
Congratulations!

なお、問題の制約に「ホストマシンの再起動後、計算機Xとの疎通ができなくても良い」とありましたので、今回は isc-dhcp-server.service の起動を永続化する作業は実施しておりません。しかし、DHCP のリース時間が切れるまではこの service を起動しなくても引き続き machine-x との接続ができるものと思います。

よろしくお願いいたします。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment