ネットワーク上で配布される資料は、特にMikroTikルーターの操作に関連しています。 そして、それらはすべて、少ないCPUリソースを使用してDHCPをキャッチします。 同時に、比較的新しいスイッチのラインは慢性的に無視されます。 ところで、無駄に。
そのため、実験装置CRS125-24G-1Sはアクセス時にインストールされます。 しばらくの間、ユーザーのデバイス上で無関係なIPアドレスがドロップアウトし始めました。 当然、「発見して無力化する」というタスクが発生しました。 RouterOSの標準装備には、サードパーティのDHCPサーバーがネットワークで検出されたときに特定のアクションをトリガーできる「DHCPサーバーアラート」ツールがあります。
わかった おそらく。 よく見てみると、あまり有益ではありませんでした。 理由を理解するために、MikroTikルーティング機器の典型的なアーキテクチャを検討してください（wikiからの写真）：
実際、デバイスの主要部分は2つに分かれています。
1）最大速度でスイッチングを実行するソフトウェア構成可能なスイッチ。
2）CPUはルーティング、フィルタリングを担当し、ソフトウェアレベルで切り替えを実行することもできます。これは、より低速で、より多くのリソースを消費します。
もちろん、そのようなデバイスのIPサービスはトップレベルでハングします。 CPUルーターボードまたはソフトウェアブリッジに戻るマスターインターフェイス上。 DHCPサーバーとそのアラートサービスが存在します。 以前見たすべてのソリューションには、このアーキテクチャから生じる2つの欠点もありました。
1）悪役からのトラフィックのフィルタリングは、「use ip firewall」を使用してブリッジで実行され、不足しているCPUリソースが取り除かれました。
2）スイッチに接続された悪役は、このスイッチの隣接ポートの加入者を制御不能に台無しにし続けました。
たとえば、port2とport3にハングアップしているサブスクライバは、port4から到着するbyakを引き続き受信しました。 しかし、MikroTikがCRSラインを導入したとき、すべてが変わりました。彼らは、より強力で機能的なスイッチチップをインストールしました。
ステップ1
「DHCPサーバーアラート」を設定します。 構成自体は複雑ではありません。ほとんどすべてがベンダーのwikiに記載されています。オンにし、監視するインターフェイス（ブリッジローカルなど）を設定し、信頼できるDHCPを指定します。 何かが発生した場合に呼び出すスクリプトを追加できます。 Hooray-パラメーターは自動的にスクリプトに渡されます：$ interface $ mac-address $検出された悪役のアドレス！ やった？ とても簡単 しかし、ここでは最初の水中レーキが隠されています。 そして一人ではありません。
最初のレーキ： $ interfaceには、アラート自体が置かれているインターフェイスの名前が渡されます。 したがって、たとえ悪役が「port4」インターフェイスに接続されていても（上の図を参照）、変数には「ブリッジローカル」が保持されます。 ログでは、ほぼ同じことがわかります。
"dhcp-alert on bridge-local: discovered unknown dhcp server, mac xx:xx:xx:xx:xx:xx, ip xyz.xyz.xyz.xyz"
エヘム。 ポートはいくつありますか？ 24？ わかった 検索します...
ステップ番号2
熊手で。 変数$ mac-addressでunicast-fdbスイッチを検索する必要があります。 そして、ここで2番目の熊手が私を待っていました。 本当の水中。 スクリプトは呼び出されましたが、動作したくありませんでした。 MikroTikのスクリプティングに携わっている人は誰でも、自動的に起動されるスクリプトのデバッグはそれ自体が簡単な作業ではないことを確認します。 また、on-error {}ハンドラは何らかの理由で沈黙していました。 経験的に、コードは
:set portname [/interface ethernet switch unicast-fdb get [find mac-address=$mac-address] port ]
端末のコマンドラインでのみ完全に実行されます。 スクリプトの本文では必要ありません。 その理由は、適切な（ベンダーによって定義された！）変数$ mac-addressの名前の奇妙な解釈です。
機能：スクリプト内のコマンドの解釈は
($"mac-address")
。 この場合、将来の使用でトリックも可能です。
私は別の方法で、通常解釈される名前でローカル変数を作成しました：
:local smac ($"mac-address")
簡単になりました。 これで、害虫が接続されているスイッチの実際のインターフェイスの名前を確認できます。 彼を殺す方法を理解することは残っています。
ご存じのとおり、本物のジェダイは力を使い、本物のエンジニアは脳を使います。 したがって、見つかったポートを愚かに切り落とすという考えは完全に破棄されました-このポートに複数のユーザーやデバイスが座っているとどうなりますか？ 幸いなことに、MikroTik CRSのスイッチチップを使用すると、MACベースのVLANを実行できます。 ソリューションはすぐに実現しました-MACの悪役からトラフィックを分離し、別の未使用のVLANにラップします。 その結果、DHCPサーバーが起動しているネットワークから別のデバイスを確実に切断するコンパクトなスクリプトを取得しました。
#dhcpsnooper - script to cut off rogue DHCP server #stubvid - Stub Vlan Id to move rogue DHCP server. Set your own value according your vlan config :local stubvid 666 :local smac ($"mac-address") :local portname [/int eth sw uni get [find mac-address=$smac] port ] :local imac [/int eth sw mac find src-mac-address=$smac] if ([:len $imac]<1) do={/interface ethernet switch mac-based-vlan add new-customer-vid=($stubvid) src-mac-address=($smac) } else={ foreach i in $imac do={/interface ethernet switch mac-based-vlan set $i new-customer-vid=($stubvid) src-mac-address=($smac) disabled=no } } /interface ethernet switch port set $portname allow-fdb-based-vlan-translate=yes log error ("DHCP found on PORT:".($"portname")." MAC:".($"mac-address")." IP:".($address))
名前が示すように、$ stubvid変数はVlanスタブの番号です。 $ imac変数は配列です。 何らかの理由で、MikroTikでは、mac-based-vlanテーブルに同じMACで複数のエントリを作成できるため、単一の値を取得しようとするとクラッシュが発生しました。 警告は単純にログエラーに書き込まれますが、ネットワーク管理者により永続的な情報を追加することを妨げるものは何もありません。
アラートとスクリプト呼び出しは次のように登録されます。
/ip dhcp-server alert add disabled=no interface=bridge-local on-alert=dhcpsnooper valid-server=MAC__DHCP
最後まで読んでくれてありがとう。 いつかこの機能が役立つと思います。