このブログを検索

2021/10/26

paloaltoでDNATするときの「元のパケット」のゾーン

 paloaltoでDNATするとき、「元のパケット」の宛先ゾーンをNATで変換した後のアドレスのゾーンにしないように注意。


大体外からやってくる通信をLANのアドレスに変換すると思う。

ゾーンは大体、untrust → trust という通信になる。


しかし、NATポリシーを書くときには「どの通信をNAT対象とするか」という設定が必要であり、それはuntrustゾーンに来るuntrustゾーンのセグメントのIPアドレス宛であるから、送信元も宛先も untrust になるのである。


まあ、考えてみれば当然なのだが昔はまったことがあり久しぶりに設定したら同じようにはまった。


2021/10/10

「おうちWifi」はどこでも使えるのか

Softbank Airというサービスを使ったことがある。

家でインターネットを使うための装置であるが、通常は自宅に回線を引いてルーターを設置して使うが、「Air」はルーターが無線接続なのである。

ルーターの内側(LAN側)、ユーザーがルータと接続するところは無線で利用している人が多いと思うが、ルータのWAN側も無線にしてしまおうというサービスである。

「工事不要、置くだけで使えます」

みたいなキャッチコピーで宣伝されていた。


私の場合、ある事情で住まいをすぐに引っ越す予定もあったため、都合がよかったので利用した。


おうちWifiは、いわゆる「モバイルWifiルータ」のようなものだと思ったのだが、実は違う。

装置的には同じなのだが、「おうちWifi」は引っ越す場合手続きが必要になる。

モバイルWifiルータであればどこでも使える。だから「モバイル」なのである。


しかしおうちWifiは無線なのに、引っ越すときに手続きをしなければならない。

これは推測なのだが、おうちWifiについてはユーザがどこにどれだけいるかを管理していて、ユーザ数によって帯域を調整したりしているのではないか。

つまり、「工事不要」といってもSoftbankの網内ではなんらかの「工事」のようなものが施されているはずだ。

そうでなければ引っ越してどこで使おうが届け出る必要はないはずだから。


Softbank Airを使ってみての感想はあまりよくなかった。遅かった。

今はどんどんワイヤレス化が進んでいていつかはほとんどワイヤレスになるのではあろうが、まだ過渡期で、ワイヤレス通信で不満を感じることは多い。

あと、すぐ引っ越して解約する予定だったのにルータを買い取り契約にしてしまっていて、解約した後も使わなくなった機器料金をしばらく払い続けるということになり、買い取りにした覚えはないとか、説明が足りないとか文句を言った挙句ソフトバンクのサービスは二度と使わないと決め、すべて解約した。

paloaltoのconfigを見ていて

paloaltoというFWアプライアンス装置のconfigを見ていた。

paloaltoはブラウザで設定を表示、変更できるのだが、

configをエクスポートするとxml形式になる。

実機があれば、というか実機にアクセスできる権限があればブラウザで直接見ればよいのだが、わけあって実機にアクセスできないためxml形式のconfigファイルを見る必要があったのだ。

この手の装置のconfigをテキストでもらってテキストなりexcelなりで開くのはよくあることなのだが、paloaltoの場合少し苦労した。

xmlファイルというのは、htmlファイルと同じような感じで、<>で囲まれたタグに挟まれてデータが記述されている。

タグは何があるかわからず、階層化されている場合もある。

excelでxmlファイルを開くと一応解析のようなことをしてそれらしき表形式にしてくれるのだが、paloaltoのコンフィグファイルはまともな形にならなかった。

なので、xmlではなく単なるテキストファイルとして読み込んでみた。

<tag>data1</tag> 

のような形式でconfigの設定内容が並んでいる。

ポリシーの部分は以下のようになっている。


<rulebase>

 <security>

 (セキュリティルール)

 </security>

 <nat>

 (NATルール)

 </nat>

</rulebase>


そしてセキュリティルールとNATルールが数百行書かれているわけだが、

その各ルールを見ていくと、設定されている項目とされていない項目がある。

excelでうまく読み込めないので、自分で項目をそろえていった。

例えば<tag>, <to>, <from>, <source>, など。


特に困ったのがNATルールである。

paloaltoはセキュリティルールとNATルールが別になっている。

NATには送信元NAT、宛先NAT、static変換、inteface NATなど様々な方法が組み合わされるので、xmlファイルの項目のバラツキが大きい。

大体いくつかのパターンにはなるのだが、数百行あり順番も意味を持つため慎重に見ていかねばならない。

最初は同じタグの項目がexcelの同じ列になるようにそろえていったのだが、想定外のことが一つあった。

paloaltoのconfigファイルの項目は、一定の順序になっていないのだ。


例えば、

<tag><src><dst><to><from><source-translation><destination-translation>

などの項目があるのだが、送信元のみNATするなら<destination-transloation>はない。

<tag>というのは注釈のようなものだからある行とない行がある。


最初は項目がないところはずらしていけば揃えられると思っていたのだが、

行によって<source-translation>と<destination-translation>の順番が逆だったりする。


fortigateのconfigを見たこともあるのだが、fortigateはxml形式ではないが<>で項目が区切られており、設定により項目があったりなかったりはするのだがその出現順番は同じであった。

だが、paloaltoは一定でないのだ。


本当はpythonなどで読み込んでタグごとの項目をいったん変数に格納して決まった順番で並びなおして出力する、などをしたかったのだが、すべきなのだろうが、結構複雑になりそうなのでそれはしなかった。

そして地道にexcelでセルを移動して項目をそろえていった。


しばらくやっているうちに、気づいた。

そもそもxmlファイルというのはexcelのような表形式を想定しておらず、その項目がなんであるかはタグによって決定されるのであり、また、タグによらずに決定してはならないのである。


それは、今私がしているようにExcelの表形式にするには不便な仕様なのであるが、データを作成し記述することを考えた時に、項目の順番を意識せずに正しいタグさえつければ順番はどうでもかまわない、読み込むときにタグを指定すれば<src><dst><from><to>であっても<to><src><from><dst>であってもかまわないのだ。


私は若いころは固定長フィールドのファイルを使っていて、データの扱いに関する意識が古いところがある。最近はもう固定長フィールドなんかほとんど使わない。

しかし、ドキュメントはだいたいExcelで作られる。ほとんどがExcelである。

パソコンでExcelを使うことが「デジタル化」であるとか「IT」であるとかいうのは間違っている。

Excelの表形式のファイルを皆で共有して更新しあっているなんていうのは、紙に印刷したものにハンコを押すようなやり方とあまり変わらない。