Mulvad VPNの「ローカルネットワーク共有」ブロックからlibvirtが使用するdnsmasqを除外する方法

Question

下記のチェーンは別のテーブルに含める必要があります。例:

table inet allowedLocal {
    ...
}

許可する特定のトラフィックによって異なります。仮想マシンのDNS要求（およびホストからの応答）のみを許可するには、次のリンクを使用する必要があります。

chain input {
    type filter hook input priority mangle; policy accept;
    ip saddr 192.168.122.0/24 meta l4proto { tcp, udp } th dport 53 ct mark set 0x00000f41
}

（conntrack mark）を設定すると、ホストの応答チェーンはct mark必要ありませんhook output。応答チェーンはその要求の同じ「接続」に属するため、ct mark自動的に同じ接続が得られます。トラフィックが（場所）に入る前に設定されていることをpriority mangle確認してください。ct markchain inputtable inet mullvadct mark 0x00000f41 accept

私が知っている/記憶するのとは異なり、少なくともホスト自体から「ローカル」ネットワークにではなく、必要に応じて応答をルーティングするために正しいmeta mark（）を設定する必要はないようです。fwmark（驚くべきことに、実際の動作はアプリケーションごとに異なります。systemd-resolvedスタブ追加リスナーでテストするときにプレフィックスを含むがこれに限定されないすべてのルーティングを削除しても、応答は要求が発生したインターフェイスから来ます。応答は常にmainすべてのIPルール/代替テーブルを無視し、ルーティングテーブルに従ってルーティングされます。

すべての「接続」を許可したい場合VMによって起動それは(L3-) ターゲットがホストである、以下を削除できますmeta l4proto { tcp, udp } th dport 53。

chain input {
    type filter hook input priority mangle; policy accept;
    ip saddr 192.168.122.0/24 ct mark set 0x00000f41
}

上記のチェーンは「接続」を設定しません。ホストによって開始それは(L3-) VM に送信許可する。これらの「接続」を許可するには、次のものが必要です。

chain output {
    type route hook output priority filter; policy accept;
    ip daddr 192.168.122.0/24 ct mark set 0xf41 meta mark set 0x6d6f6c65
}

ちなみに、ct markこのチェーンの設定は主に仮想マシンの応答を許可することです。実際にホストからのトラフィックを許可することはのoif "wg-mullvad" accept規則chain outputですtable inet mullvad。トラフィックは後の段階でチェーンを通過するように見えるtype routeため、新しいルーティング決定が行われる前にも元のルートを許可する必要があります（なぜならmeta mark）。つまり、私の考えではあるチェーンによって「変更された」トラフィックを（追加で）フィルタリングするには（1つの代わりに）type route別のチェーンを使用する必要があります。type routetype filter（詳細に関心がない場合は、この段落を無視してもかまいません。それでも情報が完全に正確でない可能性があります。）

編集するchain prerouting：実際には、すべてのトラフィックに必要なトラフィックをtable inet mullvad設定することは、DNSがVM上で動作することを可能にするために、上記で提供されたチェーンが必要ないことを意味することに気づきました。試してみて役に立つかどうかを確認できますが、今はもともと疑っていたように、何らかの理由でアップストリームサーバーとして使用されないことが問題かもしれません...ct markiif != "wg-mullvad"dnsmasq10.64.0.1

Answer 1