whywaita さんはどこにでもいるよ

この記事は、whywaita Advent Calendar 2018 - Adventar20日目の記事です。

初めましての方は初めまして。 id:do_su_0805 と申します。

whywaita さんとは直接話した機会は片手程度な気がする仲ではありますが、気づくと「知人の知人が whywaita 」というケースであったり、場合によっては同組織に所属していた期間があったりと世間は狭いなぁというお話をさせてください。1

なお、この記事を書くにあたって、結果的にこのエントリーを出す前に転職エントリを執筆する必要が出てきたため、先行で公開しております。

転職エントリ - do_su_0805's blog

自己紹介

改めまして初めまして。 id:do_su_0805 と申します。

簡単に経歴を紹介させていただくと、

という経歴を辿ってきたものです。

kosen10s という、「2010年度に高専に入学した人たちのコミュ二ティ」に所属しています。

whywaita さんとの繋がり

whywaita さんとのパス その1 ICTトラブルシューティングコンテスト

直接の関わりはなかったのですが、私自身、ICTトラブルシューティングコンテストというイベントの運営学生だったことがあります。
前職の同期がもともと初代優勝者、2回目以降ずっと運営に携わっておられる方で、「参加してみない?」とお声掛けをいただき、参加しました。
なお、ネットワーク機器の設定なんてあまりやったこともなかった人間だったため、最後は人間redmineアサイン機になったりしていました。ご迷惑をおかけいたしました・・・。

どうやらその次の 第四回 から whywaita さんは継続的に運営に参加されておられます。
この記事で「運営に誘ってくれた」とある id:jackson58 や、「技術的な支援をしてくださった」とある id:kuro_m88 とかと一緒に運営委員をやっていました。
世間は狭いです。

whywaita さんとのパス その2 電気通信大学

kosen10s 関連などで電気通信大学に友人が何名かいます。2
また、 whywaita 氏も電気通信大学に所属しておられます。
まぁかち合わないわけがなく、twitter などで何度もお見受けし、初めて存在を認識したのがこの辺りだと思います。

whywaita さんとのパス その3 kosen10s

これもう、後述の #5 の時は理解が追いつかなかったんですが、whywaita 氏は kosen10s のイベント、 kosen10s LT #5#12 などに参加されています。
自他共に認める「準高専生」という称号があり、これもまたすごいなぁと思いました。 確かにシンパシーを感じる瞬間は多々あります。 この辺りから、「世間って狭いなぁ」と思い始めました。

whywaita さんとのパス その4 前職

先ほど転職エントリをあげさせていただきましたが、つい4ヶ月くらい前までさくらインターネット株式会社に所属しておりました。
自身が twitter に挙げられていたので引用させていただきますが、

というわけで、whywaita 氏もさくらインターネット株式会社でアルバイトとして就業しておられ、勤続的に重なった期間が少なからずあります。
ここはもう完全に「世間って(ry)」となりましたが、気づいた頃から彼が僕の分報チャンネルにいた気がします。3

whywaita さんとのパス その5 現職

同じく先ほど転職エントリにて触れましたが、現在株式会社はてなに所属しています。
まず入社直後からメンターをしてもらってる方が、「whywaita とは同じアルバイト先だったよ」と話になり驚き、
この AdventCalendar を毎年作成されている id:masawada さんなども同僚になりました。そういえば初対面の話は whywaita さんのお話でした。
いやはや、whywaita 氏どこでも知り合いがいてすごいなぁと本当に思いました。

最後に

