なかっちゃんtech blog

勉強会とか日々の勉強の記録

IPv6 only な環境でUbutnuを使う

IPv6なネットワークで行きていく

IPv4がない,本当に純粋なIPv6環境でインターネットにつなぐことになった際に詰まったことがあったので,それらを書いていきます.

前提

ネットワークに接続するのはUbuntu16.04です.

あとアドレスはRAでふってきますが,上流の都合でDNSの情報はふってきません.あとでGoogleのPublic DNSを設定します.

やること1 DNSの設定

所々の都合でGoogleのPublic DNSを使うことに,アドレスわからんから調べてみるとこんなページが

developers.google.com

おっ あるやんけ,これ使おう. しかもアドレスが 2001:4860:4860::8888 とわかりやすいなーと思った. しかし,その下に何やらあった.

You can configure Google Public DNS addresses for either IPv4 or IPv6 connections, or both. For IPv6-only networks with a NAT64 gateway using the 64:ff9b::/96 prefix, you can use Google Public DNS64 instead of Google Public DNS IPv6 addresses, providing connectivity to IPv4-only services without any other configuration.

ふむ,IPv6 onluならNAT64を使うか,DNS64を使ってくれとのこと.「NAT64ってあれでしょ,v6をv4でどうこうするんでしょ? よくわからん」という状態.寄り道勉強楽しいんだけど,軽く本を読む程度にして,DNS64を使うことにした.

developers.google.com

というわけで,設定は 2001:4860:4860::6464 にしました.

やること2 リポジトリの変更

名前解決もできるようになったので,”次はapt updateだ!”といういつものノリで,コマンド叩いたけどまず "jp.archive.ubuntu.com"と通信できない.

"あれれ?"となったのでレコードの確認

$ dig jp.archive.ubuntu.com AAAA

; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> jp.archive.ubuntu.com AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40735
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;jp.archive.ubuntu.com.     IN  AAAA

;; ANSWER SECTION:
jp.archive.ubuntu.com.  589 IN  CNAME   ubuntutym.u-toyama.ac.jp.
ubuntutym.u-toyama.ac.jp. 7189  IN  CNAME   ubuntutym3.u-toyama.ac.jp.

;; Query time: 18 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sat Jan 26 23:53:10 JST 2019
;; MSG SIZE  rcvd: 113

なるほどなぁ AAAAレコード返ってきてないやん.

ぐぐってみるとこの記事を発見

ayacky.hatenablog.com

jaistのサーバに変更した.

これで全部うまくいくとおもった.

しかし, archive.ubuntulinux.com はどのミラーサーバもIPv4にしか対応していなかった.

んー なかなか厳しいですねぇ

とりあえず,タイムアウトまで待った.

まとめ

普段,使うものなのに,いろいろ詰まった. というわけで,IPv6 Only環境を想定した.各プログラミング言語フレームワークのサイトと,OSのリポジトリ対応状況を調べてみようと思います.

どこかでTLのネタにしよう

# 備忘録

ytooyama.hatenadiary.jp

www.vultr.com

ネットワークとプログラミングの話

この記事は 琉大情報工学科(知能情報コース) Advent Calendar の11日目です.

自己紹介

そこら辺の人も参加していいよということだったので,参加しました.

twittergithubを載せておきますね.

twitter.com

github.com

九州の学生です.

普段はネットワークの研究を主にやってます.あとはバイトでセキュリティと,フロントエンドをやったりしてました.

コミュニティ的なところで行くと,Perl入学式のメンターなどやったりしてます.(あんまいけてないけど)

こんな自称フルスタックエンジニア(笑)な僕が,普段はプログラミングをいっぱいしてであろう皆さん(勝手なイメージ)に少し,ネットワークのお話をしてみたいと思います.

もちろん講義みたいな話ではなく,ネットワークやインフラとプログラミングの調和みたいな話をしたいと思います.

