t-hom’s diary

主にVBAネタを扱っているブログです。

最近のLEGOが、私の知ってるやつと違う件

最近LEGOというオモチャを手に入れたので、少しずつであるが遊び始めている。

そう、あのLEGOである。


あの。。あれ?こんなんだっけ。。
youtu.be



。。。


いい歳した大人がレゴなんて!と侮るなかれ。
最近のレゴは凄いんだ。

私が買ったのはTHE LEGO MINDSTORMS EV3というもの。


Amazonで新品を見ると7万円くらいの値段がついててぶったまげる。お前、、そんなにか??プレステより偉いのか??

ということでメルカリへGo。
無事に2万ちょいでGet。

あとアイデアブックという書籍をAmazonで調達。一応洋書だけど「イケアの説明書かよ」ってくらい図しかないので読めなくても大丈夫。

これ見ながらギアの組み合わせとか、機構の学習中。

これ、パーツカラーが実物と書籍で違ってて、たぶんロット違いというかバージョン違いだと思うんだけど、すげー探しづらいのが難点。

さて、実はもともとLEGOがやりたかったわけじゃなくて、機械工作系のスキルが欲しかったのがきっかけである。
趣味のものづくりに役立つような工作系スキル全般に興味があって、このブログでも2019年末頃から雑多に扱ってきているんだけど、現状のスキル認識としては下図の黄色のレーダーチャートといったところ。これを赤の点線くらいまで引き上げたいんだけど、機械工作系だけはさっぱりだったので、ようやくスタートラインに立てた。

※これだけ見ると全然仕事出来ねぇポンコツに見える。。いや、違うんだ。。私の本業はIT統制なので、このチャートはあくまで趣味の話だ。あとVBAならたぶん5。

機械工作というよりは、マシン機構系に興味があるという感じかな。



他にもパーツをメルカリで買ったんだけどそっちは微妙に臭いがついていたので台所用洗剤とぬるま湯で超音波洗浄。

よく水で濯いだら最後に精製水で再度超音波洗浄。

精製水は回路基板製作のテストで使った化学実験器具の洗浄用に買ったのだが、不純物が取り除かれているため自然乾燥させても水垢が残らないという特徴がある。

レゴのような細かいパーツはいちいち拭いてらんないので、これを使って自然乾燥させようという作戦。
10本追加購入したけど、今回の案件で既に5本使用してしまった。

あとはひたすら地獄の選別作業。。

そんなこんなありながら学習を進めていくと途中で知らない子に遭遇。

ナニコレ、そんなパーツ入ってねぇけど??
しかもこの本、図しかない弊害でパーツ名でググろうにも何てやつなのかさっぱり。

で、色々調べてるとどうやらTHE LEGO MINDSTORMS EV3には拡張パーツセットなるものがあるらしい。。

え?また2万??

悩んだけど、まぁスキップするのもの気が晴れないので結局購入した。

メルカリでも1万5千円とかだった気がするけど、また洗うのも手間だしこれくらいの値段差なら新品で良いかなという判断。

ということで暫くチマチマと学習を進めていこうと思う。

一応、THE LEGO MINDSTORMS EV3は本体からサーボモーター等のパーツをプログラミングで動かすことができるのでこれだけでロボット工作もできる。ただ私はオモチャとしてのロボットそのものはあんまり興味なくて何か実用的なモノを作るために基本的な機構の学習がしたいという動機なので、あんまりプログラミング機能を活用ってことは今のところ考えてない。

今の私のスキルでは作れないけど、将来的にはベルトコンベアを使ったキーキャップを並び替える装置を作ってみたいなぁと思う。
キーボードって割と短期間で汚れるのでよく洗浄するんだけど、最後にキーをはめる作業が超大変なので、機械学習で文字認識させてQWERTY順に並び替えてくれるマシンとか作れないかなぁと。まぁ、まだこの夢は遠いんだけど。

ビジネスとしては成立しないけど、自分は欲しい。そういうのを好き勝手に作れるのがモノづくり趣味の醍醐味なので今後もスキルを磨いていきたい。

以上。

GWに50時間を費やしたゲーム、Satisfactoryについて

