私は、「継続的な」システム管理者に焦点を当てたシリーズの2番目の記事を発表しています。

これらの記事では、複数の会社のオフィスに接続し、ネットワークへの制限されたアクセス、トラフィックの優先順位付け（QoS）、および2つのプロバイダー間のチャネル予約による単純な負荷分散を可能にするLinuxでのインターネットゲートウェイの構築を検討します。

特にこの部分では：

Shorewallのより詳細なセットアップ
怖くて理解できないQoS
負荷分散と冗長性

そして、前の部分で検討しました：

最もシンプルなShorewallセットアップ
非常に複雑なdnsmasqセットアップ
それほど複雑ではないOpenVPNセットアップ
そして、多くの継続的な管理者にとって、非定型の動的ルーティング、例えばOSPF

第三部では：

ShorewallでのQoS
Shorewallのより詳細なセットアップ
プロトコルに従ってチャネルを介してトラフィックを拡散する
松葉杖、それらなしで、どこにも

4番目の部分では：

自動イベント
マクロ

以下に説明するすべてはCentOS 7.1に当てはまります（上記では、6番目のシリーズも適していますが、マイナーな機能があります）

高度なショアウォールのセットアップ

前回、かなりだまされやすい原始的な動作モードを設定したとき、今度は少し健全なパラノイアをオンにします。

これは難しくありません。ファイルに変更を加えましょう。

政策

# # Shorewall -- /etc/shorewall/policy # # For information about entries in this file, type "man shorewall-policy" # # The manpage is also online at # http://www.shorewall.net/manpages/shorewall-policy.html # ############################################################################### #SOURCE DEST POLICY LOG LIMIT: CONNLIMIT: # LEVEL BURST MASK $FW all REJECT grn all REJECT tun all REJECT red all DROP

新しい構成はより簡単になりましたが、ルールファイルは早期に喜ぶようになり、大幅に拡張されます。

/ etc / shorewall /ルール

 # # Shorewall -- /etc/shorewall/rules # # For information on the settings in this file, type "man shorewall-rules" # # The manpage is also online at # http://www.shorewall.net/manpages/shorewall-rules.html # ###################################################################################################################################################################################################### #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH HELPER # PORT(S) PORT(S) DEST LIMIT GROUP ?SECTION ALL ?SECTION ESTABLISHED ?SECTION RELATED ?SECTION INVALID ?SECTION UNTRACKED ?SECTION NEW INCLUDE rules.fw INCLUDE rules.grn INCLUDE rules.red INCLUDE rules.red-dnat INCLUDE rules.tun

そして、INCLUDEディレクティブを使用して、ルールを複数のファイルに分散します。

rules.fw

 # # Shorewall -- /etc/shorewall/rules.fw # # For information on the settings in this file, type "man shorewall-rules" # # The manpage is also online at # http://www.shorewall.net/manpages/shorewall-rules.html # ###################################################################################################################################################################################################### #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH HELPER # PORT(S) PORT(S) DEST LIMIT GROUP DNS(ACCEPT) $FW red Web(ACCEPT) $FW red FTP(ACCEPT) $FW red OpenVPN(ACCEPT) $FW red Ping(ACCEPT) $FW all OSPF(ACCEPT) $FW tun SSH(ACCEPT) $FW all

rules.grn

 # # Shorewall -- /etc/shorewall/rules.grn # # For information on the settings in this file, type "man shorewall-rules" # # The manpage is also online at # http://www.shorewall.net/manpages/shorewall-rules.html # ###################################################################################################################################################################################################### #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH HELPER # PORT(S) PORT(S) DEST LIMIT GROUP DNS(ACCEPT) grn $FW Web(ACCEPT) grn red FTP(ACCEPT) grn red Ping(ACCEPT) grn all SSH(ACCEPT) grn all - - - - s:3/min #,  ,   SIP (    ) ACCEPT grn red udp 5060 - - - - - - - - sip

rules.red

 # # Shorewall -- /etc/shorewall/rules.red # # For information on the settings in this file, type "man shorewall-rules" # # The manpage is also online at # http://www.shorewall.net/manpages/shorewall-rules.html # ###################################################################################################################################################################################################### #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH HELPER # PORT(S) PORT(S) DEST LIMIT GROUP OpenVPN(ACCEPT) red $FW SSH(ACCEPT) red $FW - - - - s:3/min SIP(ACCEPT) red grn

