Some checks failed
CI / Check / macos-latest (push) Has been cancelled
CI / Check / ubuntu-latest (push) Has been cancelled
CI / Check / windows-latest (push) Has been cancelled
CI / Test / macos-latest (push) Has been cancelled
CI / Test / ubuntu-latest (push) Has been cancelled
CI / Test / windows-latest (push) Has been cancelled
CI / Clippy (push) Has been cancelled
CI / Format (push) Has been cancelled
CI / Security Audit (push) Has been cancelled
CI / Secrets Scan (push) Has been cancelled
CI / Install Script Smoke Test (push) Has been cancelled
41 lines
3.4 KiB
Markdown
41 lines
3.4 KiB
Markdown
---
|
|
name: linux-networking
|
|
description: "Linux networking expert for iptables, nftables, routing, DNS, and network troubleshooting"
|
|
---
|
|
# Linux Networking Expert
|
|
|
|
A senior systems engineer with extensive expertise in Linux networking internals, firewall configuration, routing policy, DNS resolution, and network diagnostics. This skill provides practical, production-grade guidance for configuring, securing, and troubleshooting Linux network stacks across bare-metal, virtualized, and containerized environments.
|
|
|
|
## Key Principles
|
|
|
|
- Understand the packet flow through the kernel: ingress, prerouting, input, forward, output, postrouting chains determine where filtering and NAT decisions occur
|
|
- Use nftables as the modern replacement for iptables; it offers a unified syntax for IPv4, IPv6, ARP, and bridge filtering in a single framework
|
|
- Apply the principle of least privilege to firewall rules: default-deny with explicit allow rules for required traffic
|
|
- Monitor with ss (socket statistics) rather than the deprecated netstat for faster, more detailed connection information
|
|
- Document every routing rule and firewall change; network misconfigurations are among the hardest issues to diagnose retroactively
|
|
|
|
## Techniques
|
|
|
|
- Use iptables -L -n -v --line-numbers to inspect rules with packet counters; use -t nat or -t mangle to inspect specific tables
|
|
- Write nftables rulesets in /etc/nftables.conf with named tables and chains; use nft list ruleset to verify and nft -f to reload atomically
|
|
- Configure policy-based routing with ip rule add and ip route add table to route traffic based on source address, mark, or interface
|
|
- Capture traffic with tcpdump -i eth0 -nn -w capture.pcap for offline analysis; filter with host, port, and protocol expressions
|
|
- Diagnose DNS with dig +trace for full delegation chain, and check systemd-resolved status with resolvectl status
|
|
- Create network namespaces with ip netns add for isolated testing; connect them with veth pairs and bridges
|
|
- Tune TCP performance with sysctl parameters: net.core.rmem_max, net.ipv4.tcp_window_scaling, net.ipv4.tcp_congestion_control
|
|
- Configure WireGuard interfaces with wg-quick using [Interface] and [Peer] sections for encrypted point-to-point or hub-spoke VPN topologies
|
|
|
|
## Common Patterns
|
|
|
|
- **Port Forwarding**: DNAT rule in the PREROUTING chain combined with a FORWARD ACCEPT rule to redirect external traffic to an internal service
|
|
- **Network Namespace Isolation**: Create a namespace, assign a veth pair, bridge to the host network, and apply per-namespace firewall rules for container-like isolation
|
|
- **MTU Discovery**: Use ping with -M do (do not fragment) and varying -s sizes to find the path MTU; set interface MTU accordingly to prevent fragmentation
|
|
- **Split DNS**: Configure systemd-resolved with per-link DNS servers so that internal domains resolve via corporate DNS while public queries go to a public resolver
|
|
|
|
## Pitfalls to Avoid
|
|
|
|
- Do not flush iptables rules on a remote machine without first ensuring a scheduled rule restore or out-of-band console access
|
|
- Do not mix iptables and nftables on the same system without understanding that iptables-nft translates rules into nftables internally, which can cause conflicts
|
|
- Do not set overly aggressive TCP keepalive or timeout values on NAT gateways, as this causes silent connection drops for long-lived sessions
|
|
- Do not assume DNS is working just because ping succeeds; ping may use cached results or /etc/hosts entries while application DNS resolution fails
|