ISUCON8 優勝おめでとうございます!
これからもご活躍を草むらの陰から追っていけたらと思います。 改めてどうぞよろしくお願いいたします!


  1. きっとみなさんも多いと思うのですが・・・ひとえに whywaita さんの活動範囲の広さの賜物と思っており、尊敬しています。

  2. 何かプレゼンテーションかの授業で、kosen10s のメンバーが僕の自己紹介スライドを作っていた(?)らしく、先ほどの「運営に誘ってくれた」方が驚いていたのを覚えています。 (https://twitter.com/staybuzz/status/598498171484966912)

  3. ひとりごとうるさくてごめんね

iptables-extentions に含まれる u32 についてのご紹介

TL;DR

  • TL;DRとは
  • この記事は #kosen10s Advent Calendar 2018 - Adventar の 17日目の記事です。遅刻して申し訳ございません。
    • 昨日の記事は、 id:satuma77 さんで、「掴んで見せます!自分星!」とのことでした。comming soon ってやつですね。
    • 明日の記事は id:denari01 さんです。今のところすべての advent calendar に未投稿の様子です。お忙しいんでしょうね…。
    • 毎年、技術っぽい記事とそうでない生活の知恵的な記事を書いているので、これは前者側の記事です。後者側については 9日目の 転職活動まとめ - do_su_0805's blog でした。
  • 昔、ちょっと調べた iptables の u32 というオプションでどんなことができるのか、というのを例を交えてご紹介します。
    • ちなみに「これ見たことがあるぞ!」という人がいるかもですが、記憶を頼りに調べなおして見た感じです。
  • iptables -m u32 --u32 "6&0xFF=0x1 && 0>>22&0x3C@0>>24=0x08 && 0>>22&0x3C@6>>16&0x01=0x01" -A INPUT -j DROP すれば icmp_seq が偶数のときだけ通って、
    iptables -m u32 --u32 "6&0xFF=0x1 && 0>>22&0x3C@0>>24=0x08 && 0>>22&0x3C@6>>16&0x01=0x00" -A INPUT -j DROP すれば icmp_seq が奇数のときだけ ping が通るような不思議サーバができます、
    という話をパケットの仕組みを交えながら解説します。

前書き

iptables を使うと、いろいろな通信について、カウント(ロギング)や許可、排除などができます。
(実を言うと iptables 自体に慣れ親しんでいるわけでもないので、どこまでできるのか、というのは詳しくはありません。 )
ですが、そんな iptables でも手が届かない場所ってのはあって、そんなケースにおいてもパケット自体を解析してルール化できるのが iptables u32 です。

今回は下記実例をもとに、紹介できればと思います。
なお、軽くは紹介しますが、この記事を読むに当たって、 IPヘッダの図ICMPヘッダの図 と、 TCPヘッダの図 を片手に読まれるとスムーズに読めると思います。

想定できる利用用途

といってもそんなに想定できません。
逆に、変なときにこれを知っていると実現できるかも、みたいなケースがあるかもしれません。
詳しいことは忘れて、存在だけ覚えておくといいかもしれないです。
パケットの構造さえ理解できれば、様々な種類のパケットに対応できるので、使い方は無限大だと思います。

共通お作法

使い方

  • iptables -m u32 --u32 まではお約束になります。
  • それ以降は、パケットの気持ちになってスタート位置を変えたり、シフト演算したり、アンド演算したりして、自分のほしい条件を作っていきます。
  • 末尾に iptables っぽい条件を追加することで、該当ルールとして作動させることができます。

実例

今回は、二つのケースを用意しました。

  • 対向から ping を飛ばし、 2 回に 1 回 受ける側で drop する
  • 対向から curl をずっとし続けて、 シーケンス 番号が偶数のものを drop する。

1. 対向から ping を飛ばし、 2 回に 1 回 drop する についての解説

先にルールを書いて、そこから解説していきます。

  • 偶数だけ通る
    • iptables -m u32 --u32 "6&0xFF=0x1 && 0>>22&0x3C@0>>24=0x08 && 0>>22&0x3C@6>>16&0x01=0x01" -A INPUT -j DROP
  • 奇数だけ通る
    • iptables -m u32 --u32 "6&0xFF=0x1 && 0>>22&0x3C@0>>24=0x08 && 0>>22&0x3C@6>>16&0x01=0x00" -A INPUT -j DROP
  • 自ホストの応答 output でやる場合
    • iptables -m u32 --u32 "6&0xFF=0x1 && 0>>22&0x3C@0>>24=0x00 && 0>>22&0x3C@6>>16&0x01=0x01" -A OUTPUT -j DROP
    • iptables -m u32 --u32 "6&0xFF=0x1 && 0>>22&0x3C@0>>24=0x00 && 0>>22&0x3C@6>>16&0x01=0x00" -A OUTPUT -j DROP

確認方法

  • ホスト A から、 ping を ホスト B に対して打ち続け、意図したとおりの状況になることを確認する

ルール解説

6&0xFF=0x1 について

iptables の u32 が解析するのは IP ヘッダからになります。
まずは、IPヘッダのプロトコル番号から、ICMP パケットかどうかを調べます。
プロトコル番号一覧 - Wikipedia を参考に、ICMP の場合は、 1 であることがわかりました。

u32 では、0 を IPヘッダの先頭とし、1バイトずつスタート地点をずらし、指定した起点から4バイトを読み込むことができます。
プロトコル自体は、IPヘッダの先頭から10バイト目にあります。 そのため、 6 を指定し、 7 ~ 10 バイト目を読み込みます。
また、読み込んだ 4byte は、1つの4byte列として処理を行います。(これを1オクテットと呼びます)

例として ping を受ける側で tcpdump -x してみたところ、4000 4001(16進数) がターゲットに入りました。

  • 先頭 3bit がフラグにあたり、010 であることがわかります。
  • そこからの 4bit ~ 16bit までの 13 ビットがフラグメントオフセットで、 0 であることがわかります。
  • きりが良くなり 3byte 目がTTLで、0x40 であることがわかります。
  • 最後の 1byte がプロトコルになり、0x01 であることがわかります。

ここで、判定したい情報は最後の 1byte の 0x01 であるため、 0xFF で AND マスクを行います。すると、4byte に格納された情報は、0x00000001 に変わります
これが 6&0xFF までの処理で、あとはその値が 0x1 と等しいかを比較したいので、6&0xFF=0x1 となりました。

&& 0>>22&0x3C@0>>24=0x08 または 0>>22&0x3C@0>>24=0x00 について

さっきまでの内容で、とりあえず ICMP パケットだけを絞り込むことができました。
と言っても、ICMP は利用範囲が大きいので、 echo-reply のみに絞れる方法を探します。
ここでは、ICMP パケットのタイプを利用します。

  • ICMP の タイプが 8 なら echo-request となるため、ここで範囲を絞ります。
    • なお、応用として、 echo-reply で弾く場合は、ここを 0 と考えて、OUTPUT に仕込みます

さっきまでの処理は IP パケットの中身で行っていましたが、今度は IP パケットの先にある、ICMP パケットに踏み込まなければなりません。
しかし、IPパケットには、「オプション」というフィールドが存在し、可変長として定義されています。
そのため、なんとかして、「IPパケットのサイズを知って、その先に踏み込む」処理が必要です。

では、IPパケットの構造に戻ります。実は IP パケットの先頭 1byte の後半 4bit に、「ヘッダ長」というエリアがあります。
例として取得してみると、先頭 4byte が 4500 0054 でした。これだと、どうやらヘッダ長は 5 みたいです。
しかし、ヘッダ長は、「オクテット数」を記録しており、5オクテット、つまり 20byte 目までは IP ヘッダであることを指します。
先程の話で、 6 で 7 byte 目まで移動できると説明しました。つまり次はここに、 20 を投入できれば今回のケースでの 21byte目、つまり ICMP ヘッダに踏み込むことができます。
しかしながら、現在、0x45000054 という列を相手にしているため、現状だとマスキングするだけでは、 0x05000000 という馬鹿でかいものが手に入ってしまい、うまく使えなそうです。
ここで、シフト演算が登場します。 今回の例だと、 0>>24 みたいにすると、0x00000045 にデータ加工することができます。しかしこれではほしい 20 は手にはいりません。
ここで 20 を入手するためのちょっとしたテクニックなんですが、シフト演算の性質を利用して、 0>>24 せずに、 0>>22 することで、最初から ヘッダ長に 4 をかけられた状態を情報を入手しています。
しかし、そのままだと 「サービス種別」の先頭 2bit が紛れ込んでいるため、 &0x3C することでマスキングしています。

  • 0x3C は、 0b00111100 となり、中途半端にシフトされた 4bit からほしい真ん中だけを抜き出すことができます。

解説にここの処理についてはイメージを作りました。

f:id:do_su_0805:20181218072607p:plain
IPヘッダの先頭4byteイメージ

f:id:do_su_0805:20181218072612p:plain
>>22 したあとのイメージ

f:id:do_su_0805:20181218072754p:plain
&0x3C したイメージ

こうすることで、実質 && 20 から始まりそうなんですが、これだとまだ 20 という数値が手に入っただけで、移動できていません。

続いて、 @0 というのが出てきました。これは先程触れた、移動をしてくれる記号です。
@ のあとについている 0 は初期条件同様、移動先から何byte 目から読み出すかを示します。
今回はICMPパケットの先頭 4byte を読みたいので、0 から読み出すことにします。

これでやっと ICMP パケットに踏み出すことに成功しました。取得したパケット例では、 0800 eaea が記録されていました。

  • 先頭 1byte がタイプにあたり、今回は 0x08 であることがわかります。
  • 次の 1byte がコードにあたり、今回は 0x00 であることがわかります。
  • 最後の 2byte がチェックサムにあたり、今回は、 0xeaea に当たります。

ここから、欲しい情報である先頭 1byte を抜き出すために >>24 します。すると、 0x08 のみがやっと手に入りました。
ここで、ping の受け手の INPUT 時であれば、8 が入っているはずなので、 =0x08 で比較します。

  • これを、一旦 ping の Echo Request 自体は受けて、返答時に落とすという変わった方法を取る場合は、 ここが 0 になるため、 =0x00 で比較します。

ここまでの条件を使うと、ICMP の Echo Request をすべて落とすことができます。

  • iptables -m u32 --u32 "6&0xFF=0x1 && 0>>22&0x3C@0>>24=0x08" -A INPUT -j DROP すると、外からの ping はすべて落ちると思います。

0>>22&0x3C@6>>16&0x01=0x01

  • ここで混乱を招かないように解説ですが、 && で繋いだあとはスタート地点が最初の 0 に戻ります。

続いて、「奇数のときだけ落とす」を実現するためにICMPパケットを更に深堀します。

0>>22&0x3C@ までは先程と同様で、IPヘッダから IPヘッダサイズを取得して移動しています。
しかし、今回は、 @6 になります。これは、Echo Message / Echo Reply Message 時に利用される、「シーケンス番号」が 7byte - 8byte 目に含まれるためです。
@6 することで、 7byte ~ 10byte までの 4byte が手にはいります。これが 0>>22&0x3C@6 までのハイライトです。
ここから、シーケンス番号が先頭2byte にあるため、一気に >>16 で前半 2byte のみにします。
あとは、奇数かどうかを判定するだけなので、末尾 1bit が 1 かどうかを調べるので、 &0x01 でマスキングして、 0x01 かどうかを比較すれば終わります。
あとはお好きな CHAIN に、お好きなルールで投入してみてください。

動作確認結果

対向から ping を 10 発打って結果を確認しました。
下記に2パターンの結果を載せていますが、正常に動作していそうです。

  • 地味に奇数のみ許可時に 50% packet loss を表示させるのが難しい。素直にカウント指定を入れればよかったけど、勘でいい感じに成功しました。

偶数のみ許可時

  • iptables -m u32 --u32 "6&0xFF=0x1 && 0>>22&0x3C@0>>24=0x08 && 0>>22&0x3C@6>>16&0x01=0x01" -A INPUT -j DROP した状態です。
do-su-0805@ubuntu01:~$ ping 192.168.1.7
PING 192.168.1.7 (192.168.1.7) 56(84) bytes of data.
64 bytes from 192.168.1.7: icmp_seq=2 ttl=64 time=0.329 ms
64 bytes from 192.168.1.7: icmp_seq=4 ttl=64 time=0.325 ms
64 bytes from 192.168.1.7: icmp_seq=6 ttl=64 time=0.311 ms
64 bytes from 192.168.1.7: icmp_seq=8 ttl=64 time=0.320 ms
64 bytes from 192.168.1.7: icmp_seq=10 ttl=64 time=0.317 ms
^C
--- 192.168.1.7 ping statistics ---
10 packets transmitted, 5 received, 50% packet loss, time 9210ms
rtt min/avg/max/mdev = 0.311/0.320/0.329/0.017 ms

奇数のみ許可時

  • iptables -m u32 --u32 "6&0xFF=0x1 && 0>>22&0x3C@0>>24=0x08 && 0>>22&0x3C@6>>16&0x01=0x00" -A INPUT -j DROP した状態です
do-su-0805@ubuntu01:~$ ping 192.168.1.7
PING 192.168.1.7 (192.168.1.7) 56(84) bytes of data.
64 bytes from 192.168.1.7: icmp_seq=1 ttl=64 time=0.357 ms
64 bytes from 192.168.1.7: icmp_seq=3 ttl=64 time=0.367 ms
64 bytes from 192.168.1.7: icmp_seq=5 ttl=64 time=0.376 ms
64 bytes from 192.168.1.7: icmp_seq=7 ttl=64 time=0.379 ms
64 bytes from 192.168.1.7: icmp_seq=9 ttl=64 time=0.372 ms

--- 192.168.1.7 ping statistics ---
10 packets transmitted, 5 received, 50% packet loss, time 9209ms
rtt min/avg/max/mdev = 0.357/0.370/0.379/0.014 ms

2. 対向から curl をずっとし続けて、 ack 番号が偶数のものを drop する。

  • iptables -m u32 --u32 "6&0xFF=0x6 && 0>>22&0x3C@4&0x01=0x01" -A INPUT -j DROP
    • ルール自体は先程とだいたい類似するので、違うポイントを中心に紹介します。

実施方法

  • ホスト A から、 while で ホストB:80 に対して curl を 10発行い、実行ステータスを確認する。
    • この時、ホスト A で、tcpdump を取る

ルール考察

6&0xFF=0x6

先ほどと同じで、プロトコルを抜き出しています。これが ICMP では 1 でしたが、 TCP だと 6 になります。

0>>22&0x3C@4&0x01=0x01

先ほどと同じで、まずは IP ヘッダ長を取得し、ジャンプしています。
次に @4 しているのは、 TCP ヘッダの 5byte - 8byte が「シーケンス番号」のためです。
あとは &0x01 することで奇数偶数判定をしています。

結果

  • curl を 10発打って、ステータスコードで確認
    • 7 なら成功。28 なら失敗
    • for i in $(seq 1 10); do curl -s (target IP) --connect-timeout 1 || echo $?; done しました。
  • INPUT / OUTPUT 側で tcpdump で確認する。

    • なお、tcpdump のほうが先にパケットが通るため、後ほど iptables で弾こうが受け手側サーバでも確認はできる
    • 送信元の場合、 sudo tcpdump -v -vv tcp and dst (target IP) 2>&1 >> log & してから、ログをゴネゴネ
    • 受信元の場合、 sudo tcpdump tcp and src (source IP) 2>&1 >> log & してから、ログをゴネゴネ
      • (冗談みたいな話ですが、これやるとき tcpdump してればええやろーとルール投下後に ssh したら通らなくてそりゃ偶数弾くんだから確率で ssh も通らないわな・・・という自体が起きました。)
    番目 curl ステータス seq 番号
    1 7 228203506
    2 7 191816870
    3 28 1557318979
    4 28 3760951153
    5 28 3916607363
    6 28 2103122571
    7 7 3380433540
    8 28 4142152097
    9 7 2372256056
    10 7 1925275216
  • ちゃんと偶数のときだけ curl が成功していることがわかります。(ステータスが 7 なのはそもそも http サーバ立ててないからです・・・)

終わりに

いかがでしたでしょうか。そもそもが複雑というのと、うまい感じに表などが使えず分かりづらかったかもしれませんが、こういう機能もあるよ、と知っていただければ幸いです。

転職活動まとめ

TL;DR

目次

  • タイムライン
  • 必要なもの
  • 手続きについて
  • 転職に使ったアプローチについて

タイムライン

まとめ

  • Green / 転職エージェント / 友人経由の三方面で展開し活動
  • 3社内定をいただき、2社について辞退し現職に転職
  • 4社、面接/テストなどで不合格
  • 1社、面談を実施し、選考辞退
  • その他、書類選考で不合格になった会社多数

出てくる社名

  • 仮で A/B/C 等で呼んでいますが、実際の名前との関連はありません。
  • A社
    • 現職。Green経由
  • B社 / C社
    • 内定をいただいた会社。いずれもGreen経由
  • D社 / E社 / F社
    • 面接/テストなどで不合格になった会社
    • D社は知人経由
    • E社 / F社はエージェント経由
  • G社
    • 面談のみで辞退した会社
    • 知人経由
  • (未登場ですが)書類選考で不合格になった会社たち
    • エージェント経由

補足:エージェントについて

  • 結果的にエージェント経由ではすべて不合格でしたが、これは私とエージェント間での意思疎通がうまく図れてなかったことが原因と分析しています。
  • 自分のニーズとステータスがうまくアプローチできておらず、すれ違いになった様子でした。
  • 後述で詳しく触れます

活動タイムライン

  • @東京 とあるのは、東京への移動が発生しているケースです。
    • 現在大阪在住のため、遠距離移動カウントとして記載しています。
  • リモートで対応した場合はその旨を記載しています。
  • 特に記載がない場合は、関西方面のため近距離の移動が発生したことを示します。

2018/06

  • 06月上旬
    • 転職活動開始
      • 知人に相談し、「職務経歴書作るのに楽だから リクナビネクスト に登録しとくといいよ」と話をいただく
      • Green / リクナビネクスト に登録
      • リクナビネクスト経由で何社かエージェントから声がかかる
        • その中で、一番ちゃんとプロフィールを読んでくれてそうだった方と何度かリモート面談しつつ応募などをしてもらったり
  • 06/12 1社(B社)面談
    • リモートで面談
  • 06/22 1社面談(D社)/2社面接(E社1次/B社1次) @東京
    • E社については不合格
    • B社については合格し、2次面接へ
  • 06/28 1社プログラミングテスト(F社)
    • リモートで受験。不合格
  • 06/29 1社(C社)面談
    • 面談でしたがこの場で内定が出ました。

2018/07

  • 07/03 1社面談(A社)
    • リモートで面談
  • 07/04 1社面接(B社2次・最終) @東京
    • 07/06 内定をいただきました。
  • 07/10 2社面接(A社1次/D社1次)
    • A社については合格し、最終面接へ。
    • D社についてはリモートで面接。不合格
  • 07/13 1社面談(G社)
    • リモートで面談。辞退。
  • 07/25 1社面接(A社最終)
    • 07/26 内定をいただきました。

2018/08

  • 08/03 2社面談(A社/C社)
  • 08/07 1社面談(B社) @東京
  • 08/13 内定返答

転職活動で必要なもの

履歴書

  • 言わずもがなです。
  • 面接時などは大丈夫なことが多いですが、最終的に履歴書に印鑑が必要になることがあります。
  • 自分はフリーで転がっている履歴書でWordで作成しました。

職務経歴書

  • タイムラインで触れたように、リクナビネクストに登録して経歴入力をすると草案が word で吐き出されます。
  • 自分の場合はそれをベースに、知人に見せてもらった職務経歴書を参考に、下記項目で作成し、2ページにまとめました。
    • 職務要約
      • 今までの職務について文章ベースで簡略にまとめました。
    • 活かせる経験・知識・技術
      • 用語ベースで自分の知識を棚卸して列挙しました。
    • 職務経歴詳細

      • 表に職務の推移などをまとめて記載しました。
      • 職務要約より詳細に、実際にどんなことをしていたのか、みたいなのを期間と合わせて記載していきました。

        期間 主な職務内容
        2015/07 - 2015/12 hogehoge
        2016/01 - 2017/08 fugafuga
        2017/09 - 現在 fizzbuzz
    • 語学・実務経験

      • 何か日本語以外で語学についてtipsがあれば書きましょう
      • 自分の場合は特になかったため、TOEICの点数と軽くマニュアルが読める程度くらいとして英語の話を触れました。
      • ドイツ語を2年くらい授業で受けましたが忘れました…
    • 学生時代までのIT経験
      • これは自分で新設しました。参考にならない可能性があります。
      • 自己アピールの一環/つかみとして、幼稚園入るまでにワープロ3台ぶっ壊した(転じてそれくらいから触れてきた)みたいな話や、寮のネットワーク委員長やってたよみたいな話を書きました。
    • 自己PR
      • そのまんまですね。ここはよく考えたほうがよさそう
  • レイアウトとしてはこんな感じ
    f:id:do_su_0805:20181208215803j:plain
    職務経歴書

退職 / 入職にあたる手続きについて

  • 若干記憶が定かでもないのですが、覚えている限りでいろいろ書こうと思います。

健康保険について

大きく分けて、下記三種類が選べる気がします。

  • 継続する
    • すべての組合などで可能かはわかりませんが、私の場合は 退職後2年までは今のままで継続可能でした。
    • 保険料については会社の負担から外れるため、自己負担が2倍になります。
  • 国民健康保険に加入する
    • わたしはこの選択肢を選びました。選んだはずでした。
    • 健康保険資格喪失証明交付申請書というものが発行された後に、国民健康保険への加入手続きができます。
      • 私の場合は 08/31 退職で、この書類が 2018/09/16 くらいに届きました。
      • もう二日後に入社するなら不要やなと結局加入できませんでした。
    • だいたい 2週間くらいで次の職場に移る場合は、国民健康保険に入るそぶりでスルーするのがいいのかもしれません。
      • これだってどう考えても無理じゃない? 08月中旬に最終出勤だとしても結局 08/31 まで保険は必要で、09/01 に返却してやっと手続きはいるんだから絶対に空白期間が起きる気がする。
      • まぁ保険証発行されてから申請すれば差分返却できるはずなので、そういうことかな。
  • 家族の扶養に入る
    • この選択肢を選ぶ場合も、 健康保険資格喪失証明交付申請書 が必要です。

年金

  • 僕みたいに間が少ない場合は、次の会社に年金手帳の番号を提出するだけで手続きは完了しました。

雇用保険

  • 雇用保険番号というものが一番最初に入った会社で割り当てられています。
  • その番号が書かれた書類が入職後、個人保有なのか会社保有なのかわかりませんが、この番号を転職先に伝えると引継ぎがされます。
    • 一応、人事部/労務部などで管理はされているはずですが、あれどこやったかな・・・という人は今一度どこにあるかは探してもいいかもしれません。
    • 私は人事の方に教えてもらった後、会社のロッカーに埋まっているのを発見しました。
  • 資格喪失にあたり、離職票か、雇用保険資格喪失確認票 を受け取ることになります。
    • 失業保険を受給する場合は、雇用保険の資格喪失にあたって、 離職票 が必要になります。
    • すぐに次の職場に移るなどの場合は、退職する会社側の証明として念のため 雇用保険資格喪失確認票 くらいにとらえました。

住民税について

そもそも住民税というのは、年間で支払う額が決まっていており、それを分割して天引きされています。
僕の場合は、次の会社で引き続き天引きしてもらうという方法になりました。
そのほかとしては、「最後の給与から来年5月分まで一括で納付」「自分で納付する」が選べそうでした。

源泉徴収票について

  • 大体の会社は最終給与確定後に送付してくれると思います。
  • 僕の場合は事前に伝えていましたが、いずれにせよ発送はしてくれる様子でした。

入職時に必要になるもの

  • 大体ちゃんと指示が出ると思うので、忘れずに持っていきましょう

転職に使ったアプローチについて

  • 前述の通り、Green / 転職エージェント / 友人経由で転職活動を展開しました。

Green

転職エージェント

  • やはりプロということもあって、履歴書や職務経歴書のレビューや、ヒヤリングなどは充実していました。
  • 案件もたくさん出てきましたが、結果的に僕側はちゃんと現状を共有できておらず、すれ違った印象です。

友人

  • ありがとうございました。

まとめ

  • 特に何かを伝えたいというわけではないのですが、参考になれば幸いです。
    • 転職活動の空気感的なのが伝われば。
    • 何か困ってる人がいたらぜひ相談してください。

VLAN への理解がまだまだ甘そう(現状まとめ)

GS108Ev3 というスイッチで検証をしています。

現状

VLAN アサイ

  • VLAN1 / VLAN2 を用意
    • その状態で、Port 1 / Port 8 を両方に所属、Trunkとした。

ポート別

  • Port 2,3,6,7 は VLAN 1 にしました。
    • poprt 2, port 6 は U
    • port 3 , port 7 は T
    • (シッチャカメッチャカなのは挙動が怪しいので検証のため)
  • Port 4,5 は VLAN 2 にしました。
    • port 4 は U
    • port 5 は T

現状図示

VLANID \ PORT 1 2 3 4 5 6 7 8
1 T U T - - U T T
2 T - - U T - - T
Port 1 2 3 4 5 6 7 8
PVID 1 1 2 2 2 1 1 1

補足

  • ポートごとに選択できるのが下記
    • 空欄(エラーなどを見るに vlan allow から外す)
    • T (Tagged? Trunk ぽさもある)
    • U (Untagged ?)

状況について

  • Port 1 に、ルータ(NVR500) の LAN 側を設置
    • VLAN1とVLAN2 を通している
      • それぞれのVLANごとに違うセグメントのDHCPが動いている
    • これが正常なことは、別スイッチで以前確認した
  • Port 8 に WLX302 を設置
    • SSID で VLAN 2 を食わせたものがある
    • これについても意図通りの動作
  • この状況で、Port 2 ~ 7 をPCにそれぞれ結線したときの挙動が不思議
    • Port 4 のみ、DHCPでIPが降ってくる
    • 降ってくるIPについては、意図通りの VLAN 2 にいるはずの DHCP レンジ

明日以降整理すること

  • T は Tagged なのか Trunk なのか
  • 若干急ぎ足だったので一つずつ試してみよう

kosen10s LT#13 に行ってきた + LTしてきた

お久しぶりです。 題目の通り、Kosen10s LT#13 に行って、
珍しくちゃんと発表してきました。

kosen10s.connpass.com

今回は参加者20名(19名現地 + 1名リモート参加(!)) という結構集まったかな?という感じで、わいわいできました。 初参加の方も3名いらっしゃっていただき、これまた新鮮な会だったのでは?と思います。
発表資料は下のほうにも speakerdeck で公開していますが、あらかじめ見れるようにここにも貼っておきます。
speakerdeck.com

知らない人向けなざっくり Kosen10s って何?ということを説明すると、2010 年に高専に入学した全国の高専生(情報系が多いかな?) が slack でわいわいしたり交流したり、時には相談しあったり、こうやってLT会でわいわいしたりしている団体です。
2010 年に高専に入学した というのがミソで、中退/留年などは特に考慮していません。あくまでこのタイミングで入学したというポイントがそろっている集まりで、社会人も学生もいるし、いろんな人たちがいます。 故あって slack に入れる方法は今は公開されてないので、興味持たれた方はお声掛けいただくか、お近くの kosen10s っぽい人にお声掛けいただければ幸いです。
詳しくは、下記 Advent Calendar や、#kosen10s の日々のしょうもない日常について. - なっちゃんのめもがき。 などが参考になると思います。

adventar.org

adventar.org

ちなみに今年もアドベントカレンダーがあります!!

adventar.org

続きを読む

Amazon RDS for PostgreSQL が IAM 認証に対応したので試してみた

はじめに

2018/09/27 付の公開で、こんな記事が出ました。
https://aws.amazon.com/jp/about-aws/whats-new/2018/09/amazon-rds-postgresql-now-supports-iam-authentication/
Amazon RDS の PostgreSQL インスタンスで、IAM 認証ができるようになったみたいです。 早速試してみました。

やってみた

前提: 検証した環境

接続対象

手元

1. RDS for PostgreSQL インスタンスの作成

  • 今まで触ったことない人が初期状態で割り当てられる VPC だと疎通ができないので注意しましょう
    • VPC に IGW をアタッチしましょう
    • セキュリティグループで、接続元から許可を追加しましょう
      • 初期状態で allow されているのは、コンソールにログイン中の IP のご様子

2. IAM ポリシーの作成

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html

  • 日本語版を見ると小さく書いてあるので注意ですが、ユーザ名ないしはロール名 がDBのユーザ名と一致する必要があります。
    • ポリシーを作成後、割り当てるユーザの名前と、この後作る DB 側のユーザ名が一致するようにしましょう
  • また、未検証ですが、「あまりにも名前が長すぎる」とだめかもしれません。
  • ポリシー作成時、warning が出ますが、 RDS の MySQL インスタンスでも同じようになります。
    まだ IAM 認証自体がポリシー編集画面に統合されてなさそうです。気にせず行きましょう
  • ポリシーは下記の並び順になります。
    • rds-db な点、 dbuser な点に注意しつつ作成しましょう
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "rds-db:connect"
            ],
            "Resource": [
                "arn:aws:rds-db:リージョン:アカウント(数字):dbuser:リソース ID/ユーザ名"
            ]
        }
    ]
}