今年のゴールデンウィーク、起きている時間のかなりをSatisfactory(サティスファクトリー)というゲームに費やした。
このゲームはかなり面白いので、ちょっと紹介してみようと思う。


Satisfactoryは異星に工場を建設してひたすら製品を製造しつづけるというPCゲームで、一応最上位のプロダクトは存在するもののこれといってゴールはない。

クラフト要素、建築要素、冒険要素などがあるけど、中核の要素は工場のオートメーション。
クラフトマシン同士をコンベアベルトで接続して素材から部品、最終製品まで自動で製造することを目的としている。

最初期はこんな感じで手で鉄を掘る。

そして加工も最初はハンドクラフト。

しばらくするとポータブル採掘機が作れるようになり少し効率が上がる。

ゲームを進めると次のようにマシン同士をつないで全自動でプロダクトが生成されるようになる。

ただ、この初期の自動化工場はまだまだ効率が悪い。
どういうことかというと、マシンによって1分あたりに処理できるアイテム数に違いがあるので一番遅いマシンがボトルネックとなって生産ライン全体の足を引っ張ってしまうのだ。
今回の場合、採掘機のほうは鉱石を1分間に120個掘り出すことができる。
一方で今使っているベルトはアイテムを60個までしか運ぶことができず、更に製錬炉は1度に鉱石30個までしか処理できない。

効率を上げるには、ベルトをアップグレードして、分岐機を使って製錬炉を並列で動かせばよい。

このように、実際の工場で考えなければならないような各ラインの生産量調整がこのゲームの難しさであり、また醍醐味でもある。


しばらくすると土台を建築できるようになり、コンベヤも90度ターンさせるなど審美性に拘ることができる。

ここに壁や屋根をつければ小さな工場の完成だ。

そしてゲームを進めるにつれ新しい製品を製造できるようになるが生産ラインは複雑化し、工場はどんどん大規模になっていく。

今回ゴールデンウィークで取り掛かったのはターボモーターという製品を生産する工場。
現時点でこのゲームの最上位クラスの製品なので生産ラインは非常に複雑になる。。

更に、どうせ作るなら何かこだわった形の工場にしたいということでデザインに凝った結果、割とマシンをギチギチに詰め込むことに。。

写真ギャラリーとしていくつかご紹介。

外観はこんな感じ

1階の製作フロア

2階の原材料精錬フロア

屋上の原材料搬入ドローンポート

地階の原材料搬入貨物駅


ここまで、生産ラインの複雑さに比べてスッキリして見えたと思うけどそれは搬送路の大半を0.5階の搬送専用フロアと、地階に押し込んだ為だ。

サードパーティー製のツールでみたときの工場マップがこんな感じ。

かなり複雑怪奇で何のこっちゃ分からなくなっているけど、形としては結構面白い工場になったんじゃないかなと。

コンベヤラインだけを表示させるとこんな感じ。

この規模になってくるとゲームとはいえちょっとしたプロジェクトである。
頭で考えながらでは無理があるので、Excelで管理表をつくり、

Redmineでプロジェクト管理しながらなんとかGW内に稼働にこぎつけた。


まぁターボモーターはこのゲームの集大成に近いようなプロダクトなので極端な例である。
正直途中から仕事じみてきてしんどいこともあったけど、大きな達成感を得られることができたので大変満足度の高い休暇だったと思う。

興味を持った方はYouTubeでいくつか実況動画。日本語だと「らくしげ」さんの動画がおススメ。
PCスペックの関係で自分でプレイできない方も実況動画見てるだけでもそこそこ楽しめると思う。
youtu.be


さて、最後にこれまで建設した工場の写真をいくつか貼って記事を終わろうと思う。
いまのところゲームブログに転向する計画はないのでこういう機会に貼っとかないと人に見せる機会もあんまりないだろうし。

こちらはバッテリー工場。空輸ドローンはバッテリーを消費するのでこの工場で生産して、ドローンで各地に届ける。

中はこんなかんじ。

次に一応自宅として使っている基地。バッテリー工場の崖を上ってすぐのピンクの森の端にある。

中は特段なにもないけどベランダからの眺めはお気に入り。


こちらはかなり初期に作った小規模な基本パーツ工場。

