dnsmasq設定メモ
背景
内部DNSサーを使う検証をする状況が発生。 出社して環境を構築するという考えもよぎりましたが、単純に疑似的に作った社内サーバ相当のWebサーバの名前を解決だけできる簡易なDNSサーバが必要というだけであったため、 家で使えるパソコン(Ubuntu18.04LTSインストール済)にDNSサーバを導入することにしました。
DNSの選定
単純な構成なのでなんでもよかった。 最近はDNSサーバを独自に構築していなかったので、BIND、Unboundあたりかな?と何も考えていなかったが、 後輩からdnsmasqが楽だという話を聞いたので今回はdnsmasqを試すこととした。
インストール
user@ns:~$ sudo apt-get install dnsmasq Reading package lists... Done Building dependency tree Reading state information... Done Suggested packages: resolvconf The following NEW packages will be installed: dnsmasq 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 16.2 kB of archives. After this operation, 73.7 kB of additional disk space will be used. Get:1 http://archive.ubuntu.com/ubuntu bionic/universe amd64 dnsmasq all 2.79-1 [16.2 kB] Fetched 16.2 kB in 1s (26.6 kB/s) Selecting previously unselected package dnsmasq. (Reading database ... 29300 files and directories currently installed.) Preparing to unpack .../dnsmasq_2.79-1_all.deb ... Unpacking dnsmasq (2.79-1) ... Setting up dnsmasq (2.79-1) ... Created symlink /etc/systemd/system/multi-user.target.wants/dnsmasq.service → /lib/systemd/system/dnsmasq.service. invoke-rc.d: could not determine current runlevel Processing triggers for ureadahead (0.100.0-21) ... Processing triggers for systemd (237-3ubuntu10.42) ...
local DNS stub listenerの無効化
調べているとUbuntu16.10以降はlocal DNS stub listenerというものが動いており、こちらが先に53番ポートを利用してしまうとのこと。 無効にしました。
/etc/systemd/resolved.conf # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. # # Entries in this file show the compile time defaults. # You can change settings by editing this file. # Defaults can be restored by simply deleting this file. # # See resolved.conf(5) for details [Resolve] #DNS= #FallbackDNS= #Domains= #LLMNR=no #MulticastDNS=no #DNSSEC=no #Cache=yes #DNSStubListener=yes DNSStubListener=no デフォルトではDNSStubListener=yesなのでnoに変更する。
設定保存したらsystemd-resolveをリスタートする。
sudo systemctl restart systemd-resolved
dnsmasqの設定
53番ポートの競合について解決したのでdnsmasqの設定を実施。
| パラメータ | 説明 |
|---|---|
| port=53 | dnsmasqのlistenポート |
| bogus-priv | プライベートIPアドレスの逆引きを上位DNSサーバに転送しない |
| local=/umb003.net/ | ドメイン名の定義(umb003.netという内部のみ利用できるドメインを指定) |
| resolv-file=/etc/resolv.conf | 上位のDNSのIPアドレスを指定。dnsmasq自身で解決できない場合に参照する。 |
| strict-order | resolv-fileに指定しているIPを上から順番に問い合わせ |
| log-querie | ログを出力する |
| log-facility=/var/log/dnsmasq/dnsmasq.log | ログの出力場所 |
上位DNSの設定
/etc/resolve.confに上位DNSサーバを指定。 今回はCloudflareのパブリックDNSサーバを指定。
nameserver 1.1.1.3
DNSレコードの設定
/etc/hostsファイルに名前解決させるIPアドレスとホスト名のエントリを追加。 設定した内部ドメインは /etc/hosts を参照し、その他は上位のDNSサーバー(resolve.confに書かれているもの)に問い合わせて結果を返します。
192.168.112.10 ns.umb003.net 192.168.112.3 ws.umb003.net
これで完成。
digコマンドで動作確認
内部サーバ向け
$ dig ws.umb003.net ; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> ws.umb003.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52363 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ws.umb003.net. IN A ;; ANSWER SECTION: ws.umb003.net. 0 IN A 192.168.112.3 ;; Query time: 2 msec ;; SERVER: 192.168.112.10#53(192.168.112.10) ;; WHEN: Sun Aug 23 23:08:34 JST 2020 ;; MSG SIZE rcvd: 58
外部サーバ向け
dig yahoo.co.jp ; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> yahoo.co.jp ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55779 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;yahoo.co.jp. IN A ;; ANSWER SECTION: yahoo.co.jp. 300 IN A 182.22.59.229 yahoo.co.jp. 300 IN A 183.79.135.206 ;; Query time: 11 msec ;; SERVER: 192.168.112.10#53(192.168.112.10) ;; WHEN: Sun Aug 23 23:08:41 JST 2020 ;; MSG SIZE rcvd: 83
サーバログ確認
dnsmasq.confに設定したログ(/var/log/dnsmasq/dnsmasq.log)を見るとこんな出力です。 NODATA-IPv6とあるのはそのドメイン名には指定されたタイプのリソースレコードは存在しないという意味です。 AAAAレコードをクライアントから問い合わせしてもそれは存在しませんとサーバが返事しています。
Aug 23 14:12:17 dnsmasq[1410]: query[PTR] 10.112.168.192.in-addr.arpa from 192.168.112.5 Aug 23 14:12:17 dnsmasq[1410]: /etc/hosts 192.168.112.10 is ns.umb003.net Aug 23 14:12:17 dnsmasq[1410]: query[A] ws.umb003.net from 192.168.112.5 Aug 23 14:12:17 dnsmasq[1410]: /etc/hosts ws.umb003.net is 192.168.112.3 Aug 23 14:20:32 dnsmasq[1410]: /etc/hosts ws.umb003.net is 192.168.112.3 Aug 23 14:20:32 dnsmasq[1410]: query[AAAA] ws.umb003.net from 192.168.112.5 Aug 23 14:20:32 dnsmasq[1410]: config ws.umb003.net is NODATA-IPv6
外部ドメインの場合はこんな出力。 forwarded www.yahoo.co.jp to 1.1.1.3とあるので DNSサーバが自分で解決できないので上位のDNSサーバ(1.1.1.3)に投げています。
Aug 23 14:19:15 dnsmasq[1410]: query[PTR] 10.112.168.192.in-addr.arpa from 192.168.112.5 Aug 23 14:19:15 dnsmasq[1410]: /etc/hosts 192.168.112.10 is ns.umb003.net Aug 23 14:19:15 dnsmasq[1410]: query[A] www.yahoo.co.jp from 192.168.112.5 Aug 23 14:19:15 dnsmasq[1410]: forwarded www.yahoo.co.jp to 1.1.1.3 Aug 23 14:19:15 dnsmasq[1410]: reply www.yahoo.co.jp is <CNAME> Aug 23 14:19:15 dnsmasq[1410]: reply edge12.g.yimg.jp is 183.79.217.124 Aug 23 14:19:15 dnsmasq[1410]: query[AAAA] www.yahoo.co.jp from 192.168.112.5 Aug 23 14:19:15 dnsmasq[1410]: cached www.yahoo.co.jp is <CNAME> Aug 23 14:19:15 dnsmasq[1410]: forwarded www.yahoo.co.jp to 1.1.1.3 Aug 23 14:19:15 dnsmasq[1410]: reply www.yahoo.co.jp is <CNAME> Aug 23 14:19:15 dnsmasq[1410]: reply edge12.g.yimg.jp is NODATA-IPv6
おまけ(CloudflareのパブリックDNSについて)
今回の構成で使った上位DNSはCloudflareのパブリックDNSです。CloudflareのパブリックDNSは以下を参照下さい。
CloudflareのパブリックDNSは1.1.1.1が有名なのですが、 他にもマルウェアブロック機能付きの1.1.1.2とマルウェアとアダルトコンテンツをブロックする1.1.1.3(今回使ったもの)があります。
試しに有名なアダルトサイトのFanza(dmm.co.jp)の名前解決をしようとすると0.0.0.0で帰ってきます。
Aug 23 14:24:13 dnsmasq[1410]: query[PTR] 10.112.168.192.in-addr.arpa from 192.168.112.5 Aug 23 14:24:13 dnsmasq[1410]: /etc/hosts 192.168.112.10 is ns.umb003.net Aug 23 14:24:13 dnsmasq[1410]: query[A] www.dmm.co.jp from 192.168.112.5 Aug 23 14:24:13 dnsmasq[1410]: forwarded www.dmm.co.jp to 1.1.1.3 Aug 23 14:24:13 dnsmasq[1410]: reply www.dmm.co.jp is 0.0.0.0 Aug 23 14:24:13 dnsmasq[1410]: query[AAAA] www.dmm.co.jp from 192.168.112.5 Aug 23 14:24:13 dnsmasq[1410]: cached www.dmm.co.jp is ::
ブラウザで開こうとするとこんな感じです。
まとめ
dnsmasqはとてもシンプルにDNSサーバとして使えるのでちょっとした試験がしたいという方にはオススメです。 自分でもそんなに苦戦せずに構築できました。Centosでもほぼ同じ手順でできるのではないでしょうか。
構築するにあたりDNSがよくわかる教科書を読みましたが、非常にわかりやすく書かれていると思います。 自分も繰り返し読んで習熟するつもりです。
リモートワークで実機が無くてもネットワーク機器ベンダーの製品を体験できるサイト
はじめに
昨今の事情でリモートワークを余儀なくされているケースも出てきているのでは思うのですが、そんな時だからこそ自分が触ったことのないネットワーク機器がどんなもんか調査するチャンスでもあります。 とは言いつつも最近はクラウド上にベンダー製品のコンパネがあって機器検証とか普通にできるよ!!って人も多いと思いますが・・・。 ※自分もCisco Merakiあたりは普通に設定したり見たりしてます。 本記事では実物の機器が無くてもどんなものか調査したり確認できるよってサイトを記載してみます。
Cisco Devnet
https://www.cisco.com/c/m/ja_jp/developer.html
CiscoSystems社の製品に特化した内容以外にもPython等の技術の基礎コース等も無償で提供してくれているサイト。 Cisco.com IDを持ってなくともGithubやGoogleのアカウントを持っていれば入れたりする。 自分はCisco.com ID持っているのでそれを使ってます。
詳細はCiscoさんの昨年末(2019年末)のアドベントカレンダーに載ってます。
https://qiita.com/kazkaz_o3/items/b1bfaa35be7051d2c052
昨年の12月に日本でも開催されたDevnet Expressの内容なんかもここで見れたり触れたりします。 また、Devnet SandboxではイスラエルのQuali社のCloudShellのLAAS(Lab as a service)の仕組みを利用して、 複数の機器を触れる仕組みを提供してくれています。
https://info.quali.com/quali20cloudshell20pro20powers20cisco20devnet.pdf
Cisco社にはパートナー向けにdCloudという環境もありますので、代理店やられてる方はこちらを使うのもありかと思います。
Big Switch Labs
https://bigswitchnetworks.jp/labs
老舗のSDNベンダーのBigSwitchNetworks社のオンラインラボ環境。 自分はBig Monitoring Fabricをこれを使って少し触ったことがあります。
利用するにはBig Switchのサイトでユーザ登録をしてから利用する必要あり。
個人的な懸念点としては2020年2月13日にBigSwitchNetworks社がAristaNetworks社に買収されたのでこのラボの仕組みの存続がどうなるんだろうかというところです。Big Monitoring FabricはAristaのTap Aggrigationと競合していたりもするので製品自体どうなのるのかも気になります。 ※2020年8月23日の時点ではまだ使えそうです。
Arista社もこういうオンラインで機器が触れるラボがあるといいなあと思ったり・・・。
https://www.arista.com/en/company/news/press-release/9800-pr-20200214
Juniper vLabs
https://jlabs.juniper.net/ccl/portal
Junos製品を触ることができるJuniperNetworks社のラボシステム。 こちらもDevnetのSandboxのようにQuali社の仕組みを使っている模様。
詳しくは以下のてくなべさんのサイトに記載されてます。 https://tekunabe.hatenablog.jp/entry/2019/01/01/juniper_vlabs
自分はJunosを使ったこと/使う機会が現在がほとんどないので機会があれば試してみたいと思っています。 使うにはJuniper User IDユーザ登録が必要。
Fortinet Product Demo Center
https://www.fortinet.com/demo-center.html
様々なFortinet社の製品を触ることができるサイト。 最近はUTM、Firewallだけでなく、SD-WAN、SD-Accessといった分野に力を入れている印象です。 Fortinet社のSD-WANはどのようなものか個人的に興味あるのでFortiGate SD-WAN Demoを今度見てみたいなと思っています。 また、測定器を触っている仕事柄FortiTesterにも興味はあるのですが、このラボでは見れないみたいですね・・・。
VMware Hands On Lab
https://labs.hol.vmware.com/HOL/catalogs/catalog/all
様々なVMware製品をハンズオンで学べるサイト。旧VeloCloudは買収前に少し触ったことがありますがVMware製品になってから触ったことないのでこちらも登録して触ってみたいです。 また、2019年6月にVMware社が買収したAviNetworksの製品も自分は負荷分散装置は触らないので門外漢ですが、人づてに面白い製品と聞いているのでこちらも情報収集できればと思ってます。
https://www.vmware.com/jp/company/news/releases/2019/vmw-avi-networks-061719.html
※以下の日本語のサイトのハンズオンはMy VMwareのIDで試せるみたいなのですが、上記のURLはそれとは違う登録が必要? http://web.hol.vmware.com/landingPages/index.html?id=HOL-Japan
その他
元記事 qiita.com
AristaNetworks cEOS-labのインストールと起動(Docker for Windows)
はじめに
AristaNetworks社の製品について業務で少し関わっており、気軽に触りたい環境を作りたいと考えていた。 Arista社にはハイパーバイザー上で利用できるvEOS※という仮想版がリリースされてはいるものの、必要とされるメモリが2G程度で少々自宅のパソコンにいれるには厳しかったが、コンテナ環境で利用できるcEOSがリリースされている(メモリは600M程度で動く)のでそれを試しに入れてみた際のメモである。 本当はLinuxサーバマシンで試そうと思ったのだが、Windows10マシンを新規に購入したのでDocker for Windowsでも動くのかまず試すことにした。
※正確にいうとlab版とそうでないものに分かれている。簡単には以下。
| 名称 | 説明 |
|---|---|
| vEOS | 商用版。購入の必要あり。 |
| vEOS-lab | 評価用。Arista.comからダウンロード可能。 |
| cEOS | 商用版。購入の必要あり。 |
| cEOS-lab | 評価用。Arista.comからダウンロード可能。 |
インストール手順
1.Arista社のサイトからcEOS-labのイメージダウンロード(ユーザ登録が必要)。
今回はcEOS-lab4.21.1Fを利用。
2.import※
※Docker for Windowsをインストールしていること前提で記載しています。自分はWindows10Proの64bitマシンを使用した。
docker import cEOS-lab.tar ceos:latest
3.create
docker create --name=ceos --privileged -p 443:443 -e CEOS=1 -e container=docker -e EOS_PLATFORM=ceoslab -e SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1 -e ETBA=1 -e INTFTYPE=eth -i -t ceos:latest /sbin/init
4.ネットワークの作成
EOS Centralにも以下記述が記載されているのですが、eth0は使えないようなのでeth1以降を設定することにする。
Note: Connection to docker0 is created by default when no network parameters are specified in docker create. Ethernet0 interface cannot be used and is not available inside the Cli shell.
docker network create net1
docker network create net2
docker network connect net1 ceos
docker network connect net2 ceos
5.コンテナ起動
docker start ceos
6.EOSのCLI
先ほど作ったコンテナネットワークのnet1とnet2につながっているEthernet1とEthernet2が作成されている。
まとめと今後やりたいこと
Docker for Windowsでちゃんと動くのかなぁという好奇心もあり、ひとまずWindowsマシンでcEOSを建ててみました。 今回は単純に1ノードのみ作成しましたが、マルチノードやAPI叩いたりやっていきたいです。 もっと早くにチャレンジしたかったのですが、年明けてからの実施になってしまった・・・。
本記事はすでにcEOSについて記載されている以下の記事も参考にさせて頂きました。
https://qiita.com/arashi1977/items/1f728035670c0a57dffd
https://tekunabe.hatenablog.jp/entry/2018/12/17/arista_cEOS-lab_one
その他
元記事
Cisco MerakiのWebhooksを試してみた
背景
個人で使えるCisco Merakiの評価機を幸運にも所有している。 たまたま目に入ったWebhooks(まだベータ版らしい)の機能が目についたのでお試しに使ってみた。 自分への備忘録を兼ねて投稿します。 一部Cisco Merakiを触ったことがある人/知っている人しかわからない用語等も含まれます。
Webhooksの設定画面
ダッシュボードを開き、ネットワーク全体→設定→アラートを選択すると一番下の画面にこんな設定画面があります。
ここでWebhookを受信するHTTPサーバを追加設定します。 HTTPサーバを追加をクリックするとこんな感じで任意の名前とHTTPサーバのURL等を記載することになります。
当初このHTTPサーバをどうしようかと思ってMerakiの英語のコミュニティを見ていたところ、Zapier(多数のアプリを組み合わせて自分ならのワークフローが作れるintergration Platform as a Service)が使えるよ!って書いてあるのを見て調べたのですが、 どうやらZapierの無料版ではWebhookの機能は使えない(Premiumのマークがついてました)ようなので途方に暮れていたところ、 Googleスプレッドシートで試せるようなのでそちらに方向転換しました。
Webhooksを使うためのステップ
とてもシンプルでこの4つのステップを実行するだけです。
1.Googleスプレッドシートを作成 2.GitHubに公開されているコードを持ってきてコピー 3.Webアプリ公開 4.MerakiダッシュボードにWebhookの設定を投入
1.Googleスプレッドシートを作成
新規にGoogleスプレッドシートを開いてツール→スクリプトエディタを選択します。すると下のような画面になります。
2.GitHubに公開されているコードを持ってきてコピー
GitHubのここからコード(code.gs)を持ってきてスクリプトエディタの初期から記載されているコード.gsの内容を入れ替えます。
3.Webアプリ公開
公開→ウェブアプリケーションとして導入を選択
次に下のような画面がでてくるのでWho has access to the appのところはAnyone,even anonymousを選択してDeployを押してください。
※Execute the app asは自分のメアドが表示されてしまうのでマスキングしてます。
Deployが終了するとWeb whook用のURLの宛先が表示されるのでこのURLをコピーします。
4.MerakiダッシュボードにWebhookの設定を投入
MerakiのダッシュボードのWebhooksに戻り先ほどコピーしたURLを登録します。
ネットワーク全体→設定→アラートを開いた一番上のアラート設定の受信者に先ほど登録したWebhook用のサーバを登録しましょう。 今回はWebhook:GoogleSheetという名前になっています。
確認作業
保存した後はWebhookのテストを実施します。Webhooksの設定箇所でWebhookテストが実施可能です。
成功すると緑色、失敗すると赤になります。自分は最初URLを最後までコピーしてなくて失敗しました。
次に設定可能なパラメータを何か変更して見て設定変更がGoogleスプレッドシートに反映されるか見てみます。 一部情報を非表示にしたりしてますが、スプレッドシートにアラート情報を受け取っていることはわかるかと思います。
まとめ
直接Webhookの設定をするのは初めてでした。やっぱり自分の手である程度やらないとイメージもわかないので、 思い立ったが吉日でやってみた結果、多少理解度が深まった気がします。 設定変更が発生したらSlackやTEAMSに通知みたいなこともゆくゆくは試してみたいですね。
参考
今回の検証はほとんどCisco Devnetのコンテンツを参照して実施してます。 https://developer.cisco.com/meraki/build/meraki-dashboard-alerts-with-google-sheets/
元記事