3. DB 側のユーザ作成

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.DBAccounts.html

  • インスタンス作成時に指定した DB の名前と、ユーザ名を使ってログインし、IAM 認証したいユーザを作ります。
    • 上記「IAM ポリシーの作成」で作成したユーザと同じ名前にします。
  • 以下は適宜読み替えてください
    • YOUR_INSTANCE_HOSTNAME : エンドポイント
    • masteruser : ユーザ名
    • testdb : DB 名
    • testdb1003 : 予め作成しておいた IAM ユーザと同じユーザ名
$ psql -h YOUR_INSTANCE_HOSTNAME -U masteruser -d testdb
ユーザー masteruser のパスワード:
psql (10.5 (Ubuntu 10.5-1.pgdg16.04+1)、サーバー 10.4)
SSL 接続 (プロトコル: TLSv1.2、暗号化方式: ECDHE-RSA-AES256-GCM-SHA384、ビット長: 256、圧縮: オフ)
"help" でヘルプを表示します。
testdb=> CREATE USER "testdb1003" WITH LOGIN;
CREATE ROLE
testdb=> GRANT rds_iam TO "testdb1003";
GRANT ROLE

4. 手元の準備

5. 接続準備

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.PostgreSQL.html - 上記がマニュアルですが、サンプルに誤りがあります。後述の手順では修正していますが、