床用のコンベアリフト穴がゲーム内に実装される前に作った工場で、アイテムの上下移動は壁伝いにリフトで運んでいる。今となっては逆に特徴的な外観なのであえてこのまま残すことにした。


実はかなり最近まで壁を作るのが面倒で以下のように廃墟のような外観でずっと使っていたが、Update 5が来たときにコンクリ壁やいい感じの窓が実装されたので外観をきれいにした。

次に最近建設した石油発電所。こちらは海上に土台を敷き詰めて160機の石油発電機を脳筋で置いて行った感じ。

発電所は他と比べると単純なので作りやすかったけど、唯一水中でのパイプ引き回しに苦労した。

あと作りかけで放置し、先日解体した原子力発電所。
こちらはUpdate 4の頃に作っていて、50時間くらいかかっていたと思う。



当時はマシンとコンベアが干渉できず、隙間が空いているように見えても実はマシンがもつ立方体の干渉不可エリアでブロックされていてベルトを通す隙間が無いなど、技術的な理由でかなり苦労した。
ほぼ完成に近かったんだけど、Update 5で土台や壁の選択肢が増えたため今となっては古めかしく見えてしまい、放置していた。先日このあたりのバイオームの再開発が発表されたので思い切って撤去した。


最後はスーパーコンピューター工場。

アスファルトの土台が実装されたので道を整備してトラック輸送を活用した拠点だ。

スパコンもターボモーターと同じくらいハイレベルの製品なのでそれなりに複雑な搬送路になってしまう。

ただフロアが沢山あるので、念のためギチギチに詰め込んだら割とどのフロアも片側に寄っていて反対側はスカスカだったりする。


さて、今回の記事はここまで。
それではまた。

休日を有意義に過ごそうと焦る必要は無いという話

さて、昨日から連休に入った。
昔はまとまった休みが取れると何かしなくてはと焦り、連休の終わりに特に何もできなかったことを悔やむというパターンに陥っていたことがある。

同じ轍を踏む人を少しでも減らすべくここに私の考えを残そうと思う。


まず、折角の休みなので有意義に過ごしたいという焦りを覚えている時点で、恐らくあなたは疲れている。
元気があり余っている人は、そもそも既にやりたいことを計画してそれを始めているはずで、有意義に過ごしたいなどという焦りとは無縁だからだ。

休日とは読んで字のごとく、休む日である。
好きな物を食べて、惰眠をむさぼる。これで十分有意義に過ごしたと言える。
無理に何かしなくてはと焦る必要はないのだ。

私は連休の度に「何も成さない」ことを目標にしている。すると不思議なことに2~3日休むと自然とやりたいことが見つかり、それを始めてしまう。まあこれはこれで十分に回復したという証拠なので良い。

あるいは短い連休だとそれで本当に家でダラダラしているだけで終わってしまうこともある。
そういうときは喜ぶべし。目標は完遂されたのだ。休日を100%休むことに費やした。これ以上に有意義なことがあろうか。

そもそも、年に数回の連休ごときで成し遂げられることなんて高々しれている。
何かを成し遂げるためにはやはり年の大半を占める平日に短い時間でもコツコツやるのが一番。そして休日は義務感から解放され、心身のコンディションを整えることに専念するべし。

それでも折角の休みに何もできなかったと感じてしまう人は、「ぼーっとする時間」「何もしない時間」などと検索してみると良い。それらの有用性を示唆する記事が多数見つかる。

もちろん、やりたいことがあって気力が充実しているのに無理に何もしないことを推奨しているわけではない。
平日が義務に従う日だとすれば、休日は心に従う日。何かやりたいことがあればどんどんやれば良い。

でも、もともとやりたいことだったはずなのに、気が乗らないとか、それが焦り、プレッシャーになっているなと思ったらいったん落ち着こう。それは義務ではない。いつだってやめて良い。

それでも、何もやりたいことが見つからないないのに退屈だなぁ、でも眠くもないなぁ、何かしたいなぁ、と漠然とした焦燥感に駆られることがある。最近はもう、それも受け入れてしまえば良いと考えることにした。まぁいいや、どうせ休日だしと。
「何も成さない」ことを、あえて高らかに宣告するというのはつまりそこを出発点にすれば焦ったり後悔したりはしないという判断である。

