そこで、ディスクがついに死んだ古いシステムの代わりとして、Fedora Core 19を初めてインストールしました。システムはWebサーバーおよびゲートウェイ/ファイアウォールとして機能し、内部システムを保護します。ネットワーク構成がたくさんあるので、-の紹介を受けて、本当に気に入っていることがわかりました新しいファイアウォールデーモン、firewalld。
突然内部メールサーバーのmaillogファイルがおかしくなっているのを見つけたとき(それはいつもトラブルが発生したときです)、すべてがうまくいっていると思いました -物事がうまくいった後、たまたまそれを見ていたのは運が良かっただけです。
調査によると、私の内部メールシステム(ファイアウォールの背後で保護されている)は、すべての送信メールがゲートウェイシステムから送信されていると考えていたため、「内部」システムであり、スパマーはそれをオープンリレーであると判断しました。 どういうわけか、内部ゾーンと外部ゾーンの両方が「マスカレード」とマークされており、実際にはメールログファイルで認識されたIPアドレスがゲートウェイのIPであることに気づきました。転送された方法でログインするsshポートは、内部で間違ったIPが使用されていることも確認しました。
「問題ありません!」私は間違って考えました。はい、内部ゾーンでマスカレードをオフにすると、ゲートウェイを通過するときに内部システムに渡される間違ったIPが修正されました。ただし、説明できない(これまでのところ!)ため、問題は修正されませんでした。 ポート25が転送されなくなったように見えます!
他のポートが転送されています。少なくとも私が話した簡単にテストできるsshポートです。だから、私はただその派手なロギング機能をオンにする!コマンドは次のとおりです。
firewall-cmd --zone=external --add-rich-rule='rule family="ipv4" forward-port port="25" protocol="tcp" to-port="25" to-addr="192.168.1.1" log prefix="smtp-to-inside" level="info"'
永続的なオプションで試してみましたが、そうではありませんでした。/ var/log/messagesには何も表示されません-または他のログファイルを調べてみました。カーネルが単に無視しているようです。そのポート。内部メールシステムがファイアウォールで外部トラフィックをブロックする可能性があると思いましたが、ゲートウェイは接続の試行をログに記録する必要がありますが、何も取得しません。
任意そしてすべての助けに感謝します。
この問題はfirewalldとは何の関係もありませんが、DIDは、firewalldロギングのバグを明らかにします。
問題は、アップグレードの期間中、メールサービスを提供する内部システムのデフォルトルートを、アップグレードに関与しない別のゲートウェイ/ファイアウォールに切り替えたことでした。新しいシステムに問題があったので、これは良い考えだと思っていました。
新しいゲートウェイマシンをデフォルトルートとして使用するために内部SMTPサービングシステムを返すと、すべてが機能し始めました。 誰も教えてくれない要件があることがわかりました-まだ文書化されていませんが、私が見つけたので、いくつかの古いタイマーが確認します-デフォルトルートを同じに設定する必要がありますパケットがどこから転送されるかとしてORパケットが到着した場所から同じパスでパケットを返すように、特別なルートを設定する必要があります。それが要件です:戻りルートソースルートと等しくなければなりません。
頑張ってください!