rules.tun

 # # Shorewall -- /etc/shorewall/rules.tun # # For information on the settings in this file, type "man shorewall-rules" # # The manpage is also online at # http://www.shorewall.net/manpages/shorewall-rules.html # ###################################################################################################################################################################################################### #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH HELPER # PORT(S) PORT(S) DEST LIMIT GROUP Ping(ACCEPT) tun $FW OSPF(ACCEPT) tun $FW SSH(ACCEPT) tun $FW - - - - s:3/min SSH(ACCEPT) tun grn - - - - s:3/min

これで、すべてのトラフィックが制御され、必要なプロトコルのみが許可されます。 SSHのルールに注意してください。各IPソースからの接続頻度を1分あたり3回に制限しています。ただし、s：またはd：キーを誤って指定すると、このパラメーターに非常に注意する必要があります。サービスをDDoS攻撃の影響を受けやすくすることができます。また、Webトラフィック（および実際のトラフィック）の場合、多くの潜在的なクライアントがNATの背後に座って、接続のソースである1つのIPがかなりの数の接続を生成できることに留意する必要があります。

SIPおよびFTPプロトコルでの管理方法に注意してください。ちょうどそれらを登録し、Shorewallはマクロを使用して、nf_nat_ *およびnf_conntrack_ *モジュールを操作するすべての複雑さを隠しました（対応するモジュールなしで、コマンド接続は別として（またはRPCなどのすべてのポートが動的に）、未知のポートのセカンダリ、iptablesのようなShorewallは、これらの接続のためにポートを動的に開くことができません）。 SIPの例では、使用するプロトコル、ポート、ヘルパーを指定して、ほぼ手動の構成を使用しました。

ヘルパーを使用すると、Shorewallはプロトコルが検出されるとすぐに（これが無効になっていない場合）、またはヘルパーカラムを明示的に使用すると、対応するモジュールをロードします。よく知られているショアウォールモジュールとその設定は、ファイル/ usr / share / shorewall / helpersで確認できます。それらを変更する必要がある場合、ファイルを/ etc / shorewallにコピーすると、このコピーが標準ファイルを上書きします。

ポートを内部サーバーに転送する必要がある場合、これは難しくありません。

rules.red-dnat

 # # Shorewall -- /etc/shorewall/rules.red-dnat # # For information on the settings in this file, type "man shorewall-rules" # # The manpage is also online at # http://www.shorewall.net/manpages/shorewall-rules.html # ###################################################################################################################################################################################################### #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH HELPER # PORT(S) PORT(S) DEST LIMIT GROUP Web(DNAT) red grn:172.16.0.2 #,      ,    DNAT     : #Web(DNAT) red grn:172.16.0.2 - - - 192.168.10.37 #,  : #DNAT red grn:172.16.0.2 tcp 80,443 #DNAT red grn:172.16.0.2 tcp 80,443 - 192.168.10.37 #   : #DNAT red grn:172.16.0.2:80 tcp 8080

さらに、Shorewallはipsets（パッケージがインストールされていることを確認します：yum install ipset）をサポートします。これは単に名前付きアドレスリストです。サブネットに結合できないホストのグループに特定のルールを設定する必要がある場合に役立ちます。

構成でそれらを使用することは難しくありません。アドレスまたはサブネットが使用されるすべての場所に+ <ipsets nameを書き込むだけで十分です。

再起動中にShorewallにipsetを保存および復元させたい場合、shorewall.confでSAVE_IPSETS = Yesを設定する必要があります。

ipsetsを使用した場合と使用しない場合の構成は次のとおりです。

ルール

 # # Shorewall -- /etc/shorewall/rules # # For information on the settings in this file, type "man shorewall-rules" # # The manpage is also online at # http://www.shorewall.net/manpages/shorewall-rules.html # ###################################################################################################################################################################################################### #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH HELPER # PORT(S) PORT(S) DEST LIMIT GROUP # ipsets OpenVPN(ACCEPT) red:192.168.10.4,192.168.23.2 $FW # ipsets OpenVPN(ACCEPT) red:+ovpn_allow $FW

最初に、ipsetを宣言します。

 #  iphash (     ,   man ipset    ) ipset -N ovpn_allow iphash #     ipset -A ovpn_allow 192.168.10.4 ipset -A ovpn_allow 192.168.23.2