ここ数年ずっとこの方針で休日を過ごした結果、この判断は正しかったと確信している。

さて、締めの言葉が思いつかないが、眠くなってきたのでそろそろ寝よう。
別にブログは趣味で書いてるんだし、締まらない回があっても良いだろう。
これこそ有限実行である。

以上。

自宅Wifiに接続された不明な機器をMACアドレスから特定する

先ほどWifiアクセスポイントで設定をいじっていたら、接続中のクライアントにIP Address 0.0.0.0と表示される謎の機器が存在することに気づいた。ナニコレ怖い。

侵入か!?いやセキュリティは万全のはず。

ということで表示されたMACアドレスから調べることにした。

MACアドレスとは

MACアドレスとはネットワーク機器に付与される固有のアドレス※で、同一ネットワーク内の通信に用いられる。

※正確にはネットワークインターフェースごとなので、LANポートの数だけ、あるいは無線と有線があればそれぞれMACが異なる。
※TP-LinkやHuaweiなど、一部企業が固有であるはずのMACを使いまわしている実態があるので、そうした会社の製品は必ずしも固有とは言えない。

そして先頭の6桁はネットワークインターフェースのベンダー※ごとに付与される固有の番号なのでこれを検索すればそのネットワークインターフェースがどの会社の製品か分かる。

※本体機器メーカーと同一とは限らない。

調べてみた

今回は8c:aa:b5ということで検索すると、上海の企業 Espressif Inc. というところらしい。
maclookup.app

何その聞いたことないメーカー怖い。

と思って調べてみると、こんなロゴが出てきた。

あ!これ何かの基盤で見たことある。

と思って電子工作パーツを漁ってみたところ、見つけた!

あぁ、Espressifって、あのESPか。なるほど。

てことは今ネットワークに繋がってるESPモジュールといえば、、M5 Stackだな!

あとはM5 Stackの電源落としてみてクライアントから消える、電源入れたら復帰することを確認し、確定した。
StaticでIP振ってるはずなんだけど、なぜWifi-AP上にIPアドレスが表示されないのかは謎。
ひょっとしたら私のコードがまずくて標準的な無線接続の手続きを取っていないのかもしれない。。

ということで解決。

おまけ知識

MACアドレスはスイッチングHUBで使われるアドレスだから、家はルーターに直接つないでるからMACは関係ないみたいな誤解をしてる方がいて、何事も中途半端にかじると厄介だなぁと思ったので、家庭でよく使われる無線LANルーターの内部構造(想像図)をご紹介。

厳密な構造はメーカーではないので分からないけど、無線LANルーターって要するに複合機器なので、直接指してるそれはスイッチだし、Wi-Fi接続も内部APを通じてスイッチ機能に繋がっていると思われる。

このスイッチに繋がれた区間は宛先IPアドレスは相手の宛先MACアドレスを調べるための手がかりとして使われているだけで、スイッチはIPアドレスを見て転送してるわけではない。

なお、ルーターはIPアドレスを見て転送先を決めるが、ルーター同士の実際の転送はやはりMACアドレス宛なので、機器同士の直接通信はどこまでいってもMACアドレスというのが事実。

なので家庭内にMACアドレスが重複する機器が2台以上あると、まともに通信できなくなる。

最近高性能な割に価格が安くて人気のTP-Link、ガジェット系YouTuberがよく宣伝してるので皆さんも気になっている方いるかと思うけれど、上記の前提を理解したうえで以下の記事を読むと、この騒動がよく理解できるかと思う。
www.itmedia.co.jp

このメーカー、他にもなんか怪しいので、私は個人的にはおススメしない。
anonymous-post.mobi

これ知る前に同社製のUSB-有線LANアダプター買ってしまったけど。

VBA × Network学習:プレフィックス長からサブネットマスクに変換する

今回は久々にVBA。
ネットワーク学習で苦手なサブネット回りの計算をしてみようと思う。