export PGPASSWORD="$(aws rds generated-db-auth-token --hostname $RDSHOST --port 3306 --region us-west-2 --username jane_doe )"

とあるところの、 generated-db-auth-token は、 generate-db-auth-token が正しいです。ご注意ください。

5.1 まずは token 生成ができるかを確認

  • 以下は適宜読み替えてください
    • YOUR_INSTANCE_HOSTNAME : エンドポイント
    • masteruser : ユーザ名
    • testdb : DB 名
    • testdb1003 : 予め作成しておいた IAM ユーザと同じユーザ名
    • 5432 : ポート
    • --profile test : (aws cli でたくさん credentials を切り替えている人は、この方法が使えますという備忘録。)
$ export RDSHOST=YOUR_INSTANCE_HOSTNAME
$ aws rds generate-db-auth-token --hostname ${RDSHOST} --port 5432 --region ap-northeast-1 --username testdb1003 --profile test

すると、こんな感じの文字列が表示されます。されずに aws cli のエラーなどが出たら適宜見直してください

YOUR_INSTANCE_HOSTNAME:5432/?Action=connect&DBUser=testdb1003....(中略)
$

5.2 実際に接続してみる

  • 以下は適宜読み替えてください
    • YOUR_INSTANCE_HOSTNAME : エンドポイント
    • masteruser : ユーザ名
    • testdb : DB 名
    • testdb1003 : 予め作成しておいた IAM ユーザと同じユーザ名
    • 5432 : ポート
    • --profile test : (aws cli でたくさん credentials を切り替えている人は、この方法が使えますという備忘録。)