以上で、記録した内容を確認できます。ipset-L

 Name: ovpn_allow Type: hash:ip Revision: 1 Header: family inet hashsize 1024 maxelem 65536 Size in memory: 16560 References: 0 Members: 192.168.23.2 192.168.10.4

Shorewallのシンプルな負荷分散と冗長性

すぐに言うと、バランシングと冗長性はShorewallを使用してのみ設定され、それ自体はチャネル損失や実際の負荷の分散を検出する機能を提供しません。

設定全体は、単一のファイルの編集になります。

プロバイダー

 # # Shorewall -- /etc/shorewall/providers # # For information about entries in this file, type "man shorewall-providers" # # For additional information, see http://shorewall.net/MultiISP.html # ############################################################################################ #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY pr1 1 0x10000 - $IF_RED1 $GW_RED1 track,fallback=1 pr2 2 0x20000 - $IF_RED2 $GW_RED2 track,fallback=4

誰かが覚えているなら、前回の記事には「Shorewall.conf」のセクションがありました。パケットのラベル付けを構成し、プロバイダーと連携するためだけに必要です。そこで、パケットラベルのどのビットがプロバイダーIDを指定するか、どのラベルが単純か（まだどこにも使用していませんが、Shorewallは自分のニーズに合わせて使用します）、および接続を追跡するものを設定します。

ここでは、2つのプロバイダーについて説明し、それらにパッケージをマークする方法、各インターフェイスが置かれているインターフェイス、およびゲートウェイを備えているインターフェイスについて説明しました。

これがOPTIONS列です。少し説明が必要です。ここで、fallbakキーは、バランシングルールがパケットを処理できない場合（たとえば、インターフェイスがレイダウンする場合）に追加のルーティングルールを生成することを強制し、数字はインターフェイスの重みを設定します。 trackパラメーターは、接続がどのプロバイダーに行ったかを監視し、この接続から次のパケットを同じプロバイダーに送信する必要があることを示します（shorewall.confでTRACK_PROVIDERS = Yesが設定されている場合、このオプションはすべてのプロバイダーに自動的に登録されます）。、より頻繁に新しい接続がインターフェイスに届きます（その結果、相対的な重みが使用され、重みの割合が高くなり、トラフィックが増えます。大きな重み値の設定は推奨されません）。バランシングは、カーネル自体によって既にラウンドロビン方式に従って行われ、クライアントとサーバーのルートに沿って接続を確立するという事実に基づいています（クライアントとしてのルーターと、サーバーはそれぞれリモートサーバーです）。この場合、ルートはしばらくキャッシュされ、この効果が得られます：LAN内の誰かが、たとえば特定のサイト（1つのIPがある）に登り、トラフィックがプロバイダー1を通過し、他の誰かがそこに登り、トラフィックが実行されます再びプロバイダー1を使用します（キャッシュをリセットする時間がなかった場合）。また、例のように対称プロバイダーがないため、幸運なことに、最初のプロバイダーに接続する4つごとの接続が最も「難しい」ことがわかりますが、これを回避したかったのです...簡単な解決策はありません。それは何の助けにもなりません。

しかし、すべてがそれほど悪くないわけではなく、それでも威厳をもって機能します（ちなみに、ほとんどのソリューションで機能します。「正直な」バランスをとるために、非常に難しいソリューションが使用されます。

拡張変数ファイル：

params

 # # Shorewall -- /etc/shorewall/params # # Assign any variables that you need here. # # It is suggested that variable names begin with an upper case letter # to distinguish them from variables used internally within the # Shorewall programs # # Example: # # NET_IF=eth0 # NET_BCAST=130.252.100.255 # NET_OPTIONS=routefilter,norfc1918 # # Example (/etc/shorewall/interfaces record): # # net $NET_IF $NET_BCAST $NET_OPTIONS # # The result will be the same as if the record had been written # # net eth0 130.252.100.255 routefilter,norfc1918 # ############################################################################### IF_RED1=eth0 GW_RED1=192.168.10.1 IF_RED2=eth2 GW_RED2=detect IF_GRN=eth1 NET_GRN=172.16.0.0/23 IF_TUN=tap+ #LAST LINE -- DO NOT REMOVE