IPアドレスとサブネットマスクを表記する方法として、プレフィックス長表記(またはCIDR表記)という方法があり、たとえば192.168.1.0/24と書くとIPアドレスが192.168.1.0でサブネットマスクは255.255.255.0という意味になる。

IPアドレスやサブネットマスクの実態は32ビットのデジタルデータ(二進数)で、これを8ビットずつに区切って10進数で表されている。
255.255.255.0はそれぞれ2進数に直すと、11111111.11111111.11111111.00000000となる。このとき1が先頭が24個並んでいるので/24という表記になっているわけだ。

この表記は簡潔に書けて良いんだけど、ネットワークの学習をしているとパッとサブネットに直したいときがある。

これが/8、/16、/24など、都合よくドットの区切り目でわかれているようなケースはナチュラルマスクといって、255か0で構成されるので覚えるのも簡単だが、中途半端な位置で切れていると変換するのもなかなか大変。

ということでVBAコードを書いてみた。

Sub PrefixLengthToSubnetMask()
    Dim i
    For i = 0 To 32
        Debug.Print "Prefix /" & i, Subnet(i)
    Next
End Sub

Function Subnet(prefix) As Variant
    '最後にJoin使うためにあえて数値ではなくVariantで配列宣言
    Dim subnet_(1 To 4) As Variant
    
    Dim octet As Integer
    Dim bit_in_octet As Integer
    Dim current_bit As Integer
    
    For octet = 1 To 4
        'Variantなので0で初期化しないとブランク文字になってしまう。
        subnet_(octet) = 0
        For bit_in_octet = 0 To 7
            current_bit = current_bit + 1
            If current_bit <= prefix Then
                subnet_(octet) = subnet_(octet) + 2 ^ (7 - bit_in_octet)
            End If
        Next
    Next
    Subnet = Join(subnet_, ".")
End Function

余談だけど最近はラズパイとかLinuxでのpythonコーディングが増えて変数名はスネークケースの方が読みやすく感じてしまう。
どっぷりVBAに漬かってた頃はキャメル・パスカルが読みやすいと考えていたんだけど、今書いてみると単なる思い込みだった可能性が高いと思い始めた。

当時VB.Netのコーディングガイドライン本だったり、Microsoftのコードだったりを参考にガイドラインを作ったんだけど、現時点ではキャメル・パスカルについては先例を踏襲したという以外にそうする理由を見いだせない。自分で過去に書いたガイドラインから思い切り違反しているのでガイドラインの方を改定してしまいたい気持ちもありつつ、VBAコミュニティはキャメルケースとかパスカルケースが主流だと思われるので悩ましいところ。

さて、実行結果は次のとおり。

Prefix /0  0.0.0.0
Prefix /1  128.0.0.0
Prefix /2  192.0.0.0
Prefix /3  224.0.0.0
Prefix /4  240.0.0.0
Prefix /5  248.0.0.0
Prefix /6  252.0.0.0
Prefix /7  254.0.0.0
Prefix /8  255.0.0.0
Prefix /9  255.128.0.0
Prefix /10  255.192.0.0
Prefix /11  255.224.0.0
Prefix /12  255.240.0.0
Prefix /13  255.248.0.0
Prefix /14  255.252.0.0
Prefix /15  255.254.0.0
Prefix /16  255.255.0.0
Prefix /17  255.255.128.0
Prefix /18  255.255.192.0
Prefix /19  255.255.224.0
Prefix /20  255.255.240.0
Prefix /21  255.255.248.0
Prefix /22  255.255.252.0
Prefix /23  255.255.254.0
Prefix /24  255.255.255.0
Prefix /25  255.255.255.128
Prefix /26  255.255.255.192
Prefix /27  255.255.255.224
Prefix /28  255.255.255.240
Prefix /29  255.255.255.248
Prefix /30  255.255.255.252
Prefix /31  255.255.255.254
Prefix /32  255.255.255.255

ポイントはコード中の以下の部分。

If current_bit <= prefix Then
    subnet_(octet) = subnet_(octet) + 2 ^ (7 - bit_in_octet)
End If

ちょっと分かりにくいと思うのでPrefix /29の場合を例に最後の8オクテットを図示したものを張っておこうと思う。

今後の展望