ちなみにこんな流れで書くことになりました.  アナグラくんとはかれこれ2年くらい?の仲になってます??(あんま覚えてないや 3年?

ネットワークを知ると,どんなことがうれしいの?

まずは何が嬉しいかという話をします.

インターネットは今やつながるのが当たり前で社会基盤として存在しています.特に今の大学生の年齢だと,あるのが当たり前だと思います.僕もそうです.

ただ,ちゃんとわかっているかと言われれば,きっとそうではないと思います.

当たり前にあるし,IT=プログラミングみたいな風潮もあり,高校生まででネットワークしたいって人はまあまずいないんじゃないかな.

ただ,ある程度わかると,すごく楽しい.

そして,ニュースになるようなレベルの障害発生時はやることそっちのけで,自分で「普段のネットワークと比べてここがおかしいから,原因はこれか?」みたいなことができます.

大規模な接続障害、Googleが謝罪 「ネットワークの誤設定」原因

これを覚えていますか? 去年の8月に起こったゴタゴタになります.

ツイッターでは「Githubが繋がらないから仕事ができない」や「slackが死んだので仕事できない」みたいなツイートがよく見受けられました.

せっかく仕事できないので,エンジニアらしく原因追求しましょう.

そうすると「ツイッターではOCNが死んでる」という情報を得て終わりなんですが,実際にgithubにパケットを送って経路を確かめたりできます.

原因がわかるとすごい楽しい.まさに世界レベルでのデバック大会.

そんな世界だと僕は思っています.

ちなみに,ネットワークばっかりやるとどのプログラミング言語でweb appを書こうとTCPレベルでは,どの言語も変わらないぜ!!って思ってしまう.

アプリケーション側でどれだけ高速化の処理を行おうと,ネットワークが遅ければ,意味ないしな.

ここからさきはインフラとネットワークと意味を厳密に区別せずに話をします.なのでわかる方には違和感あるかもですが,ご了承ください.

どっちもいるの??

じゃあプログラミングとネットワークをどっちもやるのかという話になります.

実際のところ,どっちもできるひとはかなり少ないです.片方ならプロという方はいっぱいいるのが現状です.

そしてPaaSやSaaS,FaaSの出現でさらにネットワークを意識しなくてもよい機会が多くなっています.

じゃあネットワークわかんなくても,WebサービスをPaaSに乗せればサービス提供できるじゃん!と思うんではないでしょうか.

まあ実際そうなっていってるんじゃないかなぁと思います.

しかし,そんな中,インフラとプログラミングの両方を必要とするような仕事も出てきています.

今日はそんな2刀流な分野の紹介をしたいと思います.

前置きが長くなったけど,ここから本題 2つほどご紹介したいと思います.

Infrastructure as code

これはインフラをコード化する(そのまま)ことを言います.

これによってあるサーバの設定など(IaaSレベル)を冪等性がある状態を,「コード」を通して再現することができます.

これはネットワークというよりは,インフラよりな話にはなります.

しかし,「インフラ+プログラミング」をする分野になっています.

SRE

「Site Reliability Engineering」の略です.

Googleが提唱したシステム管理とサービス運用の方法論になります.

可用性の確保、レイテンシの低減、パフォーマンスの管理、作業の効率化、変更管理、モニタリング、障害対応、キャパシティ管理という管理業務に加えてソフトウェア開発を行う部隊になります.メルカリさんとかもあった気がします.

こちらも「インフラ+プログラミング」です.

まとめ

今,ご紹介したように,時代の進化とともに,なにか一つの分野だけというよりは複数分野を組み合わせた職業も出てきています.

そんなものに少しでも興味を持っていただけば嬉しいです.

ただ,知らないと興味を持つこともないので,この記事が誰かの興味を少しでも広げることができればいいなと思います.

ツイッターとか貼ってるのでよければフォローください.

QUNOG12参加してきた 

イベントから1週間以上空いてしまったけど,レポート投下(ネスペでバタバタしてました,ネスペの件はまた別記事で)

ここからは10/12日にあったQUNOG12に関する記事です!

QUNOGとは

一言で表すとJANOGの九州版です.

以下サイトから引用

QUNOG(九州沖縄地域ネットワークオペレーターズグループ)は、インターネットにおける技術的事項、運用に関する事項を議論、検討、紹介することを通して九州・沖縄地域の技術者および利用者に貢献することを目的としたグループです。議論や情報提供の場としてのメーリングリストと、年間3回程度一堂に会する場としてのミーティングを開催しています。

今回初参加してきました.(こういうコミュニティあるなら早く知りたかったw)

Preイベント

QTnetさんのデータセンター見学会に行ってきました.

DCの見学は初めてだったので,始まる前から楽しみにしていました.

サーバルームは研究室の面積広い版(配線きれいだったなぁ)くらいの認識でしたw

一番印象に残ったのは,すべてにおける冗長構成に関してでした.電気関係は全て冗長化,2系統で対応してすげえぇってなりました.(というかDC単位で冗長化ぇ)

たしかに,ここまですると,非常時も運用を停めることなく稼働し続けることができるのか... 社会インフラ支えてるな.....

QUNOG本編

本イベントは福大病院さんで行いました.(その前に福大でうろうろしてたらギリギリになったwww)

オリエンテーション

まずは,自己紹介と名刺交換タイム,いろいろな方とお話できました.QTさんやJRさんなどなど

あと,うちの研究室からQTさんに行った先輩ともお会いできたのでお話してました.

勉強会

福大NTPのお話

前々から,福大さんのNTPのトラフィックやばいので,やめるという話は聞いていましたが,それの最新情報でした.

あれの現況は国内のトラフィックがメインだと思っていたのですが,海外からのトラフィックだったとは.....

トラフィック量が減らすために,国際学会やNOGでどんどん,周知してました.

現状,サービスを停めるとトラフィック量が増えてしまうので,まずはアクセス数を減らすそう.

公開サーバの対応も大変だなぁという感想を持った

NTPの話

次はセイコーさんのお話.

NTPの基礎からだったのでわかるだろうと思ったら,意外と知らないことだらけでした.

一番驚いたのはNTPってUTCで値をもらってたんですね.....(確かにそうじゃないと福大のNTPに世界中からアクセスこないか....

ブロッキングの話

漫画村などの下りから,ブロッキングの話がでてくる経緯,最新情報まで,わかりやすい説明でした.

これ,どこまで書いていいかわからんなぁ(経緯は調べたらでてくるし

DNS暗号化

自分の勘違いが発覚したお話でした.DNSSECって暗号化するんだと思っていた..... あくまで正しいメッセージであることの担保だったのか.....

DNSの暗号化が,メッセージの暗号化をしていたんですね... 今まで嘘話していてしまったなぁと反省

あとは QNAME Minimisationの話が非常にためになりました.参考文献

DNSの問い合わせもプライバシーの保護の観点から守ろうみたいな風潮は感じていたので,それに利用できそうな技術だなぁと感じました.

こう考えると,UDP系のメッセージで外のネットワークにでるものも種類を考えないといけないのかぁ

通信の高速化のためにTCPからUDPみたいな風潮(QUICとか)から生まれたプロトコルはちゃんとTLSしてるから安心できるけど....

むずかしいなぁこういうの

終わりに

初参加で,懇親会まで参加させていただいて,勉強になったし,なりより,たくさんの人と話せたというのが大きいです. この調子で人とのつながりを広げていきたい

ps: うちのネットワーク研からも何人か,来ていたのでいい感じの雰囲気になってるなぁって思いました.次は懇親会まで連れて行こうw

slack化といい,イベントに参加といい,いい流れだなぁ

JANOG42を終えて(技術感想編)

はい

nkchan-diary.hatenablog.com

全日程終了して,若者支援関係の書類も書き終わった.

YAPCとは違い,JANOGの若者支援は運営側にレポートを提出があります.(YAPCもブログがあるけどねw)

しかしA4 1枚程度という制限が....

足りません!というわけでいい足りないことをこちらで書きたいと思います.

中国のネットワーク事情 :: JANOG42

こちらはSBクラウドとチャイナ・モバイルの方の中国と日本の通信を題材に話をされていました.(グレートなんちゃらって言ってたの笑ってしまった.)

現状,中国と日本の通信は非常に値段が高いのに,パケロス,レイテンシの値が大きいというのが問題視されていた.(アメリカなどの第3国を経由するとレイテンシ以外は安定するそう.)

あと中国国内でECサイト運営するのにライセンスいるんですね.....

この2つってかなり事業者としては辛いとこですね.

この障壁を乗り越えてalibabaさんがやってるのが中国国内のCDNに重たいコンテンツを置いておいて,HTMLなどの軽いコンテンツは日本から送信するという手法でした.うまいなって思いました.さすがCDNって感じの使い方だと思いました.

SD-WAN立ち上げから1年 チャレンジしたこと、苦労したこと :: JANOG42

こちらは最初にお腹いたくてお手洗いにいってあんま聴くことができなかった.しかしインターネットブレイクアウトという言葉だけは全力で持ち帰ってきた.まずこの言葉の勉強が必要だろう.

cloudwan.nttpc.co.jp

www.atmarkit.co.jp この2つの記事であらかたの概要と利点は理解できた.トラフィックの種類(アプリレベルかな)で各拠点からでていくか,本社のFirewallを通過するかというのが分けられるのか.すごいな,たしかにこれならトラフィック調整がきく.どうせクラウドとはVPC的なのを張ってるはずなので本社Firewallを通る必要ないしね.

その運用自動化では行き詰まる ~「つながらない」「つたわらない」「つみあがらない」を防ぐために~ :: JANOG42

これですよ.一番聞きたかったのは. 普段からいかに下の代につなげるかってのを気にしながら研究室のサーバ周りをしている.

まず大前提として自動化は「やってみないとどうなるかわからない」「一周してからが勝負」とのことでした.たしかに,一通りやってみて,問題点を調べて再調整なんて全然ある話ですしね. 「一旦自動化したらあとは面倒を見なくていいわけではない」心にぐっとくる....

「自動化しても自動化した人がシステムの奴隷になる 」 コードを書いた人にしか細かいとこを意図はわかりませんからね...(なお当時の自分に発狂する模様)

「賞味期限が長く,何度も行う,退屈な作業は自動化してok」 賞味期限をどれくらいにするかがキモ あとドキュメントをちゃんと残してないと作り直すときにリバースエンジニアリングが始まる

面白かったのが「手動化に戻すことができるようにするとこまでドキュメントにしておく」という点でした.たしかに,手動化に戻すところまでマニュアル化しておけば有事の際もきちんと動かすことができるなぁという感想をもった.

疲れたのでいったんここまで,気が向いたらまた書きます

togetter

まとめてくれたかたお疲れ様でした! togetter.com