2番目のプロバイダーのゲートウェイが「detect」キーワードとして指定されていることに気付く場合があります。これは、動的アドレス指定を使用した接続で機能します。場合によっては（PPtPなど）、Shorewall自体がゲートウェイを正しく判断できないため、補助スクリプト付きのファイルが使用されます。

findgw

 # # Shorewall version 4 - Findgw File # # /etc/shorewall/findgw # # The code in this file is executed when Shorewall is trying to detect the # gateway through an interface in /etc/shorewall/providers that has GATEWAY # specified as 'detect'. # # The function should echo the IP address of the gateway if it knows what # it is; the name of the interface is in $1. # # See http://shorewall.net/shorewall_extension_scripts.htm for additional # information. # ############################################################################### LANG='C' nmcli --terse --fields IP6.GATEWAY device show ${1} | cut -f2- -d':' #IPv6 LANG='C' nmcli --terse --fields IP4.GATEWAY device show ${1} | cut -f2- -d':' #IPv4

そして重要なこととして、これらすべてを正しくマスクする必要があります。

マスク

 # # Shorewall -- /etc/shorewall/masq # # For information about entries in this file, type "man shorewall-masq" # # The manpage is also online at # http://www.shorewall.net/manpages/shorewall-masq.html # ################################################################################################################################### #INTERFACE:DEST SOURCE ADDRESS PROTO PORT(S) IPSEC MARK USER/ SWITCH ORIGINAL PROBABILITY # GROUP DEST $IF_RED1 $NET_GRN detect $IF_RED2 $NET_GRN detect

ADDRESS列の検出パラメーターを使用すると、SNATのインターフェース上の発信アドレスを判別できます（複数のプロバイダーで必要になります）。

NetworkManagerのスクリプトはこれをすべて補完します（より単純なバージョンは前回の記事にありましたが、インターフェースを上げた後、Shorewallがルーティングポリシーを常に正しく構築するわけではないことを考慮していなかったため、単純にそのようなインターフェースに対して再起動します）。

/etc/NetworkManager/dispatcher.d/30-shorewall.sh

 #!/bin/bash IF=$1 #   ,     STATUS=$2 #     function check_prov() { PARAM=$(grep -v '^#' /etc/shorewall/params | grep $1 | cut -d '=' -f 1) if [ -z "$PARAM" ]; then grep -v '^#' /etc/shorewall/providers | grep -q $1 [[ $? == 0 ]] && shorewall restart else grep -v '^#' /etc/shorewall/providers | grep -q $PARAM [[ $? == 0 ]] && shorewall restart fi } case $STATUS in up) #      shorewall enable $IF shorewall6 enable $IF check_prov $IF ;; down) #      shorewall disable $IF shorewall6 disable $IF check_prov $IF ;; esac

ショアウォールの再起動後、コマンドを与えた後：

 shorewall show routing

組み込みのルーティングスキームを確認できます。