今回ご紹介したのはIPアドレス・サブネットマスク回りの様々な計算を実行できるクラスモジュールを作りたいという目的の一部分である。
今後記事にするかどうかは分からないけど、とりあえず自分用の計算クラスを作るところまではやってみようと思う。

以上

IT技術全般において概念モデルは比喩ではなく本質だという考察

最近ネットワークの学習をしていて思うのが、10年前の私はよく概念モデルで躓いていたなということ。たとえばOSI参照モデル等。
学習が遅々として進まなかった原因として、概念モデルが登場したときにいつも腑に落ちず苦痛を伴っていたことを思い出した。

当時の私は実装こそが真実であり、概念モデルはそれを分かりやすく説明するための単なる比喩表現に過ぎないと勘違いしていた。
しかしそんなものを見せられても一向に実装がイメージできない。実際にどうなっているのか、どのように実装されているのかを理解できなければ分かったことにならないと思い込んでいたのだ。

たとえばTCP/IPモデルでいえば、層という概念が実際にどう実装されているのか、まさか図の通り積みあがっている何かがあるわけではあるまいし、だとすればどうなってるんだ。層ってなんなんだ!分からん、何も分からん!といった具合。


この考え方が変わったのは、ブログでVBAを説明し始めた影響が大きい。
ちょうど以下の記事を書いた頃から、実装は単なる手段なので本質とは違うのではないかということに気づき始めた。
thom.hateblo.jp

新しいIT技術を考えだすプロセスとしては、(1)まず目的があり、(2)それを達成するための仕組みを考え、(3)それを実装に落とし込むという順序になると思う。

つまり(2)で考えられた仕組みの本質を抜き出したものが概念モデルであり、仕組みを学習して理解するという点に置いては概念モデルの理解がゴールなのだ。
これに気づいたことで、まずは与えられた説明を受け入れて学習を前に進めるということが出来るようになった。

もちろん、実装を学ぶフェーズもある。
概念モデルはその実装によって様々な現実的な制約を伴ってくるので、理解を深めるうえで実装を知ることは避けては通れないが、それは必要になった時に学べば良い。

以上

VLANで分割した自宅ラボターミナルサーバーへTELNET接続できなくてハマった件

今回はVLANによるネットワーク分割でハマった件と原因・解決策について備忘禄として残しておく。

VLANとは

VLANの前提となるLANはローカルエリアネットワークの略で、基本的には同じスイッチ(ルーターのスイッチポート含む)に直接つながっている機器同士がMACアドレスという機器固有のアドレスを使って通信する様子をイメージしてもらえれば良いかと思う。
(スイッチがスタッキングしてたり、色々と例外もあるんだけど。)
※LAN内でもIPアドレスは参照されるが、一旦IPアドレスを元に相手のMACアドレスを特定して実際の通信はMACアドレスに宛てられる。

VLANとはVirtual LANの略で、物理的なスイッチポートに囚われず、仮想的にネットワークを区切ったり、統合したりできる。

例えばVLANで一つのスイッチに繋がれた機器を2つのネットワークグループに分割すれば、これらのネットワーク同士はもはやMACアドレスで通信することはできなくなる。

そこで登場するのがルーター・L3スイッチなどのIPアドレスでルーティングをする機器。
一度分割したネットワークもこれでまた接続させることが出来る。

なんでそんな面倒なことをするかというと、LANの中は基本的に機器同士が常時おしゃべりをしてるので、適当にグループを分けてやらないと無駄話が飛び交って仕事が進まなくなるためだ。ただ別のグループへも必要な連絡事項は通す必要があるので、ルーターの出番という訳。

今回分割したネットワーク

今回はメインPCが所属するメインのネットワークから、Ciscoの検証用ネットワーク機材を管理するためのターミナルサーバーを切り離してみた。

f:id:t-hom:20220417162058p:plain

我が家のメインスイッチCiscoのCBS250にはVLANの機能が付いている。そしてCBS250はL2スイッチングだけではなく、L3ルーティングも部分的に対応しているのでネットワークを分割してもVLANを跨いで通信ができる。
特にアクセス制御リストで拒否設定等しないかぎり、問題なく通信できるはずだった。

設定内容

CBS250

