PHPcon2017 に CONBU (project team member) として参加してきました
先日、東京の南蒲田にて PHPcon2017 *1 が開催されていました。
今回私は CONBU(project member) *2 として参加してきましたので、その一部をご紹介できればと思います。
当記事では、物理構成・製品選定 について、実際に考慮した部分を書く予定です。
対象とする読者
- 製品選定までの過程が気になる方
- 配線方法が気になる方
- ただ読みたい方
- このブログが好きで好きでたまらない方
項目
1. 今回のトポロジ図
2. 構成や配線周りに関して
2.1 なぜ分ける構成にしたのか
2.1.1 会場側
2.1.2 クラウド側
2.2 なぜIXとpfsenseにしたのか
2.2.1 クラウド側候補
2.2.2 会場側候補
2.3 どう機材を設置したのか
2.4 どう配線したのか
3. CROSS2017,PHPcon2017と参加してみて
4. 最後に
では、どんな構成だったかを説明するにあたり、今回のトポロジ図がございますので、まずはそちらを掲載いたします。
今回のトポロジ図
三好 さん作
(ブログに掲載する許可を頂きました)
左: 通常
右: おでんバージョン
今回は、さくらのクラウド内と会場ネットワークを結び運用していました。
CONBUの今年のテーマとして 「クラウド」(○Fではない) がありまして、今年構築しているネットワークは基本的に クラウド(○ストライフではない) を用いています。
構成や配線周りに関して
なぜ分ける構成にしたのか
会場側
- フレッツの引き込み口が1階にある
- Wi-Fiの提供範囲
- 1階～4階 + 6階
- 会場のルール
- 壁・床どちらも養生禁止
- 階層によっては床にケーブルを這わせる事自体禁止
以上の事から全ての階を繋ぐ事は難しいと判断し、会場側は五拠点に分けて運用を行っていました。
また、IXが潤沢にあった事も後押しになったかと思います。
1～3階だけ繋ぐことが出来たのは、階段を溝配線したり2階吹き抜けホールを空中配線したりして、3階まで持って行く事が可能だったからでした。
クラウド側
- CONBUで IX 対 pfsense でのイベント運用実績があまりなかった
- pfsenseについて追究しきれてない部分があり、各VPNを1台のpfsenseに纏める事に対して抵抗があった
- Hotstage *3 ではVPNを1台に纏める事が出来たが、その上でのパフォーマンスチェックや他十分な検証が行えなかった
以上の事からクラウド側のpfsenseは五拠点分構築して運用することにしました。
纏める事に関してはもう少し詰める事が出来たかもしれませんが、この時点では安定稼働できる確証が持てませんでした。
また、私自身あまりpfsenseのマニュアルを読みきれてないのですが、設定箇所が点在している為か何かと作業が煩雑になりがちだなぁという印象を受けました。
インストールしてすぐ使うにはちょっと難易度の高い製品かもしれません。
なぜIXとpfsenseにしたのか
- IPsec NAT-Tに対応している必要がある
- 因みにIXのIPsec NAT-Tはmainモードと併用できない
- aggressiveモードに対応している必要がある
- vyos非サポート,aggressiveは削除された
- クラウド側はフリーのアプライアンスで解決したい
- Wi-Fi構築の敷居を低くし、CONBUがなくても構築できるようにしたい
クラウド側候補
SEILとpfsense、多分どっちでも問題なかったと思いますが、CROSS2017でpfsenseを使用していたこともありpfsenseを選びました。
会場側候補
- IX
- 五拠点補うくらいはあった
- 過去何回かの実績があった
- pfsense (実機)
- そんなに台数がない
- CROSS2017でパフォーマンスがあまり出なかった
どちらかというと個数的な問題でIXになりました。
無い物は無いので。。。
どう機材を設置したのか
会場空き状況等との兼ね合いもあり、PHPcon前日に 1階ホール機材展開 と 上流回線との接続 を行っていました。
他階の設置と配線は当日朝の数時間で展開していて、何だかんだ時間ギリギリ。
どの会場でもそうだと思うのですが、やはり配線は時間がかかりますね。
ちなみに階層別に担当を分けてやっていたわけですが、毎度の事ながら作業中の連絡手段として Zello がとても便利です。
着信音とかも変更できるので、機内音にしたりメタル○アの音にしたりカスタマイズも可能です！
（他に良いツールがあれば教えて頂けると助かります！）
また、実際の配置場所については、アクセスポイントもスイッチ (任○堂ではない) も事前に決めた場所へ配置しています。
機材設置に関して特筆するような事はないと思いますが、考慮する点として以下などがあるのかと思われます。
- 会場自体の調査
- 養生は可能か
- ドア等にはケーブルを通すスペースがあるのか
- 既設回線はあるか、引き込み口はどこか
- .etc
- 出展スペース等の把握
- 動線の確保
- どこに機材を置けるか
- おおよそのカバレッジ考察
- どこにアクセスポイントを置けるか
- assoc数と利用端末数との兼ね合い
- ...etc
L1って最初に考えておきたい部分だと思うのですが、前もって展開する物が決まってないとL1構成を後から変更する必要がでてくるので
会場側との擦りあわせを多めにしておくと色々と良いのかなと思っています。
今回の場合、PHPcon本体スタッフと兼任している方もいらっしゃった為、円滑に擦りあわせが出来ていたのかもしれません。
どう配線したのか
先にも説明したとおり
- 壁も床も養生禁止
- 階層によっては床にケーブルを這わせる事自体禁止
という条件のもとネットワーク環境を構築しました。
溝がある所は溝に埋めたりしたわけですが
完全に締め切る部分は以下のようなLANケーブルを用いることにしました。
「この先までケーブル通したいけど、ドアは締め切らなきゃいけない」
という場合に便利なので、一つの手段として覚えておくと良いかもしれないですね。
また、「床にケーブルを這わせない」「二階から三階にケーブルを持っていく」という条件に対しては以下を用いて空中配線しました。
木造やコンクリでは使えないですが、今回は壁が金属だったのでとても重宝しました。
とはいっても、金属ならどこにでも付けて良いというわけではないので防火扉の開閉とかも考慮する必要があります。
イベントの配線って直に動線に影響してくるので、思ってる以上に考慮する必要がありますね。
CROSS2017,PHPcon2017と参加してみて
私が今回のイベントを通して改めて強く思ったこと、それは
- 「守りに入らず攻めの姿勢で、やりたいならやろう、無理だったら助けを求める」
でした。
なぜかというと
学生の頃は自分の時間をふんだんに使って準備出来ていたものが、社会人になってみると、確保できる時間に限界がでてきてしまって
その結果、 学習コスト と やり遂げる責任を強く意識するあまり、手を挙げづらくなって、守りに入ってしまった事に気づいたからです。
CROSS2017はそんな感じで自ら守りに入ってしまい、振り返るとあまりチャレンジできていなかったなぁ、と思ったり
そこから学生の頃もっと有効に時間を使う事ができたのかなぁと、悩んでしまいました。
ですが、正直時間なんてどうでもいいんです、なければ作ればいいし、どうせやらなきゃいけなくならないとやらないんです。
いつでも「機会」というものは訪れますが、それがまた訪れるとは限らないわけで、そこに必要なのは「攻めの姿勢」ではないか
手を挙げても独りでやり遂げる必要なんてないし、助けを求めればいいのではないか、という事に改めて気づき
イベントを通じて、今の自分を見つめ直すよいきっかけを得ることができました。
あと、社会人しながらって大変だなぁーと感じると共に
イベントを運営されてる皆様、すごいなーと心から尊敬します。
最後に
大まかに今回の構成になった流れと会場での配線方法等を書いてみました。
physicalでニッチな内容なので参考になるかどうかは微妙なところですが、イベント設営においての知見になれば幸いです。
ちなみに次回は Internet Week2017 のネットワーク構築をします！
（今度は写真を沢山とるぞ）
*1:
国内の業界トップランナーによるPHP最新動向や、コアテクノロジーからPHP初心者向けセッションまで約40のセッションと約10のLT（ライトニングトーク）を展開します。
これからPHPをはじめる方から、さらにPHPを極めてきたい方まで幅広く楽しめるイベントになるようプログラムをご用意します。
引用: PHPカンファレンス2017 - connpass
*2:
CONBUはCOnference Network BUildersの略称であり、大規模なカンファレンスや勉強会が行われる会場において、
会場ネットワークを構築し、インターネット接続を提供するネットワークエンジニアの集団です。
引用: CONBU - COnference Network BUilders
*3:長時間、または集中的に確保した事前準備期間
IKEv1 - UNIVERGE IX 2000シリーズ の各バージョン追加項目についてメモ
< 当記事は NEC様 よりマニュアルの転載許可を頂いた上で公開しております >
公式のマニュアルに記載してある事なので直接見ればいいのだが
自分が見やすいように纏めたかったのでカキコ
主にバージョンで追加された機能や一部細かい動作をまとめた。
それぞれの機能がどういう動きをするのかの詳細はマニュアル見ればいいと思う。
尚、2017/09/25時点の情報です。
用法
- 自分のIXのバージョンでどこまで出来るか確認する際にどうぞ（最新版入れれば全てが解決）
- 自分用にメモしただけなので他に用法はない
各機能追加順序
IPsecはこっち（まだかいてない）
IKEv2はこっち（まだかいてない）
バージョン対応
Ver 4.0 以降
Ver 4.1 以降
- ike initial-contact payload
- 機能説明書に記載はないが、おそらくalwaysは元からあった
Ver 4.3 以降
- ike commit-bit
- NEC独自
- aggressive mode + Responderでのみ有効、initiatorやmain modeではサポートしてない
- 対向がIXじゃない場合は使わない方が良いかも
- ike retransmit-count, ike retransmit-interval
- commit-bitに付随する奴、多分これも独自
Ver 5.0 以降
- ike keepalive
- passive mode出来るようになった
- 自身がkeepaliveを設定してなくても、対向が設定していれば keepalive-ack を送る
- IKE 自動再接続機能
- commit-bit再送終了時に行う、設定コマンドはない
Ver 6.2 以降
- ike suppress-dangling
- これを入れると Continuous-channel SA 型 になる、IPsecSAに連動してIKESAも落ちる
- デフォルトは Dangling SA 型、連動しない
Ver 8.1 以降
Ver 8.6 以降
- IKE HMAC-sha2 256,384,512bit
- 認証アルゴリズムにSHA2が追加
Ver 8.8 以降
| 名前解決の契機 | 定期的な更新 - 名前解決前:60秒 - 名前解決後:depend on TTL 全てのSAが削除された場合 |
|---|---|
| アドレス更新時の動作 | 該当するSAを削除 |
| 名前未解決時の動作 | SA作成不可 |
Ver 9.0.54 以降
- ike interoperability unprotected-aggressive-mode
- aggressive modeのinitiatorとして動作する際、Phase 1の最後のパケットが暗号化されない事を期待する装置と接続を可能とする
- デフォルトは暗号される状態
- Phase 2以降は保護される
Ver 9.4 以降
- no ike send-delete
- SA削除時のDELETEmessageの送信を抑止
非対応
NewGroup mode : サポートしてない
IKE Keepalive (DPD) についての僕の誤解
VPNを張る際、IKE Keepaliveについて誤解していたのでメモ。
（半年くらい公開するの忘れてた）
探せばIKE Keepaliveについて日本語でまとめてあるページがいくつかありますが、ベンダー特有の動作が混じっていたとしても私にはまだその判別が出来ないので
RFC3706 を読むことにしました。
読み切れてはなくて、ほとんどただのメモです。
解釈が違っていた場合指摘して頂けると助かります！
誤解 / 結論
私の場合、ずっとIKE Keepaliveの事を「繋がる状態を常に維持しておくもの」という考えでいました。
しかし、IKE Keepaliveの本質は
「片方のPeerが再起動やルーティング変更等を行い、もう片方のPeerにだけSA情報が残る「ブラックホール状態」にならないよう、接続障害および復旧を検知する」
という所にあるので
実際は「障害を検知し、復旧を検知すれば繋げる」という役割になります。
調べた事
DPDの目的
When two peers communicate with IKE [2] and IPSec [3],
the situation may arise in which connectivity between the two goes down unexpectedly.
....
...
Likewise, it is sometimes necessary to detect black holes to recover lost resources.
意訳ですが
二点間のIKEとIPsecでの通信で、疎通性が予期せず失われる事がある。
それは、ルーティングの問題や1つのホストの再起動などで発生する可能性があり
多くの場合、IKEとIPsecはピアへの疎通性が失われた事を特定する方法がない。
なので、ライフタイムが切れるまでSAが残り、パケットが損失する「ブラックホール状態」になる。
また、別のピアに切り替える為に「ブラックホール状態」を早く知りたい場合があり、
復旧する為にも「ブラックホール状態」を検出する必要がある。
という文章になるかなと思います。
つまりは ピアへ疎通性がない事を検知するのがDPDの目的 のようです。
略さなければ Dead Peer Detection なので、それはそうという感じですね。
ダウンの確認方法
検出するために、ISAKMP Notify messageを利用して定期的にHello/Ackメッセージを送信する。
指定間隔が経過してもHelloメッセージを受信できない場合、Helloメッセージを送信する。
指定タイムアウト時間内にそのHelloメッセージに対するACKメッセージが受信できない場合、Helloメッセージを再送する。
それでもACKを受信できなかった場合、エラーカウンターがあがり、別のHelloメッセージを送る。
逆にHelloメッセージを受信したり、ACKメッセージを受信すると、キープアライブタイマーがリセットされる。
エラーカウントがいくつか上がると、SAを削除し、フェイルオーバーを開始する可能性がある。
この通信、ISAKMPなんですよね、ICMPじゃないんです。
なので、トンネル内の通信にカウントされず更新リキーが働かない・・・と、いうことなんですかね。
六本木のジャングルと言われる、DMM新オフィスを見学してきた
こんにちは！
DMM新オフィスツアー全日程が終了したので、ネタバレしていこうかなと思っています。
ちなみに私が参加したのは 4月25日(火) - 4月26日(水) に開催されたツアーでしたが、おそらく他日程のオフィスツアーも内容は同じです。
↓ 募集はこちらでされてました、また機会があれば開催してほしいですね。
https://www.facebook.com/events/901520106657354/
ツアー内容
所要時間 : 30分
- 会社説明
- DMMは色んな事やってるよ、エロだけじゃないよってお話
- オフィス見学
- ミーティングやイベントで使われるスペースの紹介
- 正面受付の紹介
- 動物が映し出されるスペースの紹介
ツアー内容は以上で構成されていました。
会社説明
いつもの事ながら「DMMはエロだけじゃないです！こんな事もやってます！」というお話を聞きました、恒例ですね。
皆さんもご存じだとは思いますが、DMMと付く関連事業だけでも
- DMM.make
- 秋葉原にある、物を作れる場所。
- 使える機材の専門性が高い、故に使用料も高い。
- DMM.make robots
- ロボット事業。
- RoBoHoNとかはイベントで踊ったりしてる。
- DMM.com override
- スマホゲームとか作ってる。
- DMM GAMESアプリで偶にOVERRIDEって出てくるのはこれ。
- DMM.com 証券
- FXとかCFDとか取り扱ってる所。
- 結構古くからある事業な気がする。
- DMM英会話
- DMM.Africa
- 去年くらいにできた事業。
- アフリカで色々やってる
- 当初は英語喋れれば誰でもウェルカムな感じで募集してて、今はどういう募集形態なのかは知らない。
- DMMアカデミー
- 去年くらいから募集を始めて、今年から始まった事業。
- 月30万貰えて、実際に現場で活躍してる人からOJT感覚で授業を受けれる。
- 22歳まで。
私が思いつく範囲だけでもこれだけあります。色々やってますね。
VRや機械学習にも手を伸ばしているようなので、今後はそっち方面でどういう展開を見せていくのか・・・
また、今後Youtuberの方と新事業を展開するそうなので、そちらもどうなっていくのか注目ですね。
youtu.be
オフィス見学
ミーティング等で使用されるオフィス
一部分の写真で申し訳ありませんが、こんな感じでした。
また、360°の画像はこちらのサイトに掲載されています。
見てみるとオフィスの周りにたくさん植物があると思いますが、この植物、本物なんです。
(全部で250種類あるそうです)
水散布も自動で管理されていて、虫もわかないようになっているとか。
この数ならば納得ですが、凄いこだわりです。
ちなみに、ある時間になると机にあるiPadに会長のデフォルメキャラが出現します。
正面受付
エレベーターから降りてすぐこの受付があります。
滝のような映像が特徴的ですが、この滝は前の物体に反応して避けるように水の軌道が変わります。
奥には各種植物や動物の紹介が載っているパンフレットも置いてあります。
動物エリア
よく記事などで目にするエリアですね。
約26種類の動物たちが左右の壁に映し出されているエリアとなっていて、それぞれ動物をよく見ると植物で出来ています。
そしてこのエリア、実はミーティングする為の部屋が並んでいて、所々ドアになっています。
使用中の部屋の前には、その部屋に対応する動物が鎮座して使用中という事がわかるようになっていたりするようです。
触れることで動物が鳴いたり、こっちを見てくれたりするので訪れた場合は是非触ってみてください！
最後に
まるでアトラクションのようなオフィスで、見学しに行った私は楽しむ事ができました。
今後もいろんなイベントで使うオフィスだと思うので、訪れる時は色々と試してみてください！
【ICTSC7】C6D (IPv6+BGP) の問題解説
こんにちは。
ついこの前、3/4〜3/5に開催された第七回ICTトラブルシューティングコンテストで運営をやってきました。
参加された皆様および関係者の皆様、ありがとうございました！
今回私は、イベントサポートで会場準備・司会・大人との交渉などをしていた他に問題作成も行っていました。
ここではその作成した問題の解説をします。
早速ですが、私の問題構成は以下のようになっていました。
問題コード : C6D
コア技術
IPv6
RA/RS
( BGP )
IPv6
Internet Protocol Version 6（インターネット プロトコル バージョン6）、IPv6（アイピーブイ6、アイピーバージョン6）は、Internet Protocolの一種で、OSI参照モデルにおいてネットワーク層に位置付けられるプロトコルである。IPv6が誕生した背景には、IPv4のIPアドレス枯渇問題がある。
引用 : IPv6 - ウィキペディア
RA
RA (Router Advertisement; ルータ広告)とは、 IPv6アドレスの自動設定を行う機能(Stateless Address Autoconfiguration, SLAAC)(*1)の一部分で、 RFC4862で標準化されています。引用 : インターネット用語1分解説～RA (Router Advertisement; ルータ広告)とは～ - JPNIC
トポロジ
問題文
1841bに対して無事にIPv6アドレスが振られたが、今度は1841aにつながるインターフェイスにグローバルアドレスが振られていないようである。
移行期間内にBGPによるルータの冗長化を完了させて、無事サービスを始められなければインフラ班の首が危ない。
グローバルアドレスが正しく振られていない原因を突き止め、下記経路を通ってインターネットに通信ができるように設定を見直し、コンフィグとともに報告してほしい。
ただし、コアスイッチのBGP経路の重みづけはすでに設定されている。
設定に使用する認証情報と正しい経路の情報は以下のとおりである。
【1841a】
enable password：ihuygh77Kggl4dsg8G8h
【正しい経路】
1841b → 1841a → → → 疎通先
* この問題を解く為には、前提問題を解いた上で基準点を満たす必要があります
トラブルの内容
1. Ciscoルータに、定期的なRA送信を抑制するコマンドが入っている。
また、アドバタイズされたアドレスの最終有効期限が変更されている。
ipv6 nd ra suppress （不完全な抑制コマンド） ipv6 nd prefix <ipv6-prefix/prefix> <valid-lifetime preferred-lifetime> （デフォルトは30日だが、大会の性質上120秒と短く設定してました）
尚、上記の抑制コマンドの場合、自らRAは出さないものの、RSが来た場合はRAを送信する。
2. 一度はクライアントにグローバルIPv6アドレスが割り振られるが、最終有効期限が経過すると、グローバルIPv6アドレスが無くなり、外部との通信ができなくなってしまう。
3. RSは基本的にnodeがI/Fをupした時しか流れない為、アドレスが消える度にupし直さないと繋がらない状態が続いてしまう。
4. また、RouterA側にRouterBとピアを張る設定が抜けている為、インタフェースがただupするだけではBGP neighborが張れない
5. 上記が原因で対象のインタフェースとのBGP neighborがdownしてしまい、正しい経路で外部と通信ができない。
* 4と5は、手元トポロジ変更によりOSPFv3ではなくBGPにする必要があった為、付け加えた項目です。
ゴール
- ipv6 nd ra supressの削除 (valid-lifetimeのみ削除では、デフォルト設定である30日後に繋がらなくなってしまう)
- インタフェースを立ち上げ直す事でRSを流し、グローバルIPv6アドレスが再度割り振られた事を確認する
- RouterA側のBGP設定にRouterBの指定インタフェースとピアを張る設定が抜けている為、設定を入れる
- BGP neighbor downしていたインタフェースがEstablishedに変わりBGP neighbor UPした事を確認する
- 正しい経路で通信できる事を確認する
* 大会では、参加者手元環境の上流にあるコアL3スイッチにAS_PATHアトリビュートの設定を加えており、指定の経路を通るように重み付けされています
採点基準
- コンフィグもしくは入力コマンドの未提出で減点
- ipv6 nd ra supress(+ valid-lifetime)が原因で、グローバルIPv6アドレスが消えると特定できている
- 上記とRouterA側のBGP設定不備により、BGP neighborがdownしていると特定できている
- RouterAとRouterB間でBGP neighborがupしている
- IPv6アドレスを用いて、正しい経路で通信確認ができている
- RouterA、RouterBが上流ルーターとneigbhorが張れていて、冗長化構成になっている
講評
前回はPathMTUDiscoveryBlackHole問題やAUX問題を出題しましたが、解答者数が多くなかった為、今回は難易度低めの問題にしてました。
この問題では、今後docomo,Softbank,KDDIの三大キャリアがIPv6へ徐々に移行していく事も含め、IPv6に対しての関心と移行時のトラブルを知ってほしい気持ちから作成しています。
トラコン当日、解答状況を見ていると前提問題であるYUTの基準点を満たせず、この問題まで到達できないチームが多かったようでした。
しかし二日目午後終了時間間際になると、この問題に到達できるチームが続々と増え始め、結果的に半分くらいのチームがこの問題の原因を特定し、解答してくれていたので個人的に嬉しかったです。
ただ、惜しかったのは1841bとコアスイッチ間でBGP neighborが張れておらず、冗長化されていないチームが数チーム見受けられました。
show bgp ipv6 unicast neighborコマンドを用いると隣接ノードとのneighbor状況がわかる為、ぜひ使ってみてください。
また、大会のアンケートもしています。
お手隙な時にでもよろしくお願いします。
ICTSC7アンケート
ちなみに・・・
学校の環境でZabbixからslack通知を送れなかった話
家の環境ではZabbixからslackへ通知送れたけど、学校の環境では通知を送れなかったのを解決できたのでメモ
症状
- slack通知が送れる環境と同様に実装したはずだが、通知を送れない
環境
- CentOS7 [user: root, centos]
- Zabbix3.0.5
- 学校環境ではProxy経由でWANに繋がっている
ゴール
- Zabbixからslackへアラートを送信する
本題
学校の環境にZabbixを入れてslackへ通知しよう！と思い通知スクリプトを実装
しかし、slack側には何も送られず、Zabbix側では「通知スクリプト実行したよ！」という表記だけ出てしまう
最初はSELinuxかなぁ？パーミッションかなぁ？とか思っていたけど、そもそもその場合はZabbix側でエラーがでる・・・
ということは、実行後にネットワーク部分でエラーがでているのでは？と考えてみた
とりあえず、どこでエラーがでているのか確認も含めて、スクリプト自体を実行することにした
【ユーザー: centos】
【ユーザー: (sudo -s) root】
centos側では問題なく実行出来ているものの、sudo -sしたrootではタイムアウトのエラーが出てしまっている
この状態でコネクションが張れてるか気になったので、今度はhttps://slack.com/に対してcurlをやってみた
【ユーザー: centos】
【ユーザー: (sudo -s) root】
すると、sudo -sしたroot側ではproxyに向けて通信を行っていなかった
centos側にはネットワーク設定にproxyを入れていたものの、/etc/profile.d/配下にproxy.shを作成してない為
sudo -sしたrootではproxyを経由せず通信していたのだ。
これを直せばZabbixから通知を送れるようになるんじゃねえか？！とか思い、/etc/profile.d/配下にproxy.shを作成
以下のような設定で内容を記述した
PROXY="ProxyIPアドレス:ポート番号" export http_proxy="http://$PROXY" export https_proxy="http://$PROXY" export ftp_proxy="http://$PROXY"
変更後、sudo -sし直してcurlをしたところ、ちゃんとProxyを経由して通信する事が出来た。
しかし、これではまだZabbixから通知を送信することは出来なかった。
そこで、Wiresharkを用いてパケットトレースをすることにした。（最初からやれ）
【直接スクリプトを叩いた場合】
【zabbixから実行した場合】
結果、直接スクリプトを叩いた場合はProxyを経由しているが、Zabbixから実行した場合はProxyを経由してない事がわかった。
ということは、通知スクリプト自体にproxy.shを読み込めば経由してくれるのではないか？！と思い、通知スクリプトの最初に以下を追記した。
source "/etc/profile.d/proxy.sh"
その結果、うまくslackへ通知する事ができた。