$ export PGPASSWORD="$(aws rds generate-db-auth-token --hostname ${RDSHOST} --port 5432 --region ap-northeast-1 --username testdb1003 --profile test)"
$ psql "host=${RDSHOST} port=5432 sslmode=verify-full sslrootcert=/path/to/rds-combined-ca-bundle.pem dbname=testdb user=testdb1003"
psql (10.5 (Ubuntu 10.5-1.pgdg16.04+1)、サーバー 10.4)
SSL 接続 (プロトコル: TLSv1.2、暗号化方式: ECDHE-RSA-AES256-GCM-SHA384、ビット長: 256、圧縮: オフ)
"help" でヘルプを表示します。
testdb=>
  • 注意としては、PostgreSQL のパスワードを打たない方法として、 $PGPASSWORD にパスワードを格納する か、 .pgpass ファイルに諸々記載する があると思いますが、後者はうまくいかなそうです。
    • 理由としては、(変更できるのかな)デフォルトの .pgpass ファイルのセパレータが : ですが、aws rds generate-db-auth-token が生成する token に : が利用されているからです。

おまけ:ログインできないときに RDS コンソールから見れるログから推察したこと

  • ログイン成功時
< HTTP/1.1 200 OK
  • ログイン失敗時(パスワード誤り/IAMポリシー誤りっぽい?)
< HTTP/1.1 403 Forbidden
  • ログイン失敗時(前述の ユーザ名が長すぎた か、 .pgpass に登録してしまってセミコロンが暴発した
< HTTP/1.1 503 Service Unavailable

以上、速報レベルですが、うまくできましたというログです。