既存のVLAN1に加えてVLAN99を作成してIPアドレス192.168.99.1を付与、ターミナルサーバーが接続されたポートをVLAN99に所属させた。

ターミナルサーバー

IPアドレス192.168.99.2を付与し、デフォルトゲートウェイを192.168.99.1に設定。

NTT ホームゲートウェイ

192.168.99.0/24ネットワーク宛ての通信が来たら192.168.1.254へ転送されるようルーティングを設定。

ハマったところ

同じネットワークに所属させていたときは通信できていたのだが、ネットワークを分けたことでTELNET接続してもブランク表示されるようになってしまった。

Wiresharkでパケットを見てみると、3WAYハンドシェイクの後TCP再送が繰り返されている。
f:id:t-hom:20220417161657p:plain

WindowsファイアウォールをOFFにしてみると、ちゃんと通信できることが分かった。
f:id:t-hom:20220417161737p:plain

しかしメインPCから開始した通信なのになんで手元のファイアウォールで蹴るのかさっぱり分からない。
ターミナルサーバーからしたら通信したいと言われてデータ送ったら捨てられるとか意味不明。。

原因

メインPC側で返信が破棄されてしまう原因は、往路と復路が違うためにファイアウォールが自分が送った通信の返信だと判断できずにデータを捨てていたっぽい。

経路をa~hの記号で図示してみた。
f:id:t-hom:20220417162902p:plain

(a) メインPCは192.168.99.2宛てに通信しようとするが、その時点で自分と異なるネットワーク宛てだと分かるので、デフォルトゲートウェイであるNTT-ホームゲートウェイのMACアドレスに宛ててフレームを送る。

(b) Cisco CBS250はMACアドレスをみてフレームをNTTホームゲートウェイへ転送する。この時点ではL2スイッチとしての仕事しかしてない。だってMACアドレス的には俺宛じゃないし。。という理屈。

(c) NTTホームゲートウェイは自分のMAC宛に届いたフレームからIPパケットを取り出して、自分が持ってる経路情報を確認。次の宛先がCBS250であることを知る。そこでCBS250のMACアドレス宛にフレームを転送する。もし人格があれば「おいCBS250、お前のとこやん」て思ってるはず。

(d) CBS250はここで初めて、自分のMACアドレス宛に届いたフレームからIPパケットを見て、自分に繋がってるCiscoターミナルサーバー宛であることを知り、そちらに転送する。

(e) ターミナルサーバーはデータを受け取り、返信先を確認する。

(f) ターミナルサーバーは返信先の192.168.1.152が別ネットワーク宛てだと分かるのでデフォルトゲートウェイに設定してあるCBS250のMAC宛に返信データのフレームを送信。

(g) CBS250は自分のMACアドレス宛に届いたIPパケットから配送先が192.168.1.152であることを確認し、自分に接続されたネットワーク宛てなのでMACアドレスのリスト(ARPテーブル)を確認。自分に接続されたメインPC宛てであることが分かったのでメインPCのMACアドレス宛にフレームを転送。

(h) メインPCに到着したデータはファイアウォールで検査される。しかし送ったのと異なるルートで返ってきた返信は、PC側から開始した一連の通信であることが認められず、ファイアウォールはこの返信を破棄する。

ということらしい。

改善策

とりあえずメインPCをスタティックIPにして、手動でデフォルトゲートウェイをCBS250にしてたみたところ、行きも返りもNTTホームムゲートウェイを通らずCBS250だけで完結したのでファイアウォールではじかれるようなこともなくなった。

まぁこのままだとネット接続できないのでCBS250側に0.0.0.0/0宛ての通信を192.168.1.1へ通信させるよう設定。(いわゆるデフォルトゲートウェイ)。

これでひとまずの改善策となった。

本格的に設定を固める際はDHCPサーバー側で配布するゲートウェイをCBS250にしてやる必要があるが、とりあえず実証実験は終わったので一旦満足。

以上

当ブログは、amazon.co.jpを宣伝しリンクすることによってサイトが紹介料を獲得できる手段を提供することを目的に設定されたアフィリエイト宣伝プログラムである、 Amazonアソシエイト・プログラムの参加者です。