Tyblog

Posted on by admin

” Building my ideal router for $50 ”

  • 09 April 2018
  • 4204 words
  • 23 minutes read time

Asus N66U kicket後、いくつかの選択肢を検討しました。 別のオールインワン ルーター、EdgeRouter のようなものにアップグレードする、または何かカスタム製品を作る、などです。

私は、Ars Technica の記事で、独自のルーターを構築することの素晴らしさを支持する記事を読んだとき、それでほぼ決着がつきました。 ちなみに、ARM ボードはこれらの要件の多くに適合し、Raspberry Pi のようなものは、x86 からは異質と感じるかもしれませんが、ARM プラットフォームに対する大きなサポートがあるほど、コミュニティの活動をかき立てました。

私は、それが行うことに対して非常に安価であるだけでなく、それ自体が非常に高性能なデバイスを何とか作り上げました。もしあなたが自分のホームルーターを作ることに興味があるなら、私はここで、そうすることが実現可能なだけでなく、比較的簡単で、トラフィックシェーピングからネットフローの監視、ダイナミック DNS まで、膨大なユーティリティを提供することを実証したいと思います。

My espressoBIN in operation

この写真は、3D プリントしたケースに収められたボードです。残念ながら、Raspberry Pi のように購入できるケースを幅広く誇るほど espressobin は普及していませんが、3D プリント用に良いモデルがいくつか出てきています。

余談ですが、以下のドキュメントは、同じことを自分で行うための包括的なステップバイステップ ガイドとして意図されているわけではありません。構築のために行った選択の多くをカバーしたいとは思いますが、ルーター/ファイアウォールのような重要なものの設定は、本当にコピー/ペーストの仕事であってはならず、方法と理由を完全に理解した上で、ここの手順によってゆるやかにガイドされるのがよいでしょう。

  • The Why
  • Part One: Hardware
    • What About WiFi?
  • Part Two: Software
    • Operating System
    • Firewall
  • Part Three: 基本的な構築
    • OS Install
    • OS Config
    • Firewall
    • DHCP
  • Part Four: Interlude
  • Part Five: アップグレード
    • Netflow Monitoring
    • Traffic Shaping
  • Conclusion

The Why

ISP の純正タイヤキではない、おそらくもっと適したルーターがたくさんあります (EdgeRouter Lite、愛情込めて見ていますよ)。だから、なぜこのすべてに悩むのか？ここにはいくつかの正当な利点があります：

  • それは実際に非常に手頃な価格です。 私のルーターは見事に私のベンチマークに合格し、Linux から引っ張ってこられる可能性のあるすべての機能 (これは大きなリストです) を備えています。 毎月のように、いくつかの消費者向けネットワーク エッジ デバイスに新しい脆弱性が発表されているように感じます。 自己管理されたファイアウォールと比較すると、私はどのサービスが公開されているかを正確に知っています (そして、もし iptables が壊れたら、世界はもっと大きな問題を抱えることになります)。 ちなみに、私のファイアウォールでリッスンしている唯一のポートは、公開鍵のみのssh認証用のランダムな高番号のポートです。 ですから、Huawei のコンシューマ向けルーターよりも安全だと思います。
  • 素晴らしい機能があります。 もちろん、私の espressobin はルーティングとファイアウォールとしての役割を果たしますが、他にもいくつかの便利な機能を追加しました。 私が行ったマイナーなベンチマークでは、espressobin は汗をかかずに本当にトラフィックをプッシュできます。
  • 構築するのは本当に楽しかったです。

Part One: Hardware

技術的には、2 つの NIC を持つ任意のコンピュータを使ってルーターを構築することができますが、より少ない電力、より小さなフォーム ファクター、そしてより手頃な価格で同等のものを実現することが可能です。ARM ボードは非常に安価で、想像以上にパワフルであり、市場に出ている多くのバリエーションで十分にサポートされているからです。さらに、ヘッドレスネットワークデバイスには必要のない GPU などにお金を払うことになります。

良いニュースは、昨年、espressobin がリリースされ、これが非常に有能だということです。ギガビットネットワーキング、内蔵スイッチ、およびより汎用的なものに必要な飾り気はありません (ディスプレイ出力さえなく、シリアルコンソールだけです)。