ルーティングの例

 Shorewall 5.0.2.1 Routing at cent1.domain.local -   8 23:41:30 MSK 2016 Routing Rules 0: from all lookup local 999: from all lookup main 10000: from all fwmark 0x10000/0xff0000 lookup pr1 10001: from all fwmark 0x20000/0xff0000 lookup pr2 20000: from 192.168.10.37 lookup pr1 20000: from 192.168.10.36 lookup pr2 32765: from all lookup balance 32767: from all lookup default Table balance: Table default: default nexthop via 192.168.10.1 dev eth0 weight 1 nexthop via 192.168.10.1 dev eth2 weight 1 Table local: local 192.168.10.37 dev eth0 proto kernel scope host src 192.168.10.37 local 192.168.10.36 dev eth2 proto kernel scope host src 192.168.10.36 local 172.16.3.1 dev tap0 proto kernel scope host src 172.16.3.1 local 172.16.3.129 dev tap1 proto kernel scope host src 172.16.3.129 local 172.16.248.1 dev lo proto kernel scope host src 172.16.248.1 local 172.16.0.1 dev eth1 proto kernel scope host src 172.16.0.1 local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 broadcast 192.168.10.255 dev eth2 proto kernel scope link src 192.168.10.36 broadcast 192.168.10.255 dev eth0 proto kernel scope link src 192.168.10.37 broadcast 192.168.10.0 dev eth2 proto kernel scope link src 192.168.10.36 broadcast 192.168.10.0 dev eth0 proto kernel scope link src 192.168.10.37 broadcast 172.16.3.255 dev tap1 proto kernel scope link src 172.16.3.129 broadcast 172.16.3.128 dev tap1 proto kernel scope link src 172.16.3.129 broadcast 172.16.3.127 dev tap0 proto kernel scope link src 172.16.3.1 broadcast 172.16.3.0 dev tap0 proto kernel scope link src 172.16.3.1 broadcast 172.16.248.1 dev lo proto kernel scope link src 172.16.248.1 broadcast 172.16.1.255 dev eth1 proto kernel scope link src 172.16.0.1 broadcast 172.16.0.0 dev eth1 proto kernel scope link src 172.16.0.1 broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 Table main: 192.168.10.1 dev eth2 scope link src 192.168.10.36 172.16.3.1 dev tap0 proto zebra 172.16.3.129 dev tap1 proto zebra 172.16.248.2 via 172.16.3.2 dev tap0 proto zebra metric 13 172.16.12.129 via 172.16.3.2 dev tap0 proto zebra metric 3 172.16.11.1 via 172.16.3.2 dev tap0 proto zebra metric 3 172.16.3.128/25 dev tap1 proto kernel scope link src 172.16.3.129 172.16.3.0/25 dev tap0 proto kernel scope link src 172.16.3.1 192.168.10.0/24 dev eth2 proto kernel scope link src 192.168.10.36 metric 101 192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.37 metric 100 172.16.8.0/23 via 172.16.3.2 dev tap0 proto zebra metric 13 172.16.0.0/23 dev eth1 proto kernel scope link src 172.16.0.1 metric 100 Table pr1: 192.168.10.1 dev eth0 scope link src 192.168.10.37 default via 192.168.10.1 dev eth0 src 192.168.10.37 Table pr2: 192.168.10.1 dev eth2 scope link src 192.168.10.36 default via 192.168.10.1 dev eth2 src 192.168.10.36

しかし、特定のプロバイダーにトラフィックを誘導することは可能ですか？はい、答えてください！

マングル

 # # Shorewall -- /etc/shorewall/mangle # # For information about entries in this file, type "man shorewall-mangle" # # See http://shorewall.net/traffic_shaping.htm for additional information. # For usage in selecting among multiple ISPs, see # http://shorewall.net/MultiISP.html # # See http://shorewall.net/PacketMarking.html for a detailed description of # the Netfilter/Shorewall packet marking mechanism. # #################################################################################################################################################### #ACTION SOURCE DEST PROTO DEST SOURCE USER TEST LENGTH TOS CONNBYTES HELPER PROBABILITY DSCP # PORT(S) PORT(S) MARK(0x20000):P 172.16.0.4 0.0.0.0/0!172.16.0.0/12

ここでは、172.16.0.4から、172.16.0.0 / 12を除く任意のネットワークへのすべてのトラフィックに、2番目のプロバイダーのラベルを付けました。条件はより複雑になる可能性があります。ゲートウェイで生成されたトラフィックについては、ルールから「：P」を削除する必要があります。

怖くてひどいQoS

すぐに説明する必要があるのは、送信時の速度の調整のみです。入ってくるトラフィックはすでにインターフェイスに到達しており、すべてのボトルネックをバイパスし、キューに入ることで、すぐにアクセスできます。

しかし、絶望するのは時期尚早であり、私たちが望むほどエレガントで信頼性の低いメカニズムがありますが、この問題を解決します。プロトコルのIPファミリに基づくネットワークでは、これは次のように解決されます。

送信元は、配信応答（TCPプロトコルのACKパケット）が通常到着するか、通常の遅延で到着するまで、送信速度をスムーズに上げます。損失があるか、ACK遅延が増加すると、速度は低下します。その後、一定の時間の後、彼らは再び速度を上げようとします。そして、これは転送の終了前に起こります。

しかし、UDPはどうですか？そして、彼にとってはすべてがシンプルで、配送管理も頭痛もありません。送信済みでOK（受信者に被害を与えます）。

