主页 / user-236012

user236012's questions

Martin Hope
user236012
Asked: 2021-12-05 02:21:10 +0800 CST
  • 0

我想从本地网络中分离出几台主机并将它们放在防火墙后面。我想使用 VLAN 来“物理地”分离它们，而不是只使用不同的子网。我的想法是使用支持 VLAN 的交换机，并像这样构建网络：

在此处输入图像描述

P1 和 P2、P3 和 P4 是四个不同的主机，它们属于两个独立的“物理”网络（VLAN 1 和 2）。它们应该受到 P5 上的防火墙/网关的保护。

P5 应该充当防火墙/网关，控制分离的主机和现有网络之间的数据。它只有一个网卡需要连接现有网络（无VLAN）和两个VLAN。

P6 是现有网络的上行链路。

我现在的问题是：

  1. 这个想法能否按预期工作（给定正确的配置） - 即，P5 上的主机可以有多个 IP/成为多个网络的一部分，只有一个 NIC，它充当分离主机和现有主机之间的网关/防火墙网络，如果没有我没有考虑过的陷阱/缺陷可能允许绕过防火墙的网络之间的数据流？
  2. 我猜交换机需要能够支持标记的 VLAN（而不仅仅是基于端口的 VLAN），因为 P5？
firewall vlan ethernet gateway
Martin Hope
user236012
Asked: 2018-09-05 15:49:10 +0800 CST
  • 2

我想将后缀配置为仅中继来自某些发件人地址的邮件。Postfix 应根据发件人的地址（“MAIL FROM:”）将邮件中继到不同的中继主机（/smarthosts）（Gmail、AOL、...）。

到目前为止，我当前的配置如下：

  • 用户通常在邮件中继的 postfix 上进行身份验证。如果他们无法进行身份验证，则无法进行中继。请注意，此身份验证与中继主机的身份验证不同。

  • 根据发件人的地址（“MAIL FROM:”），选择某个中继主机（smtp_sender_dependent_authentication, sender_dependent_relayhost_maps, smtp_sasl_password_maps）。这也很好用。

  • 但是，如果用户可以进行身份​​验证，并且有一个未包含在 中的发件人地址sender_dependent_relayhost_maps，则 postfix 会尝试直接中继邮件 - 由于 IP 地址限制（黑名单），这通常不起作用。

我现在的问题是：如何拒绝直接转发的邮件（没有智能主机），即发件人的地址未列在sender_dependent_relayhost_maps哪里？任何提示如何实现这一目标？

postfix
Martin Hope
user236012
Asked: 2015-05-17 14:11:16 +0800 CST
  • 3

在使用公共 wifi 时，出于隐私目的，我正在运行 OpenVPN-Server (Debian 8)。因此，客户端的所有网络流量都旨在通过 VPN 连接进行处理。服务器和客户端配置如下。

服务器配置：

port 1194
proto tcp
dev tun

ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt    
key /etc/openvpn/server.key
dh /etc/openvpn/dh.pem
tls-auth /etc/openvpn/tlsauth.key 0

user nobody
group nogroup

server 10.11.12.0 255.255.255.0

ifconfig-pool-persist ipp.txt
keepalive 10 120

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

persist-key
persist-tun

comp-lzo
status openvpn-status.log
verb 3

客户端配置：

client
remote X.X.X.X 1194
proto tcp

dev tun

resolv-retry-infinite

nobind

user nobody
group nogroup

persist-key
persist-tun

ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt    
key /etc/openvpn/client.key
tls-auth /etc/openvpn/tlsauth.key 0

comp-lzo 0
verb 2

在客户端上启动 VPN 服务时，路由表会发生如下变化。

路由表（192.168.178.0/24 表示公共wifi）：

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.11.12.13     128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.178.1   0.0.0.0         UG    1024   0        0 wlan0
10.11.12.1      10.11.12.13     255.255.255.255 UGH   0      0        0 tun0
10.11.12.13     0.0.0.0         255.255.255.255 UH    0      0        0 tun0
128.0.0.0       10.11.12.13     128.0.0.0       UG    0      0        0 tun0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0
192.168.178.0   0.0.0.0         255.255.255.0   U     0      0        0 wlan0
X.X.X.X         192.168.178.1   255.255.255.255 UGH   0      0        0 wlan0

启动 openvpn 时 syslog 的相关部分：

