これは歴史的に発展しており、これには賛否両論がありますが、会話は今ではそうではありません。
通常、各VLANにはグレーアドレスのネットワークが割り当てられ、NATを介して大きな世界に解放されます。 しかし、加入者は実際のホワイトアドレスを必要とする場合があり、最近まで/ 30ネットワークが与えられていました。 現在の現実には非常に無駄が多く、実際のアドレスを持つ加入者は、SuperVLANテクノロジー（RFC 3069）を使用して接続に転送されます。
すべてのアドレス-灰色と白の両方がDHCPを介してサブスクライバーに発行されます。 DHCP、NAT、およびシェーパーサービスは、FreeBSD 9.3を実行している同じサーバー上で動作します。 サーバーのハードウェアはごく普通です-Core i7、8Gb RAM、Intel E1G42ET。
チャレンジ：
各サブスクライバに、彼が持っていたのと同じ実際のアドレスを与えますが、/ 30マスクではなく、すべてとxxx1ゲートウェイに共通の新しい/ 24マスクを使用します。 サブスクライバーが他の誰かの実際のアドレスで作業できないことを確認します
灰色のアドレスを持つ加入者の場合、加入者にネットワークを発行し続けます。
SuperVlan ala FreeBSDの構築
Vlan9は技術的なVLANであり、何も接続されていません。トラフィックは、サブスクライバーにまだ発行されていない実際のアドレスに行きます。
Vlan10-灰色のアドレスを持つサブスクライバー
vlan11とvlan12は、実際のアドレスを持つ2つのサブスクライバです。
ifconfig vlan9 inet 1.1.1.1/24 ifconfig vlan10 inet 192.168.10.1/24 ifconfig vlan11 inet 1.1.1.1/32 route add 1.1.1.11 –iface vlan11 ifconfig vlan12 inet 1.1.1.1/32 route add 1.1.1.12 –iface vlan12
私たちの手でvlan11クライアントにアドレス1.1.1.11/24、gw 1.1.1.1を配置しました-インターネットはクライアントのために機能しています。
実際のアドレスを持つクライアント間のトラフィックが必要な場合は、ProxyARPを有効にします
sysctl net.link.ether.inet.proxyall=1
（この場合、プライベートスティッキーvlan（マンブリッジ）からのブリッジは使用できません。理由は以下で説明します）
今、最も興味深いことをしましょう
DHCPを介したアドレス配布
すなわち、ISC-DHCPD ver 4.3
アドレスは、リクエストの送信元のインターフェースに基づいて発行する必要があります。
残念ながら、isc-dhcpdの作成者は、システム管理者自身がシステム管理者よりも必要なものを確実によく知っていると確信しています。 そして、彼らは彼が足で自分自身を撃つことを許さず、人差し指をシステム管理者にひじを切り落とします。
その結果、クライアントからの要求をリッスンするインターフェイスのリストを指定できますが、dhcpd.conf configでこのインターフェイスのアドレスが取得するサブネットを指定しない場合、それは無視されます。
また、複数のインターフェイスで同じアドレスが指定されている場合、DHCPREQ要求は1つのサブネットで処理されます。
また、dhcpd.confに登録することはできません。サブネットも、プールも、ホストも、指定されたインターフェースに厳密に結び付けられません。
これは夢であり、実際には次のようには機能しません。
subnet 1.1.1.11 netmask 255.255.255.255 { option routers 1.1.1.1; range 1.1.1.11; interface vlan11; }
まあ...まあ、DHCPリレーがあります。 必要なポートでリレーを開始します。これにより、Option 82 Agent Circuit IDが追加され、dhcpd要求が送信されます。
試行1：
dhcpはループバックインターフェースを厳密にリッスンしたくないため、追加のvlan5を開始します。
rc.conf：
ifconfig_vlan5=”inet 192.168.5.1/24” dhcrelay_flags =”-a” dhcrelay_servers =”192.168.5.1” dhcrelay_ifaces =”vlan11 vlan12” dhcpd_ifaces =”vlan5 vlan10”
開始-開始しない...
dhcpdは、ソケットをバインドできないことを報告します。
リレー用とデーモン用の異なるインターフェイスが直接示されていますが、両方ともフォールバックソケットをアドレスにバインドしたい場合のために*：67
「ソケットで送信/フォールバック」の開始時にこの行を報告します。
当然のことながら、2番目のシステムを開始した人は「忙しい！」と言います。
私が見つけることができなかったこのフォールバックソケットを切断する方法と方法は可能かどうか。
試行2：
代替プログラムはdhcprelyaとdhcprelayです。
繰り返しますが、彼らはソケットをバインドできないと言います。 コードを調べ、isc-creationsとの基本的な違いを理解します。 ISCは、デバイススタックを使用し、ファイアウォールやその他の超過の前でも、ネットワークスタックのほぼ最初にシステムからパケットを奪います...代替エンジニアは標準のソケットメカニズムを使用しますが、複数のインターフェイスに同じアドレスがあるため、2番目のバインドアドレス1.1.1.1 ：67システムは再び報告します：「忙しい！」
試行3：
そして、dhcrelayがすべてのインターフェイスでリッスンし、リクエストをdhcpdに転送できるようにします。dhcpdは192.168.5.1のアドレスにのみ固定されます
dhcpdを再構築して、BPFを使用せず、ソケットを介して接続するようにします。
これを行うには、isc-dhcp43-serverポートのMakefileをすばやく修正します
追加する：
CONFIGURE_ARGS + =-enable-use-sockets
収集、実行-開始しましたが、機能しません。 Dhcpdは、クライアントにアドレスを割り当てたことをログに書き込みますが、クライアントはdhcpdから応答を受け取りません。
クライアントが灰色のアドレスを持つvlan10のアドレスを取得しようとするとき、tcpdumpを確認します。
tcpdump –i vlan10-クライアントからの要求があります-サーバーからの応答がありません。
tcpdump –i vlan5-沈黙
tcpdump –i lo0-ここで興味深いのは：
アドレス192.168.5.1からアドレス192.168.5.1へのリレーからデーモンへのudpパケットが表示されます
デーモンからアドレス192.168.5.1からアドレス192.168.10.1へのリレーへのudp応答が表示されます
そして、dhcrelayはBPFを介してのみリッスンするため、内部lo0インターフェイスを通過するパケットが表示されないため、dhcrelayを再構築してソケットを使用することは意味がないことが明らかになり、その後、「試行2」の状況に戻ります
試行4：
dhcrelayとdhcpdをSEPARATEサーバーに配布します。
サーバーdhcpd rc.conf：
ifconfig_vlan5=”inet 192.168.5.1/24”
サーバーdhcrelay rc.conf：
ifconfig_vlan5=”inet 192.168.5.2/24” dhcrelay_flags =”-a” dhcrelay_servers =”192.168.5.1”
動作しません。
そうそう...
「試行3」からtcpdumpを呼び出し、dhcpdサーバーに書き込みます
ルート追加192.168.10.0/24 192.168.5.2
ルート追加1.1.1.0/24 192.168.5.2
今では動作します。 vlan10のクライアントへのアドレスが提供します。
次に、実際のアドレスを持つクライアントに関するdhcpd情報を追加します。
インターネットには、エージェントIDと回線IDからのサブストリングがカットされ、サブポートが作成されて、いくつかのアドレスを接続ポートに割り当てることができるクラスの例がたくさんあります。
1つのアドレスで十分なので、次の行を含むホストを説明するだけで十分です。
ホスト識別子オプションagent.circuit-id "vlan11"
ブリッジを使用してSuperVLANを構築する場合、dhcrelayは、agent.circuit-id = "bridge0"でブリッジに接続されているすべてのインターフェースからの要求を転送するため、同じアドレスと強制ルーティングを持つインターフェースのみが転送されます。
合計：
ソリューションの利点-クライアントは新しい設定を自動的に受け取りますが、古いアドレスを持ちます。
短所-2台目のサーバーが必要
ToDo：クライアントのMACアドレスを変更する状況がどのように解決されているかを確認してください。 以前のポピーでまだ有効期限が切れていない場合、dhcpdはホストから同じ実際のアドレスを返します。
そして、isc-dhcpdの思いやりのある直接の著者に戻ります。
dhcpdがbpfを介してインターフェイスに着信する要求をインターセプトするには、dhcpd.conf configに、このインターフェイスのアドレスを含むサブネットセクションを登録する必要があります。
同時に、リレー経由で応答を発行するために使用するサブネットを指定する必要はありません。すべての一致を検索します。
dhcpd.confの構成は次のとおりです。
option domain-name "example.org"; option domain-name-servers 8.8.8.8, 8.8.4.4; default-lease-time 600; max-lease-time 7200; one-lease-per-client true; stash-agent-options true; update-conflict-detection false; authoritative; log-facility local7; subnet 192.168.5.0 netmask 255.255.255.0 { } subnet 192.168.10.0 netmask 255.255.255.0 { range 192.168.10.2 192.168.10.254; option routers 192.168.10.1; } subnet 192.168.14.0 netmask 255.255.255.0 { range 192.168.14.2 192.168.14.254; option routers 192.168.14.1; } subnet 1.1.1.0 netmask 255.255.255.0 { } group realip1 { option routers 1.1.1.1; host client11 { host-identifier option agent.circuit-id "vlan11"; fixed-address 1.1.1.11; } host client12 { host-identifier option agent.circuit-id "vlan12"; fixed-address 1.1.1.12; } host client28 { host-identifier option agent.circuit-id "vlan28"; fixed-address 1.1.1.13; } }
PS：予期しないレーキと解決策：
誰かがisc dhcrelayを8kインターフェイスに上げる必要がある場合
変える必要がある
ファイルのFD_SETSIZE値
/usr/src/sys/sys/select.h
/usr/include/sys/select.h
と
#define FD_SETSIZE 1024U
に
#define FD_SETSIZE 16384U
isc-dhcrelayまたはisc-dhcpdを再構築します