もちろん、その純粋な形式では、UDPは通常、複雑なデータ転送タスクでは使用されません。このプロトコルは通常、独自のバージョンの配信制御を実装する際の基礎として使用されます（標準が適合しない場合、独自のTCP実装と言えます）。したがって、UDP上で実行される多くのプロトコルでは、配信制御もあります。これは、フルパワーでUDPの連続ストリームを送信する機能を無効にせず、ターゲット（同じバージョンのDDoS）の通信チャネルを詰まらせます。

着信トラフィックのトラフィックの優先順位付けと帯域幅割り当てを整理するにはどうすればよいですか？答えは上にあります：あなたの側での受信の遅延（結果として、ACKの生成の遅延）を作成するか、遅延が過度に大きい場合、パケットをドロップします。

Linuxでは、IFB擬似インターフェイスを作成することで実装されます。IFBは、物理インターフェイスとゲートウェイ自体の間に位置し、着信トラフィックを通過させます。トラフィックは物理インターフェイスに入り（既に受け入れられています）、IFBに進みます。IFBは、このトラフィックをスキップする（または完全にドロップする）速度と順序をすでに制御しています。

Shorewallは設定を支援します（/etc/modprobe.dに書き込むこともできます）：

/ etc / shorewall / init

 # # Shorewall -- /etc/shorewall/init # # Add commands below that you want to be executed at the beginning of # a "shorewall start", "shorewall-reload" or "shorewall restart" command. # # For additional information, see # http://shorewall.net/shorewall_extension_scripts.htm # ############################################################################### modprobe ifb numifbs=3 ip link set ifb0 up ip link set ifb1 up ip link set ifb2 up

ここでは簡単です。3つの擬似IFBインターフェイスを作成し、それらを作成しました。

次に、トラフィックを調整するインターフェイスについて説明します。

tcdevices

 # # Shorewall -- /etc/shorewall/tcdevices # # For information about entries in this file, type "man shorewall-tcdevices" # # See http://shorewall.net/traffic_shaping.htm for additional information. # ############################################################################### #NUMBER: IN-BANDWITH OUT-BANDWIDTH OPTIONS REDIRECTED #INTERFACE INTERFACES 1:$IF_GRN - 1000mbit hfsc,classify 2:ifb1 - 1000mbit hfsc,classify $IF_GRN 3:$IF_RED1 - 10mbit hfsc,classify 4:ifb0 - 10mbit hfsc,classify $IF_RED1 5:$IF_RED2 - 10mbit hfsc,classify 6:ifb2 - 10mbit hfsc,classify $IF_RED2

ここでは、使用されるインターフェイスの番号を明示的に設定し（指定されていない場合、Shorewallはファイル宣言の順に番号を付けます）、IFBを実際のインターフェイスに関連付け、最大発信速度を設定します（制御するだけで、ifbは基本的に着信です）行）を使用して、分類規則とどのトラフィックを正確に分類するかを設定します。

重要！ 速度は、プロバイダーが提供する速度よりわずかに低く設定する必要があります。プロバイダーが提供する速度よりも操作速度が速い場合、帯域幅の制限がその側で発生します。つまり、分類などの試行がすべて行われます。（完全ではありませんが、大部分は）無駄になります。帯域幅が可変のチャネルでは、すべての作業ツールがあるため、QoSを実行するのは非常に困難です。貴重なトラフィックがチャネルをクロールすることを期待して、パケットの順序を変更するだけです（無線チャネルの被災者は悲しそうにため息をつきます）。

クラスそのものについて説明しましょう。

tcclasses

 # # Shorewall -- /etc/shorewall/tcclasses # # For information about entries in this file, type "man shorewall-tcclasses" # # See http://shorewall.net/traffic_shaping.htm for additional information. # ############################################################################### #INTERFACE:CLASS MARK RATE: CEIL PRIORITY OPTIONS # DMAX:UMAX 1:1:2 - 1mbit 3mbit 2 default 1:1:3 - 256kbit full 1 2:1:2 - 1mbit 3mbit 2 default 2:1:3 - 256kbit full 1 3:1:2 - 1mbit 3mbit 2 default 3:1:3 - 256kbit full 1 4:1:2 - 1mbit 3mbit 2 default 4:1:3 - 256kbit full 1 5:1:2 - 1mbit 3mbit 2 default 5:1:3 - 256kbit full 1 6:1:2 - 1mbit 3mbit 2 default 6:1:3 - 256kbit full 1

