株式会社グローバルゲート公式ブログ
firewalldを使わずiptablesを選ぶ理由：本格Firewall＆ルーター構築【実践編】
こんにちは！株式会社グローバルゲートでサーバ管理をしてるタカです。
サーバやネットワークのセキュリティ対策において、「Firewallをどう構築するか」は避けて通れないテーマです。
近年のLinux環境では firewalld が標準として採用されるケースが増えていますが、実務の現場では今なお iptables を選択する理由が明確に存在します。
特に、
・ルーター機能を兼ねたFirewall構築
・NATやポート転送を含む複雑な通信制御
・障害時に“何が起きているか”を即座に把握する運用
こうした要件が求められる企業ネットワークでは、内部動作が見えにくい抽象化レイヤよりも、挙動を完全に把握できるiptablesの方が適している場面は少なくありません。
本記事は、前編で解説した「iptablesによるFirewallの基礎」の続きで、後編として“実際に使える構成”を作ることを7章目から順番に書きたいと思います。
単なるパケットフィルタリングに留まらず、Linuxを本格的なルーター兼Firewallとして運用するために必要な考え方を、段階的に整理していきます。
後編では、IP転送やFORWARDチェーンの設計といったルーター構築の基礎から始まり、NAT（MASQUERADE / SNAT / DNAT）の使い分け、WAN・LAN・DMZを意識したゾーン設計、さらにfail2banと連携した実運用向けの防御まで踏み込みます。
加えて、iptables運用で多くの管理者が一度は悩む「通信が通らない」「SSHが繋がらない」といったトラブルの原因と対処法も、実例ベースで解説します。
firewalldが悪いわけではありません。
しかし、「なぜこの通信が通るのか／遮断されるのか」を自分の言葉で説明できることは、企業ネットワークを預かるエンジニアにとって大きな武器になります。
重ねて申しますがiptablesを理解することは、単に古い技術を学ぶことではなく、
ネットワークを守れるエンジニアになるための本質を学ぶことです。
前回の記事は以下を参照してください
7. ここから本番：iptablesで“ルーター”を作る基礎知識（導入）
ここまでの章では、iptablesを使ったFirewallの基本的な考え方や、INPUT/OUTPUTチェーンを中心とした防御について解説してきました。しかし、企業ネットワークや実運用の現場では、Linuxサーバは単なる「守られる側」ではなく、**通信を中継・制御するルーターとしての役割**を担うことが多くあります。
この章では、iptablesを使ってLinuxを「本格的なルーター」として動かすために欠かせない基礎知識を整理します。IP転送の有効化、FORWARDチェーンの考え方、そして「通す通信」と「落とす通信」をどう設計するか。これらは設定方法以前に、**考え方を間違えると通信が破綻する重要ポイント**です。
iptablesは自由度が高い反面、設計を誤ると「なぜ通らないのか分からない」状態に陥りがちです。本章では、実務で再現性の高い設計視点を意識しながら、後続のNAT設定やゾーン設計につながる土台を固めていきます。
Linuxルーターに必要な条件
Linuxをルーターとして動作させるための最初の条件は、IP転送（IP forwarding）が有効になっていることです。デフォルト設定では、多くのLinuxディストリビューションは自分宛ての通信しか処理せず、他のネットワークへパケットを転送しません。
IP転送を有効化することで、Linuxは「受け取ったパケットを別インターフェースへ流す」役割を担えるようになります。これはiptables以前の、カーネル（※OSの核の部分）レベルの前提条件です。
企業ネットワークでは、WAN側とLAN側、あるいはDMZをまたぐ通信を制御するケースが多く、IP転送が無効なままでは、どれだけiptablesルールを正しく書いても通信は成立しません。
また、sysctl設定として永続化する点も重要です。一時的に有効化して動作確認だけ行い、本番再起動後に通信が止まる――これは現場で非常によくあるトラブルです。iptables設計に入る前に、まず「ルーターとして動作できる状態か」を確認することが不可欠です。
FORWARDチェーンの考え方
iptablesでルーターを構築する際、最も重要になるのがFORWARDチェーンです。INPUTが「自分宛て」、OUTPUTが「自分発信」の通信を扱うのに対し、FORWARDは通過する通信を制御します。
たとえば、LANからWANへ出ていく通信、WANからDMZへ入る通信などは、すべてFORWARDチェーンで評価されます。この概念を正しく理解していないと、「INPUTは許可しているのに通信できない」という混乱が起きます。
企業向けの構成では、FORWARDチェーンは実質的にFirewallの中核です。どのネットワークから、どのネットワークへ、どのプロトコルを通すのか。そのルールを明示的に定義することで、意図しない通信を確実に遮断できます。
FORWARDチェーンは自由度が高い分、設計思想がそのままセキュリティレベルに直結します。後続のゾーン設計やNAT設定を見据え、ここで考え方を固めておくことが重要です。
“通すルール”と“落とすルール”の設計
iptables設計で初心者が最もつまずきやすいのが、「どこまで許可し、どこで落とすか」というルール設計です。実務では、すべてを許可してから塞ぐのではなく、必要な通信だけを通す（許可リスト方式）が基本になります。
特にFORWARDチェーンでは、「LAN→WANは許可」「WAN→LANは原則拒否」といった、方向性を意識した設計が不可欠です。通信の向きを考えずにルールを書くと、想定外の穴が生まれます。
また、DROPとREJECTの使い分けも重要な設計要素です。内部ネットワークではトラブルシュートを優先してREJECT、外部からの不要な通信はDROP、といった使い分けが現場ではよく行われます。
iptablesは上から順に評価されるため、「通すルール」と「落とすルール」の順序も含めて設計の一部です。この考え方が身につくと、後のNATやDMZ構成でも迷いが激減します。
iptablesコマンド例：ルーター構築の実践
① IP転送を有効化する（必須）
まずは Linux を「ルーターとして動かす」ための前提条件。
永続化は必ず行う。
反映確認：
② FORWARDチェーンの初期ポリシーを定義する
まずは 「通さない」を基本にする。
③ LAN → WAN の通信を許可する（基本ルール）
例：
LAN：eth1（192.168.10.0/24）
WAN：eth0
戻り通信も忘れずに許可。
双方向セットで1つの通信、ここが超重要ポイント！！
④ WAN → LAN の直接通信は拒否する
原則、外部から内部への新規通信は拒否。
これで 外→内の勝手な侵入は防止できる
⑤ ログを取る（トラブルシュート用）
いきなりDROPせず、ログを挟むのが実務では鉄板。
ログ確認：
⑥ ルール確認（必須）
・パケット数が増えているか
・想定外の通信がDROPされていないか
ここを見ずに次へ進まないこと。
※実務ワンポイント
・まず DROP ありきで設計する
・FORWARD は「どこから → どこへ」を常に意識
・INPUTが通っても FORWARD が通らなければ通信は成立しない
・ログを仕込むことで「なぜ通らないか」が見える
8. NATを理解する：MASQUERADEとSNAT/DNATの使い分け（導入）
ルーター構築において、iptablesと並んで必ず理解しておくべき概念が NAT（Network Address Translation） です。
企業ネットワークでは、内部LANにプライベートIPアドレスを割り当て、外部インターネットとは1つ、もしくは少数のグローバルIPで通信する構成が一般的です。この「内と外のIPを変換する役割」を担うのがNATです。
iptablesでは、NATは filter テーブルとは別の natテーブル で制御され、MASQUERADE、SNAT、DNATといった仕組みを使い分けおり、「とりあえず動かすNAT」ではなく、なぜその方式を選ぶのかを重視します。ここを理解しておくことで、通信トラブルや将来の構成変更にも強いFirewall／ルーター設計が可能になります。
NATとは何か（超わかりやすく）
NATとは簡単に言えば、通信途中でIPアドレスを書き換える仕組みです。
たとえば、LAN内のPC（192.168.10.100）がインターネットへ通信する際、そのままでは外部と通信できません。そこで、ルーターが送信元IPを「自分のグローバルIP」に書き換えて通信します。
iptablesでは、この処理を POSTROUTINGチェーン で行います。
NATはFirewallとは別物ですが、FORWARDチェーンと密接に関係しており「FORWARDで許可されているのに外に出られない」場合、多くはNAT設定が不足しています。
NATは「通す・落とす」ではなく「書き換える」処理であることを意識すると、iptables全体の理解が一段深まります。
MASQUERADEが便利な理由（動的IP向け）
MASQUERADEは、送信元IPを自動的に外側インターフェースのIPに変換するNAT方式です。
DHCPなどでグローバルIPが変わる環境では、最も手軽で安全な選択肢です。
・eth0：WAN側インターフェース
・LAN→WANの通信が対象
MASQUERADEはIP変更に自動追従する反面、毎回IPを確認するため わずかに負荷が高い 特性があります。
とはいえ、一般的な企業ネットワークやクラウド環境では、まずMASQUERADEで問題ありません。「まず動かす」には最適な方式です。
固定IPならSNATを選ぶ理由
WAN側が固定グローバルIPの場合は、SNAT を使う方が設計として明確になります。
SNATは送信元IPを明示的に指定するため
・負荷が少ない
・ログやトラブル解析がしやすい
といったメリットがあります。
企業向けFirewallでは、「固定IP環境＝SNAT」が基本と覚えておくと設計判断に迷いません。
MASQUERADEとSNATはどちらか一方を選ぶものであり、混在させないのが鉄則です。
ポート転送（DNAT）で内部サーバを公開する考え方
DNATは、宛先IPやポートを内部サーバへ書き換える仕組みです。
Webサーバ公開などで使われます。
さらにFORWARDチェーンで許可が必要です。
DNATは「公開＝危険」になりやすいため、
・必要最小限のポートのみ
・DMZ構成と組み合わせる
といった設計が重要です。
次章のゾーン設計（WAN/LAN/DMZ）と非常に相性が良いポイントでもあります。
9. 本格Firewall構築：ゾーン設計（WAN / LAN / DMZ）で考える（導入）
企業ネットワークにおけるFirewall設計で重要なのは、「どの通信を通すか」以前に、ネットワークをどう分けて考えるかです。
iptablesは非常に自由度が高いため、ルールを積み重ねるだけでも動作しますが、ゾーンの概念を持たずに構築すると、後からの変更や拡張が困難になります。
そこで本章では、WAN・LAN・DMZというゾーン設計を軸に、iptablesで本格的なFirewallを構築する考え方を解説します。
ゾーンを分けることで、「内→外」「外→内」「内→内」といった通信の性質が明確になり、最小限のルールで高いセキュリティを実現できます。
これは大規模環境だけでなく、小規模な企業ネットワークや検証環境でも有効な設計手法です。iptablesを“ルールの集合”としてではなく、ネットワーク構成そのものを表現するツールとして使うための重要なステップになります。
ありがちなネットワーク構成例
企業ネットワークでよく見られる基本構成は以下の3ゾーンです。
・WAN：インターネット側
・LAN：社内ネットワーク
・DMZ：外部公開サーバ用ネットワーク
たとえば、WebサーバやメールサーバをLANと同一セグメントに置くと、侵入時の被害が内部全体に及びやすくなります。
ゾーン設計の目的は、「信頼レベルの異なるネットワークを分離すること」です。
iptablesでは、インターフェース（eth0 / eth1 / eth2）やIPレンジを基準にゾーンを定義します。
これにより、「どこからどこへ通信しているのか」をルール上で明確に表現でき、レビューや引き継ぎもしやすくなります。
DMZを分けるメリット
DMZ（DeMilitarized Zone）は、外部公開を前提としたゾーンです。
WANから直接LANへ通信させないための緩衝地帯として機能します。
DMZを分けることで、仮にWebサーバが侵害されても、LANへの横展開を防げます。
これは企業Firewallでは必須レベルの設計思想です。
最小許可ルールの作り方（許可リスト方式）
iptables設計の基本は「許可リスト方式」です。
“内→外”と“外→内”を分けて設計する
通信は常に方向性を持っています。
「LAN→WAN」は業務上必要でも、「WAN→LAN」は原則不要です。
方向を意識してルールを書くことで、
・事故的な全開放
・想定外の通信許可
を防げます。
iptablesは「書けてしまう」からこそ、書かない設計が重要なのです。
10. 設定を永続化する：iptables-service運用の基本（導入）
iptablesは非常に強力なFirewallですが、設定が再起動で消えるという特性を正しく理解していないと、思わぬ事故につながります。検証環境では問題なく動いていたのに、本番サーバの再起動後に通信が全停止――これは現場で本当によくあるトラブルです。
本章では、Rocky Linux 9で firewalld を使わず、iptables-service を前提とした永続化運用を解説します。単に「保存する方法」を紹介するだけでなく、ルール管理の考え方や、手作業を減らすための工夫も含めて整理します。
iptablesは“書いて終わり”ではなく、“運用して守り続ける”ものです。本章を通して、再起動や障害に強いFirewall運用の基礎を身につけていきましょう。
再起動で消える問題を理解する
iptablesで設定したルールは、メモリ上に存在する一時的な状態です。そのため、OS再起動やiptablesサービスの再起動で消えてしまいます。
この挙動を知らずに運用すると
・再起動直後にFirewallが無防備になる
・逆に全通信が遮断される
といった致命的な状態を引き起こします。
重要なのは「iptablesは常に揮発的である」という前提を持つことです。ここを理解していれば、永続化の必要性は自然と腑に落ちます。
Rocky Linuxでの永続化（iptables-service前提）
Rocky Linux 9では、iptablesの永続化に iptables-services を使用します。
現在のルールを保存：
再起動後に自動復元されることを確認：
この /etc/sysconfig/iptables が、Firewall構成の正本になります。
本番環境では、このファイルを必ずバックアップ対象に含めることが重要です。
ルール管理のコツ（手作業を減らす）
ptables運用で事故を防ぐ最大のポイントは、直接コマンドを叩き続けないことです。
おすすめは以下の運用です。
・変更は一時ルールで検証
・問題なければ iptables-save で反映
・設定ファイルをGit等で管理
これにより、
・変更履歴が追える
・差分レビューができる
・ロールバックが容易
という、企業運用に耐えるFirewall管理が可能になります。
11. 運用を自動化する：fail2ban × iptables連携（実務で強い）
導入
Firewallは通信を制御する重要な仕組みですが、現実のインターネットでは常に様々な攻撃が行われています。特にSSHやWebサービスを公開しているサーバでは、パスワード総当たり攻撃（ブルートフォース攻撃）が日常的に発生します。iptablesだけでも通信制御は可能ですが、攻撃元IPを手動でブロックし続けるのは現実的ではありません。
そこで活躍するのが fail2ban です。fail2banはログを監視し、一定回数以上の認証失敗などを検知すると、自動的にiptablesへルールを追加して攻撃元IPを遮断します。つまり、Firewallとログ監視を組み合わせた 自動防御システム と言えます。
本章では、fail2banの基本的な役割からiptablesとの連携の仕組み、そして実務運用で重要な誤BAN対策までを解説します。ここを理解すると、Firewallは単なる通信制御ではなく、攻撃に対して自動で反応する防御装置へと進化します。
brute force攻撃の現実
公開サーバをインターネットに接続すると、数分以内にSSHへのログイン試行が始まるケースも珍しくありません。これは特定のサーバを狙った攻撃ではなく、インターネット全体を対象とした自動スキャンによるものです。
攻撃者は大量のIPアドレスを巡回し、一般的なポート（22、80、443など）に対してログイン試行を繰り返します。パスワード認証を使用している場合、弱いパスワードは短時間で突破される可能性があります。
iptablesだけでIP単位の遮断を行うことも可能ですが、攻撃元は頻繁に変わるため手動対応では追いつきません。そこでfail2banがログを解析し、「一定回数以上失敗したIP」を自動的にブロックする仕組みが有効になり、これにより攻撃を受けても自動的に防御が強化される環境を構築できます。
fail2banの役割
fail2banは、サーバのログファイルを監視し、不正アクセスの兆候を検出するとFirewallへルールを追加するツールです。主に以下の流れで動作します。
ログを監視
認証失敗を検出
IPアドレスを抽出
iptablesでBAN
Rocky Linuxでは次のようにインストールします。
サービスを有効化します。
設定ファイルは主に以下を使用します。
ここにSSHなどの保護ルールを定義します。
iptablesでBANされる仕組み
fail2banは攻撃を検出すると、iptablesに専用チェーンを作成してIPアドレスを追加します。
例：
表示例
つまりfail2banは、iptablesの以下の処理を自動で実行しているイメージです。
SSH保護の基本設定例：
意味
この設定により、SSHへのブルートフォース攻撃を自動的に遮断できます。
誤BAN・解除・ホワイトリスト運用
fail2ban運用で注意すべきなのが 誤BAN です。管理者自身がログインに失敗し続けると、自分のIPがブロックされることがあります。
そのため、管理ネットワークはホワイトリストに登録しておくことが重要です。
設定例：
BANされたIPの確認：
BAN解除：
このように、fail2banはiptablesと連携することで自動防御を実現しますが、運用ルールを整備することでより安全に利用できます。
12. よくあるトラブルと解決方法（初心者が詰むポイント集）
導入
iptablesは柔軟で強力なFirewallですが、その自由度の高さゆえに「設定したのに通信できない」という状況に陥ることも少なくありません。特にLinuxで初めてFirewallやルーター構築を行う場合、設定ミスや理解不足によってトラブルが発生することがあります。
実務の現場でも、iptablesが原因の通信トラブルは珍しくありません。しかし多くの場合、その原因は複雑なものではなく、基本的なポイントを確認することで解決できます。
iptables運用で初心者がつまずきやすい代表的なトラブルを取り上げ、それぞれの原因と対処方法を解説します。SSH接続ができなくなった場合の確認ポイント、通信が通らないときの調査方法、NAT設定のよくある落とし穴など、実務でも頻繁に遭遇するケースを中心に整理します。
これらを理解しておくことで、iptablesの設定ミスに慌てることなく、落ち着いて原因を特定し解決できるエンジニアへと一歩近づくことができます。
SSHが繋がらなくなった
iptables設定変更後に最も多いトラブルが、SSH接続できなくなる問題です。
これはINPUTチェーンでSSHポートを許可していない場合に発生します。
確認コマンド
SSH許可ルール例
また、すでに接続しているSSHセッションが切断されないよう、次のルールも重要です。
実務では以下を徹底すると安全です。
・SSH許可ルールを最初に書く
・Firewall変更はコンソールから行う
・変更前にバックアップを取る
通るはずの通信が通らない
iptables設定で通信が通らない場合、まずどのチェーンで止まっているかを確認することが重要です。
iptablesは以下の順序で評価されます。
・INPUT
・FORWARD
・OUTPUT
ルール確認
特にルーター構成では FORWARDチェーン が原因になることが多いです。
例
トラブル調査ではパケットカウンタを見ると役立ちます。
パケット数が増えていない場合、そのルールに到達していない可能性があります。
NATしてるのに外に出れない
LANからインターネットへ通信できない場合、多くはNAT設定不足です。
確認ポイント
・IPフォワード有効化
・MASQUERADE設定
・FORWARD許可
IP転送確認
NAT設定例
LAN→WAN通信許可
この3つが揃っていないと通信は成立しません。
ルール順序の罠（上から評価）
iptablesは上から順番に評価されます。
この仕組みを理解していないと、意図したルールが適用されません。
例えば次の設定
この場合、SSH許可ルールは一切適用されません。
なぜなら最初のDROPで処理が終了するためです。
正しい例
ルール順序はFirewall設計そのものと言えます。
ログの見方がわからない
iptablesトラブル解決で非常に役立つのがログ出力です。
ログルール例
ログ確認
特定ログのみ
ログを見ることで
・どの通信が遮断されたか
・どのIPからアクセスが来ているか
を確認できます。
iptables運用でトラブルが発生しても、多くの場合は基本ポイントを確認することで解決できます。
特に重要なのは以下です。
・SSH許可ルールを最初に設定する
・FORWARDチェーンを確認する
・NAT設定を忘れない
・ルール順序を意識する
・ログを活用する
iptablesは難しい技術ではありません。
仕組みを理解すれば、トラブルにも冷静に対応できる強力なツールになります。
まとめ：iptablesを理解すると守れるようになる
「firewalldを使わずiptablesを選ぶ理由」というテーマのもと、Linuxサーバを本格的なFirewall・ルーターとして構築するための考え方と実践方法を段階的に解説してきました。iptablesは古くから存在する仕組みですが、その柔軟性と制御力の高さから、現在でも多くのサーバ環境で利用されている重要な技術です。
前編では、iptablesの基本概念やチェーンの役割、そしてFirewall設計の基本となる「必要な通信だけを許可する」という考え方を中心に解説しました。Linuxの通信処理の流れを理解し、INPUT・OUTPUT・FORWARDチェーンの役割を把握することが、iptablesを使いこなす第一歩になります。Firewallは単なる設定ではなく、ネットワークの安全性を設計する重要な要素です。
後編では、より実務的な内容として、Linuxをルーターとして運用するための設定やNATの仕組み、ゾーン設計の考え方について解説しました。特にWAN・LAN・DMZといったネットワーク分離の概念は、企業ネットワークのセキュリティ設計において欠かせません。iptablesのFORWARDチェーンを適切に利用することで、ネットワーク間通信を安全に制御することが可能になります。
また、実際の運用を想定し、iptablesの設定を永続化する方法や、fail2banと連携した自動防御の仕組みについても紹介しました。インターネット上では常に様々な攻撃が行われているため、Firewallは単に通信を遮断するだけではなく、ログ監視や自動ブロックといった仕組みと組み合わせて運用することが重要です。これにより、サーバはより安全で安定した運用が可能になります。
さらに、iptablesを利用する際によく発生するトラブルとその解決方法についても整理しました。SSH接続ができなくなる問題や、NAT設定の不足による通信トラブルなどは、基本的な仕組みを理解していれば落ち着いて対応できます。iptablesは複雑に見えることもありますが、通信の流れとルールの順序を理解することで、確実に扱えるようになります。
iptablesは単なるコマンドの集合ではなく、Linuxネットワークを理解するための重要な学習ツールでもあります。本記事を通して、Firewallの仕組みやネットワーク制御の基本を理解することで、より安全なサーバ運用につながるはずです。
今後さらに理解を深めたい場合は、nftablesやWAF（Web Application Firewall）、IDS/IPSといった技術へと学習を広げていくとよいでしょう。これらの技術は、iptablesと同様にサーバセキュリティを支える重要な要素です。
iptablesを理解することは、単にFirewallを設定することではありません。
ネットワークを理解し、サーバを守る力を身につけることでもあります。
GSVは企業の大切なデータを守る安全なNASサーバーシステムです。自動バックアップやRAID構成による多重保存で、データの消失リスクを最小限に抑えます。ネットワーク接続だけで社内外から安全にデータにアクセス可能で、異なるOS間でもスムーズな運用が可能です。
スケジュール管理やToDoリストの一元管理機能を備え、チームの業務効率化を支援します。契約期間中の無償アップデートで常に最新機能を利用可能です。
さらに、無停電電源装置（UPS）の標準装備、ウイルス検知システム、柔軟なアクセス制限により、物理的な障害やセキュリティリスクからも企業データを保護。GSVは安全で効率的なデータ管理環境を提供します。
【関連記事】