ボードはかなり新しいものですが、Armbian と Arch Linux Arm は両方ともハードウェアをサポートし、両方のプロジェクトが素晴らしい仕事をします。Armbian と Arch Linux Arm は、aarch64 に必要なすべてをディストリビューション レポでネイティブに提供するので、64 ビット ARM チップ上で異質と感じることはほとんどなく、ハードウェアの手頃さと低電力フットプリントを考慮すると、それは確かに価値があるように思えます。 私のネットワーク テストでは、LAN インターフェイスを横切るだけのトラフィックは、バニラ スイッチを通過するトラフィックと速度的に区別がつきません。 NAS からストリーミングする場合や、ルーターを越えるデバイス間通信に高い要件がある場合、これは大きな違いになります。

  • シリアル コンソールは一流の市民です。 私の Raspberry Pis では、問題をデバッグするときに HDMI ディスプレイに手を伸ばさなければならずイライラすることがありましたが、espressobin にはマイクロ USB シリアルポートがあり、簡単にコンソールにアクセスできます。 私が投げかけたものすべてを処理しただけでなく、メルトダウンの影響を受けないことをご存知ですか? Cortex-A53 チップは投機実行バグの影響を受けないので、これはボーナスです。
    • What About WiFi?

    詳細は省きますが、努力に見合わない多くの問題があります。

    Operating System

    最初に行うべき選択は、aarch64 をサポートするディストリビューションから手動でロールバックするか、OpenWRT などのビルド済みファームウェア的ソリューションを使用するかということです。個人的には、Tomato/OpenWrt や FreeNAS のようなシュリンクされたソリューションをビルドに使用するときはいつも、本当にそこに入って物事を微調整することができずにイライラすることが分かっているので、オペレーティング システムには汎用の Linux ディストリビューションを使用するつもりです。

    以前述べたように、Armbian と Arch Linux ARM はボードをサポートしており、espressobin には Ubuntu (および今までよく知らなかった Yocto) の公式ドキュメントがあります。あなたのユースケースにどれがベストかは言いませんが、私が Arch Linux Arm を好んだ理由は以下の通りです:

    • 私は完全にローリングリリースディストリビューションを売り込んでいます。
    • 私はまた、最先端のディストロの上で動くことを売り出しています。 ルーターの場合、潜在的にセキュリティ関連のアップデートがリリースされたときに、アップストリームの近くにいるのはいいことです。
    • Arch は、余計なサービスなしで構築するための白紙の状態を私たちに提供してくれるでしょう。 つまり、最小限のベースがあれば、ピースを組み上げた後に何がインストールされ、公開され、実行されるかを正確に知ることができるのです。 WarheadsSE さん、こんにちは！
    Firewall

    PFSense などの名前がすぐに思い浮かびますが、BSD よりも Linux のほうがよく知っているので、Linux で何かを実行したいと思います（さらに、espressobin にとって最高の OS オプションは Linux ベースなのです）。

  • 複雑さを避ける。
  • トラフィック シェーピングのサポートや簡単なポート転送の設定など、あると便利な機能をサポートすること。 これは、ルールセットを適用する前に正常であることを保証し、デバイスのリソースを消費する常駐デーモンがないことを意味し、小さなシングルボード コンピュータに関連します。
  • また、多くの素晴らしい歴史的知識が組み込まれており、吐き出される iptables ルールは、通常では考えられないような多くのエッジケースを処理します。
  • これについては後で詳しく説明しますが、パケット マークとトラフィック シェーピングのネイティブ サポートにより、クラスフルな qdisc が簡単にできます。
    • OS インストール

    これは簡単です – Arch Linux Arm espressobin ページに従うだけです。

    OS Config

    一般的に、Arch Linux Arm のインストールは最初からよく設定されています。もちろん、デフォルトアカウントではない、管理用の非 root ユーザを設定したいでしょうから、alarm ユーザを無効にすること、すべてのパスワードを変えること、システムをアップデートすることは忘れないでください。設定ファイルのアップデートを自動的に検出し、マージするのを助けてくれますし、パッケージの変更に関する重要なニュースをインラインで表示してくれます。正直に言うと、私は世の中のあらゆる設定管理ソリューションが嫌いで、ほとんど全ての変更は /etc に限定されているので、少なくとも私にとってこれは十分なバックアップソリューションです。

    Note that the default network config for the espressobin works well for the router use case:

    • Both lan interfaces, lan0 and lan1, is bridged to the br0 interface. これにより、dnsmasq のようなプライベートネットワークに面したものを単一の仮想インタフェースに集中させることができます。
    • パブリックに面したインタフェースは wan です。 これは DHCP を介してアップストリーム ISP からアドレスを取得します。

    ルータ用に br0 と wan をセットアップするために必要な唯一の変更は、2つの追加です。まず、LAN インターフェースがルータになるので固定 IP を割り当て、/etc/systemd/network/br0.network で IP 転送と IP マスカレードを有効にしています。

    Address=192.168.1.1/24IPForward=ipv4IPMasquerade=yes

    そして、WAN に面したインターフェースが /etc/systemd/network/wan.network:

    DHCP=yesIPForward=ipv4UseDNS=no

    で ISP にアドレスを要求することを確認し、私は上流の ISP の代わりに OpenNIC サーバーを使用したいのでここで UseDNS=no と設定しています – これらは後でどこに設定するかに触れたいと思います。

    Firewall

    The Arch Linux ARM aarch64 repositories have got the latest version of Shorewall, which is what I used. My configs are not that fancy, and if you’re seriously considering deployment Shorewall with a connection to the wild internet, I recommend the whole of Shorewall’s introduction to a two-interface firewall.All the whole of read the Shorewall is very recommended to see.ルーティングとファイアウォール全般の素晴らしい要約とともに、どのようにセットアップすべきかの基本をカバーしています。

    基本的には、br0 と wan インターフェイスを正しいゾーンに入れ、/etc/shorewall/rules で必要なルールを設定します。LAN 上のホストに DNS サーバーを使用させることを忘れないでください:

    DNS(ACCEPT) loc $FW

    interfaces ファイルで、LAN インターフェースで DHCP が許可されていることを確認します。

    ここで、ファイアウォールのセットアップ中に Shorewall のバグに遭遇し、文字通り前日にパッチが適用されているのを発見したことを記しておきます。

    DHCP

    dnsmasq はホームルータに完璧にフィットします。これは DNS と DHCP サーバを小さなネットワークで必要なすべてを扱う軽量のデーモンにバンドルしており、その正確な使用例について多くのドキュメントがあるくらいに成熟しています。 私は .network ファイル中の DHCPServer= で設定できる systemd 組み込みの DHCP サーバを使おうと試みました。あまり冗長にならないように、現在のアドレスリースを見つける方法がないことが大きな理由の一つです。

    ここで設定すべきオプションはたくさんありますが、最も重要なのは次のとおりです。 

    # Listen for requests on this interfaceinterface=br0# Address range to draw fromdhcp-range=192.168.1.5,192.168.1.250,255.255.255.0,24h# Default route for clients (the address we used in /etc/systemd/network/br0.network)dhcp-option=option:router,192.168.1.1# Instead of doling out DNS servers from your upstream ISP who may do dumb# things for things like unresolvable names, you can rely on other DNS servers.# These are from OpenNIC.server=192.52.166.110server=66.70.211.246server=69.195.152.204server=158.69.239.167

    静的割り当てまたはエイリアスが必要なら、それらも簡単に追加することができます。

    Part 4: Interlude

    espressobin が br0 で DHCP と DNS 要求を提供し、Shorewall によってファイアウォールを行い、LAN と WAN の間でパケットをルーティングすることで、ルーターとして機能していることが確認できました。

    I bolted on the following features to my vanilla espressobin router, which’ll each cover in turn:

    • Netflow monitoring
    • Traffic shaping
    Netflow Monitoring

    Traffic visibility is something that I found really valuable with my Asus Merlin firmware to track usage.The トラフィックは、Asusのファームウェアの使用状況をトラッキングするために、私が本当に価値のあるものだとわかった。Netflow はこの種のもののデファクトスタンダードであり、利用可能なすべてのオプションの中で、私は ipt-netflow が本当に好きです。

    おそらく私が aarch64 アーキテクチャでこれを使用した最初の人間であることがわかりました。なぜなら、私は aarch64 チップセットでこれをサポートするためにいくつかの助けを得たからです。プロジェクトのメンテナはバグフィックスに対して非常に反応がよく、そのため私は Arch Linux ARM プロジェクトが実行する最新のカーネルでこのモジュールがサポートされることを保証するのに何の問題もありませんでした。dkms は素晴らしいので、あなたのカーネル用にビルドします。/etc/modules-load.d/ipt-netflow.conf

    ipt_NETFLOW

    これで読み込み、/etc/modprobe.d/ipt-netflow.conf:

    options ipt_NETFLOW destination=$ip:2055 protocol=5

    ここで $ip はあなたの netflow destination です。最後に、トラフィックは特別な iptables ターゲットに流れることによって捕捉されますが、これは便利なことに shorewall から直接行うことができます。/etc/shorewall/start:

    run_iptables -I INPUT -j NETFLOWrun_iptables -I FORWARD -j NETFLOWrun_iptables -I OUTPUT -j NETFLOWreturn 0

    これは、ルーター上のすべてのパケットを、何よりもまず NETFLOW ターゲットに入るように指示し、それがパケットを処理して、Shorewall が設定する通常のルールで流れるように戻します。

    もちろん、ipt-netflow には netflow ログを送信する場所が必要ですが、これはこの記事の範囲外です。私の場合、ネットワーク上で Logstash インスタンスを実行し、netflow モジュールを実行して Elasticsearch クラスターにイベントを集約しています。これは、いくつかの便利なダッシュボードとネットワークに関するさまざまな情報を視覚化する能力を得ることができます。デフォルトのダッシュボードがいくつかあります。

    Logstash Netflow Overview Dashboard

    Geo IP ダッシュボードなど、非常に優れたものも含まれます。

    Logstash Netflow Geo IP Dashboard

    しかしながら、私が関心を持つ最も関連性の高いメトリックは、データ上限を気にする前時代の ISP を持っているので、総帯域幅使用量です。幸いなことに、私が収集している netflow データを使えば簡単です。Elasticsearch にいくつかのフィールドの合計を求めるだけで、それらのメトリックを簡単に取得できます。

    • The gauge compare the sum over the time period in question against the cap my ISP has set for me, so can easily see where my current usage lies against the cap.
    • The timeseries plot bandwidth in bytes over time, to see when you are using that bandwidth.
    Custom Netflow Bandwidth Usage Dashboard

    この設定について特に素晴らしいことは、他のデータストアや時系列データベースではなく Elasticsearch にネットフローのメトリックを保存しているので、これらのダッシュボード用のクエリを実際にフォーカスし、特定の CIDR 範囲について合計バイト数のみを行うといったことを行うことができる、ということです。たとえば、Kibana の次のクエリ:

    NOT (netflow.dst_addr:"192.168.1.0/24" AND netflow.src_addr:"192.168.1.0/24")

    Will effectively filter out potentially big hunks of bandwidth that happen between host on my Kodi host and NAS machine.Cool.

    Traffic Shaping

    This turned into a attractive rabbit hole that was a pretty massive projectaking into disappear to be.いくつかの純正およびほとんどのカスタム ルーター ファームウェアは、何らかの形で QoS またはトラフィック シェーピングを提供しているので、私のカスタム ルーターで同じことを行い、私のトラフィック (Overwatch など) を高い遅延から保護したいと思っていました。HTB (hierarchical token bucket) フィルタのような単純なスキームに頼ることもできますが、パケット フィルタリングの進歩は驚くほど活発で、多くの興味深いアプローチがあります。正直に言うと、その背後にある数学は私の専門外なので、普通の人向けにそれを分解しようとするいくつかの要約を読む必要がありました。そして、私にとって最も納得のいく説明は、GitHub ユーザー eqhmcow が偶然見つけた、実際の HFSC の利点と使用を説明する優れた gist でした。

    要点は次のとおりです。HFSC トラフィック コントロール クラスを使用すると、非常に効果的にトラフィックに優先順位を付け、高い帯域幅と低いレイテンシーを必要とするストリーム間の良好なバランスを達成することができるのです。ルールがなければ、Steam や Blizzard Launcher のダウンロードは ping 時間をつぶしますが、アクティブな HFSC ルールは、インタラクティブなストリームに影響がないように、それらの重いトラフィック部分を優雅に切り詰めます。

    最初のステップは、tcdevicesファイル内の各デバイスに関連するtcクラスを設定することです:

    # cat /etc/shorewall/tcdevices#INTERFACE 97%_down 90%_up options(set hfsc)wan 224mbit:200kb 9mbit hfscbr0 1000mbit:200kb 1000mbit hfsc

    ここでは、LAN に面した br0 インターフェースはフルギガビットとなり、WAN インターフェース wan には下り速度の 97% と利用できる上速度 90% のクラスが設定されています。これらの数字の理由は gist で説明されています – 私たちは本質的に、このルールセットを Shorewall の用語で再現しているのです。

    次に、パケット マークが tcclasses ファイル内の tc クラスにどのようにマッピングされるかを定義します:

    # cat /etc/shorewall/tcclasses#INTERFACE MARK RATE CEIL PRIO OPTIONSwan:10 1 full/2:10ms:1540 full 1 tcp-ackwan:11 3 full/2:10ms:1540 full/2 2 defaultbr0:20 2 full*9/10:10ms:1540 full*9/10 1 tcp-ackbr0:21 3 115mbit:10ms:1540 224mbit 2 default

    これにより、重要/対話型のトラフィックは、より高い優先度が得られるクラスへと落とされるでしょう。もちろん、より高い優先度を得るべきパケットをマークする必要もあり、これは mangle:

    # cat /etc/shorewall/mangle# ICMP pingMARK(1-2) 0.0.0.0/0 0.0.0.0/0 icmp echo-requestMARK(1-2) 0.0.0.0/0 0.0.0.0/0 icmp echo-reply# sshMARK(1-2) 0.0.0.0/0 0.0.0.0/0 tcp ssh# Overwatch, Hearthstone, Diablo. 3478-3497 are very general RTP ports.MARK(1-2) 0.0.0.0/0 0.0.0.0/0 tcp,udp bnetgame,blizwow,6113MARK(1-2) 0.0.0.0/0 0.0.0.0/0 udp 3478-3497,5060,5062,6120,6250,12000-64000# Local trafficMARK(1-2) 192.168.1.0/24 192.168.1.0/24

    これは、tc クラスによって処理される高優先度のマーク (1 と 2) を設定します。

    私は、HFSC の動作を示すいくつかのベンチマークを持っていますが、ここでは、iperf がバックグラウンドで実行されたときに ping 遅延がどのように影響されるかという小さな例を紹介します。

    お分かりのように、トラフィック制御ルールがない場合、大量のトラフィックのバーストは、高い遅延に敏感な対話型トラフィックにかなり悪い影響を与える可能性があります。連続稼働の全期間において、謎の接続低下、速度問題、ハードウェア問題は発生していませんので、この構築は成功したと考えています。アップグレードも問題なく、通常の sudo pacmatic -Syu とリブートの後、システムはすべての iptables ルールや他のサービスを期待通りにオンラインに戻すので、最新のカーネルや他のパッケージの維持は簡単です。

    まとめ：

    • 操作に詳しい人や技術的に関心のある人にとって、カスタムルーターの構築は非常にやりやすいものです。 ARM シングル ボード コンピューターにより、安価で便利に始めることができます。
    • ファイアウォール、トラフィック シェーピング、およびネットワーク監視用の OSS ソリューションは成熟しており、簡単に使用することができます。 特に、Shorewall や dnsmasq のような細かく古いソリューションは非常によく文書化されており、その文書と機能セットに何年もの作業が費やされています。
    • ルーティング + DNS + DHCP はスラムダンクですが、OSS WiFi はヒットするかどうかわからないことがあります。 あなたのマイレージは異なるかもしれませんが、私の espressobin は良いアクセスポイントではありません。

    コメントを残す

    メールアドレスが公開されることはありません。