複雑なことは一切行わず（したがって、興味深く有用です）、2つのクラスを各インターフェイス（IFBを含む）にバインドします。

最初の列では、インターフェイスをクラスに関連付けます。 <インターフェイス番号>：<親クラス番号>：<記述されたクラス番号>。

インターフェイスには常にクラス1があります。これについては、基本的にtcdevicesで説明しました。

さらに、パケットをマークしなかったため、この列を使用せず、このクラスで最も興味深い、最小限に保証された帯域幅、および可能な最大（親クラスの帯域幅以下）が使用されます。優先順位は、物議を醸す状況を解決するための順序を設定します（保証されたストリップの通路を超えて、すでに他の誰かによって完全に占有されている場合、より少ないものが最初に行きます）。結論として、オプションがあります。デフォルトでは、フィルターで何も見つからない場合（パッケージがクラスに割り当てられていない場合）、デフォルトのクラスを割り当てます。

さらに、実際には、実際のインターフェイスの分類ルールがファイルに含まれていることが歴史的に起こりました。

マングル

 # # Shorewall -- /etc/shorewall/mangle # # For information about entries in this file, type "man shorewall-mangle" # # See http://shorewall.net/traffic_shaping.htm for additional information. # For usage in selecting among multiple ISPs, see # http://shorewall.net/MultiISP.html # # See http://shorewall.net/PacketMarking.html for a detailed description of # the Netfilter/Shorewall packet marking mechanism. # #################################################################################################################################################### #ACTION SOURCE DEST PROTO DEST SOURCE USER TEST LENGTH TOS CONNBYTES HELPER PROBABILITY DSCP # PORT(S) PORT(S) CLASSIFY(1:3) 0.0.0.0/0 0.0.0.0/0 tcp - 80,443 CLASSIFY(3:3) 0.0.0.0/0 0.0.0.0/0 tcp 80,443

そして、次の仮想IFBの場合：

tcfilters

 # # Shorewall -- /etc/shorewall/tcfilters # # For information about entries in this file, type "man shorewall-tcfilters" # # See http://shorewall.net/traffic_shaping.htm for additional information. # ######################################################################################################## #INTERFACE: SOURCE DEST PROTO DEST SOURCE TOS LENGTH PRIORITY #CLASS PORT(S) PORT(S) 2:3 0.0.0.0/0 0.0.0.0/0 tcp - 80,443 4:3 0.0.0.0/0 0.0.0.0/0 tcp 80,443

上記の例では、HTTP（S）サーバーからの着信トラフィックを物理インターフェイスとそれに関連付けられた仮想インターフェイスのクラス番号3に配置し、発信は同じことを行いましたが、「ポートのデプロイ」を行いました。接続は多くの場合双方向であり、クライアントまたはサーバーを開始したユーザーに関係なく、各方向に分類を個別にペイントする必要があることに注意してください。

屋根が割れ始めるのはここです。理解するために、画像が役立ちます（特にキックしないようにお願いします。Visioでは、実際に動作する方法がわかりません）。

その結果、1つのプロバイダーがあり、ゲートウェイ自体がトラフィックを受け入れない場合（受信者ではない場合）、IFBを使用せずに異なるエリアでトラフィックをカットできます。プロバイダーがさらにあり、ゲートウェイ自体がトラフィックをアクティブに受け入れる場合（たとえば、VPNにサービスを提供する場合）、IFBがなければ、簡単に出られません。

PS

次の記事では、特にVoIPテクノロジーの普及を考慮して、QoSにさらに焦点を当てる予定です。トピックは大きく、すべてを慎重に計画する必要があります。特定の側面にさらに興味がある場合は、コメントにリクエストを書いてください。次の記事でその要望を考慮します。

中小企業向けのソフトウェアインターネットゲートウェイ（Shorewall、OpenVPN、OSPF）。パート2

高度なショアウォールのセットアップ

Shorewallのシンプルな負荷分散と冗長性

怖くてひどいQoS

More articles:

中小企業向けのソフトウェアインターネットゲートウェイ（Shorewall、OpenVPN、OSPF）。 パート2

高度なショアウォールのセットアップ

Shorewallのシンプルな負荷分散と冗長性

怖くてひどいQoS

More articles:

中小企業向けのソフトウェアインターネットゲートウェイ（Shorewall、OpenVPN、OSPF）。パート2