ovpn-client[3395]: OpenVPN 2.3.4 i586-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Dec  1 2014
ovpn-client[3395]: library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08    
ovpn-client[3395]: WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
ovpn-client[3395]: Control Channel Authentication: using '/etc/openvpn/tlsauth.key' as a OpenVPN static key file
ovpn-client[3395]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
ovpn-client[3395]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
ovpn-client[3396]: NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
ovpn-client[3396]: Attempting to establish TCP connection with [AF_INET]X.X.X.X:1194 [nonblock]
ovpn-client[3396]: TCP connection established with [AF_INET]X.X.X.X:1194
ovpn-client[3396]: TCPv4_CLIENT link local: [undef]
ovpn-client[3396]: TCPv4_CLIENT link remote: [AF_INET]X.X.X.X:1194
ovpn-client[3396]: VERIFY OK: depth=1, [...]
ovpn-client[3396]: VERIFY OK: depth=0, [...]
ovpn-client[3396]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
ovpn-client[3396]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
ovpn-client[3396]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
ovpn-client[3396]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
ovpn-client[3396]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
ovpn-client[3396]: [VPN-Server] Peer Connection Initiated with [AF_INET]X.X.X.X:1194
ovpn-client[3396]: TUN/TAP device tun0 opened
ovpn-client[3396]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
ovpn-client[3396]: /sbin/ip link set dev tun0 up mtu 1500
NetworkManager[556]: <info> (tun0): carrier is OFF
NetworkManager[556]: <info> (tun0): new Tun device (driver: 'unknown' ifindex: 15)
NetworkManager[556]: <info> (tun0): exported as /org/freedesktop/NetworkManager/Devices/14
ovpn-client[3396]: /sbin/ip addr add dev tun0 local 10.11.12.14 peer 10.11.12.13
NetworkManager[556]: <info> (tun0): link connected
ovpn-client[3396]: ERROR: Linux route add command failed: external program exited with error status: 2
ovpn-client[3396]: GID set to nogroup
ovpn-client[3396]: UID set to nobody
ovpn-client[3396]: Initialization Sequence Completed
NetworkManager[556]: <info> (tun0): device state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41]
NetworkManager[556]: <info> (tun0): device state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41]
NetworkManager[556]: <info> Activation (tun0) starting connection 'tun0'
NetworkManager[556]: <info> Activation (tun0) Stage 1 of 5 (Device Prepare) scheduled...
NetworkManager[556]: <info> devices added (path: /sys/devices/virtual/net/tun0, iface: tun0)
NetworkManager[556]: <info> device added (path: /sys/devices/virtual/net/tun0, iface: tun0): no ifupdown configuration found.
NetworkManager[556]: <info> Activation (tun0) Stage 1 of 5 (Device Prepare) started...
NetworkManager[556]: <info> (tun0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
NetworkManager[556]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) scheduled...
NetworkManager[556]: <info> Activation (tun0) Stage 1 of 5 (Device Prepare) complete.
NetworkManager[556]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) starting...
NetworkManager[556]: <info> (tun0): device state change: prepare -> config (reason 'none') [40 50 0]
NetworkManager[556]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) successful.
NetworkManager[556]: <info> Activation (tun0) Stage 3 of 5 (IP Configure Start) scheduled.
NetworkManager[556]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) complete.
NetworkManager[556]: <info> Activation (tun0) Stage 3 of 5 (IP Configure Start) started...
NetworkManager[556]: <info> (tun0): device state change: config -> ip-config (reason 'none') [50 70 0]
NetworkManager[556]: <info> Activation (tun0) Stage 5 of 5 (IPv4 Configure Commit) scheduled...
NetworkManager[556]: <info> Activation (tun0) Stage 3 of 5 (IP Configure Start) complete.
NetworkManager[556]: <info> Activation (tun0) Stage 5 of 5 (IPv4 Commit) started...
NetworkManager[556]: <info> (tun0): device state change: ip-config -> ip-check (reason 'none') [70 80 0]
NetworkManager[556]: <info> Activation (tun0) Stage 5 of 5 (IPv4 Commit) complete.
NetworkManager[556]: <info> (tun0): device state change: ip-check -> secondaries (reason 'none') [80 90 0]
NetworkManager[556]: <info> (tun0): device state change: secondaries -> activated (reason 'none') [90 100 0]
NetworkManager[556]: <info> Activation (tun0) successful, device activated.

我的问题是：

  1. 路由表是否正确？对我来说，由于有两个默认条目，它看起来有些奇怪。此外，在公共 wifi 路由器上记录流量时（使用 tcpdump），并非所有流量都通过 VPN 路由。

  2. ERROR: Linux route add command failed: external program exited with error status: 2syslog中的错误 ( ) 说明了什么？它可能与第一个问题有关吗？

编辑：谢谢你的回答，米哈尔。为了减少多播/本地/...流量，我还计划使用 iptables 来丢弃该流量。

我正在尝试使用 iptables 规则，如下所示：

#!/bin/bash

GATEWAY="192.168.178.1"

iptables -F

# Allow loopback device (internal communication)
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Allow DHCP communication with gateway
iptables -A INPUT -i wlan0 -p udp -s $GATEWAY/32 --dport 67:68 --sport 67:68 -j ACCEPT
iptables -A OUTPUT -o wlan0 -p udp -d $GATEWAY/32 --dport 67:68 --sport 67:68 -j ACCEPT

# Allow ICMP communication with gateway
iptables -A INPUT -i wlan0 -p icmp -s $GATEWAY/32 -j ACCEPT
iptables -A OUTPUT -o wlan0 -p icmp -d $GATEWAY/32 -j ACCEPT

#Allow VPN establishment
iptables -A OUTPUT -p tcp --dport 1194 -j ACCEPT
iptables -A INPUT -p tcp --sport 1194 -j ACCEPT

#Accept all TUN connections (tun = VPN tunnel)
iptables -A OUTPUT -o tun+ -j ACCEPT
iptables -A INPUT -i tun+ -j ACCEPT

#Set default policies to drop all communication unless specifically allowed
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

IMO，这些规则应该足以获得网关分配的 IP，建立到 OpenVPN 服务器的连接并处理该连接上的所有流量。但是，DNS 不起作用，尽管它也应该使用 VPN 连接。为什么这不起作用？

dnsmasq下一个编辑：在 VPN 服务器上设置本地名称服务器 ( )。服务器配置更改为

push "dhcp-option DNS 10.11.12.1"

代替

push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

在 VPN 服务器本身上运行dig +short serverfault.com @10.11.12.1时，可以成功检索主机名。如果该命令在不使用 VPN ( dig +short stackoverflow.com @X.X.X.X) 的不同主机上运行，​​也可以成功检索主机名。但是，当命令在连接到 VPN ( dig +short stackoverflow.com @10.11.12.1) 的客户端上运行时，命令会失败 ( ;; connection timed out; no servers could be reached)。为什么？iptables 设置为全部接受。

domain-name-system