主页 / server / 问题

问题[icmp](server)

Martin Hope
Abid
Asked: 2022-01-04 11:46:03 +0800 CST
  • 0

我在路由器上配置了 VPN（路由器型号为 bintec be.ip plus）。

客户端使用 IKEv2 成功建立 VPN 连接（路由器可通过 DynDNS 访问）。

路由器的本地 IP 地址为 192.168.73.1。本地设备的 IP 地址之一是 192.168.73.150。

问题是：有时VPN 客户端无法访问本地网络中的设备。例如 ping 失败：

> ping 192.168.73.150
PING 192.168.73.150 (192.168.73.150): 56 data bytes
Request timeout for icmp_seq 0

客户端始终可以访问路由器本身：

> ping 192.168.73.1
PING 192.168.73.1 (192.168.73.1): 56 data bytes
64 bytes from 192.168.73.1: icmp_seq=0 ttl=63 time=83.713 ms

并且路由器始终可以访问本地设备：

> ping 192.168.73.150
PING 192.168.73.150: 64 data bytes
64 bytes from 192.168.73.150: icmp_seq=0. time=0.569 ms

因为它有时会失败，所以我怀疑这是防火墙问题。

由于从路由器到设备的 ping 数据包成功，我怀疑这是本地网络问题。

我怀疑某种路由问题，但完全不知道如何处理该问题。

任何想法如何进一步调查？

vpn ping icmp
Martin Hope
Hoto Cocoa
Asked: 2021-07-16 02:14:54 +0800 CST
  • 0

我有一个来自 RIR 的 IP 块。

我正在使用两个提供商对“某些”IP 进行任播。我将其称为 A 和 B。

当该 IP 不在该位置时，我想转发给其他提供商。我正在使用两台 Ubuntu 服务器来 BGP 宣布和转发数据包，以及提供者 A 和单播端点之间的 pfSense 机器。

任播 IP 效果很好。但是，如果客户端靠近提供商 B，则该数据包不会到达端点。

这是它的配置方式：

Client --> Provider B -(GRE, Static Route)-> Provider A -(GRE, Static Route)-> pfSense --> Endpoint
                                                                             ^ Here is problem

确切的问题是数据包没有从提供商 A 转发到 pfSense。我可以在 Provider A Server tcpdump 上看到 ICMP 数据包，但在 pfSense tcpdump 上看不到。我允许防火墙，但我看不到任何被阻止的日志。通过位于 pfSense 和提供商 A 之间的 GRE 隧道的所有端点流量。

如果我使用 Provider B Server 进行 ping，那也不起作用。但是，如果我在提供程序 A 之间使用 GRE 接口 IP 进行 ping 操作，即使没有 NAT 也可以。

当然，当我在 Provider A 附近执行 ping 操作时，我可以 ping 到 Endpoint。

什么有效（本身意味着提供者的服务器）：

Client(or itself) --> Provider A or B -(GRE, Static Route)-> pfSense -(GRE, Static Route)-> Anycast IP

Client(or itself) --> Provider A -(GRE, Static Route)-> pfSense -(GRE, Static Route)-> Unicast IP at near Provider A

Provider B -(GRE, Static Route, GRE IP or same subnet IP excluding Anycasted)-> pfSense -(GRE, Static Route)-> Unicast IP at near Provider A

Unicast IP at near Provider A --> pfSense -(GRE, Static Route)-> Provider A

Provider B --> Server near Provider B

什么不起作用：

Client(or itself) --> Provider B -(GRE, Static Route)-> Provider A -(GRE, Static Route, Traffic stops here)-> pfSense -(GRE, Static Route)-> Unicast IP at near Provider A

Unicast IP at near Provider A --> pfSense -(GRE, Static Route)-> Provider B --> Server near Provider B --> Provider B --> Provider A -(Traffic stops here)-> pfSense --> Endpoint

这是sysctl -p结果：

Provider A
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.ipv4.conf.all.accept_redirects = 1
net.ipv6.conf.all.accept_redirects = 1
net.ipv4.conf.all.send_redirects = 1
net.ipv4.conf.all.accept_source_route = 1
net.ipv6.conf.all.accept_source_route = 1
net.ipv6.conf.all.accept_ra = 2
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

Provider B
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.ipv4.conf.all.accept_redirects = 1
net.ipv6.conf.all.accept_redirects = 1
net.ipv4.conf.all.send_redirects = 1
net.ipv4.conf.all.accept_source_route = 1
net.ipv6.conf.all.accept_source_route = 1

如果需要更多信息，请告诉我。谢谢。

icmp bgp
Martin Hope
David Roonie
Asked: 2021-05-19 00:08:48 +0800 CST
  • 0

使用 (traceroute -q 1 serverAddress) 时，我们知道它从 TTL(Time to Live) = 1 开始。当它通过路由器时，路由器将 TTL 减 1。如果该路由器的 TTL 变为 0，它会发回 ICMP错误 TTL 超出消息。现在，告诉我，路由器会将错误消息发送回客户端（意味着我/我们）。现在路由器如何知道要设置什么 TTL。当我使用wireshark时，我收到了接收ICMP错误消息，显示初始TTL = 5的udp数据包的TTL = 64。路由器如何设置TTL？

networking udp icmp wireshark traceroute
Martin Hope
bug.spencor
Asked: 2021-02-08 08:54:31 +0800 CST
  • 2

几个月以来，我在发送电子邮件时遇到了零星的问题。

根据源 IP，使用 tcpdump 我终于发现我从似乎是我的电子邮件提供商那里收到了“端口无法访问”的消息。但是我的电子邮件提供商说他们在他们的网络中找不到问题，并说它一定在我的网络中。为了排除防火墙的问题，我设置了端口镜像，并在连接到作为网桥运行的电缆调制解调器的端口上捕获了数据包。

我已经做了很多故障排除。我懂了：

  • 当我通过 Wi-Fi 从 Android 手机或有线 PC 上的 Thunderbird 发送时，都会发生错误。
  • 当我向电子邮件提供商发送到 SMTP 端口 465 或 587 时发生错误
  • 它并不总是发生；经过一番尝试，邮件终于被发送了；或者在第一次尝试时发送
  • 我刚刚看到，在接收 DNS 响应时，我的 DNS 解析器也将“端口不可达”发送到转发 DNS 服务器（1.1.1.1、1.0.0.1）。我想这与电子邮件问题无关，但谁知道呢？

这是我遇到的 ICMP 错误的一个示例。

Internet Control Message Protocol
    Type: 3 (Destination unreachable)
    Code: 3 (Port unreachable)
    Checksum: 0x8c59 [correct]
    [Checksum Status: Good]
    Unused: 00000000
    Internet Protocol Version 4, Src: <my-ip>, Dst: <smtp-server-ip>
    Transmission Control Protocol, Src Port: 48624, Dst Port: 587, Seq: 3998125229
        Source Port: 48624
        Destination Port: 587
        Sequence number: 3998125229
        [Stream index: 0]
        Acknowledgment number: 0
        Acknowledgment number (raw): 0
        1010 .... = Header Length: 40 bytes (10)
        Flags: 0x002 (SYN)
        Window size value: 29200
        [Calculated window size: 29200]
        Checksum: 0x3680 [unverified]
        [Checksum Status: Unverified]
        Urgent pointer: 0
        Options: (20 bytes), Maximum segment size, SACK permitted, Timestamps, No-Operation (NOP), Window scale
        [Timestamps]

这里会出现什么问题，以及网络的哪个部分？问题既不在我的网络也不在电子邮件提供商的网络中是否合理？

networking smtp icmp smtp-auth
Martin Hope
fat_mike
Asked: 2021-01-31 04:53:24 +0800 CST
  • 0

在下面的日志记录中，我将我的 eth MAC 地址替换ETH_MAC_ADDRESS为我的服务器的 IP，MY_SERVER_IP并将其他 IP 替换为STRANGE_IP加号以区分。

Jan 29 15:11:48 cld kernel: [140229.731612] [UFW BLOCK] IN=eth0 OUT= MAC=ETH_MAC_ADDRESS SRC=STRANGE_IP_1 DST=MY_SERVER_IP LEN=107 TOS=0x00 PREC=0xC0 TTL=53 ID=46005 PROTO=ICMP TYPE=3 CODE=3 [SRC=MY_SERVER_IP DST=STRANGE_IP_1 LEN=79 TOS=0x00 PREC=0x00 TTL=233 ID=55136 PROTO=UDP SPT=30910 DPT=389 LEN=59 ] 
Jan 29 15:11:48 cld kernel: [140229.790143] [UFW BLOCK] IN=eth0 OUT= MAC=ETH_MAC_ADDRESS SRC=STRANGE_IP_2 DST=MY_SERVER_IP LEN=107 TOS=0x00 PREC=0xC0 TTL=57 ID=47474 PROTO=ICMP TYPE=3 CODE=1 [SRC=MY_SERVER_IP DST=STRANGE_IP_3 LEN=79 TOS=0x00 PREC=0x00 TTL=247 ID=43802 PROTO=UDP SPT=30910 DPT=389 LEN=59 ] 
Jan 29 15:11:48 cld kernel: [140229.803157] [UFW BLOCK] IN=eth0 OUT= MAC=ETH_MAC_ADDRESS SRC=STRANGE_IP_2 DST=MY_SERVER_IP LEN=107 TOS=0x00 PREC=0xC0 TTL=57 ID=47475 PROTO=ICMP TYPE=3 CODE=1 [SRC=MY_SERVER_IP DST=STRANGE_IP_3 LEN=79 TOS=0x00 PREC=0x00 TTL=247 ID=36766 PROTO=UDP SPT=30910 DPT=389 LEN=59 ] 
Jan 29 15:11:48 cld kernel: [140229.816160] [UFW BLOCK] IN=eth0 OUT= MAC=ETH_MAC_ADDRESS SRC=STRANGE_IP_2 DST=MY_SERVER_IP LEN=107 TOS=0x00 PREC=0xC0 TTL=57 ID=47476 PROTO=ICMP TYPE=3 CODE=1 [SRC=MY_SERVER_IP DST=STRANGE_IP_3 LEN=79 TOS=0x00 PREC=0x00 TTL=247 ID=26493 PROTO=UDP SPT=30910 DPT=389 LEN=59 ] 
Jan 29 15:11:48 cld kernel: [140229.831386] [UFW BLOCK] IN=eth0 OUT= MAC=ETH_MAC_ADDRESS SRC=STRANGE_IP_2 DST=MY_SERVER_IP LEN=107 TOS=0x00 PREC=0xC0 TTL=57 ID=47477 PROTO=ICMP TYPE=3 CODE=1 [SRC=MY_SERVER_IP DST=STRANGE_IP_3 LEN=79 TOS=0x00 PREC=0x00 TTL=247 ID=3269 PROTO=UDP SPT=30910 DPT=389 LEN=59 ] 
Jan 29 15:11:48 cld kernel: [140229.844130] [UFW BLOCK] IN=eth0 OUT= MAC=ETH_MAC_ADDRESS SRC=STRANGE_IP_2 DST=MY_SERVER_IP LEN=107 TOS=0x00 PREC=0xC0 TTL=57 ID=47478 PROTO=ICMP TYPE=3 CODE=1 [SRC=MY_SERVER_IP DST=STRANGE_IP_3 LEN=79 TOS=0x00 PREC=0x00 TTL=247 ID=20707 PROTO=UDP SPT=30910 DPT=389 LEN=59 ] 
Jan 29 15:11:48 cld kernel: [140229.856986] [UFW BLOCK] IN=eth0 OUT= MAC=ETH_MAC_ADDRESS SRC=STRANGE_IP_4 DST=MY_SERVER_IP LEN=107 TOS=0x00 PREC=0x00 TTL=52 ID=29529 PROTO=ICMP TYPE=3 CODE=1 [SRC=MY_SERVER_IP DST=STRANGE_IP_4 LEN=79 TOS=0x00 PREC=0x00 TTL=242 ID=33191 PROTO=UDP SPT=30910 DPT=389 LEN=59 ] 
Jan 29 15:11:48 cld kernel: [140229.844130] [UFW BLOCK] IN=eth0 OUT= MAC=ETH_MAC_ADDRESS SRC=STRANGE_IP_2 DST=MY_SERVER_IP LEN=107 TOS=0x00 PREC=0xC0 TTL=57 ID=47478 PROTO=ICMP TYPE=3 CODE=1 [SRC=MY_SERVER_IP DST=STRANGE_IP_3 LEN=79 TOS=0x00 PREC=0x00 TTL=247 ID=20707 PROTO=UDP SPT=30910 DPT=389 LEN=59 ] 
Jan 29 15:11:48 cld kernel: [140229.856986] [UFW BLOCK] IN=eth0 OUT= MAC=ETH_MAC_ADDRESS SRC=STRANGE_IP_4 DST=MY_SERVER_IP LEN=107 TOS=0x00 PREC=0x00 TTL=52 ID=29529 PROTO=ICMP TYPE=3 CODE=1 [SRC=MY_SERVER_IP DST=STRANGE_IP_4 LEN=79 TOS=0x00 PREC=0x00 TTL=242 ID=33191 PROTO=UDP SPT=30910 DPT=389 LEN=59 ]

如您所见，目标 IP 在记录的第一部分始终是我的服务器 IP，而源 IP 是第二部分。所有其他IP都不相同。

这持续了大约4个小时。在那段时间里，服务器的 CPU 负载非常低，甚至 SSH 连接都断开了。

ping 被 ufw 防火墙的前规则阻止。

这是DDos攻击吗？值得一提的是，几天前我们遇到了 DDos 攻击，而前一天我们尝试了 DDos 攻击，我们在 Cloudflare 仪表板中添加了防火墙规则来阻止该攻击。

有人可以解释如何识别日志中每条记录的括号 [] 中的第二部分吗？

猫 /etc/ufw/before.rules

#
# rules.before
#
# Rules that should be run before the ufw command line added rules. Custom
# rules should be added to one of these chains:
#   ufw-before-input
#   ufw-before-output
#   ufw-before-forward
#

# Don't delete these required lines, otherwise there will be errors
*filter
:ufw-before-input - [0:0]
:ufw-before-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-not-local - [0:0]
# End required lines


# allow all on loopback
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-output -o lo -j ACCEPT

# quickly process packets for which we already have a connection
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# drop INVALID packets (logs these in loglevel medium and higher)
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP

# ok icmp codes for INPUT
-A ufw-before-input -p icmp --icmp-type destination-unreachable -j DROP
-A ufw-before-input -p icmp --icmp-type source-quench -j DROP
-A ufw-before-input -p icmp --icmp-type time-exceeded -j DROP
-A ufw-before-input -p icmp --icmp-type parameter-problem -j DROP
-A ufw-before-input -p icmp --icmp-type echo-request -j DROP

# ok icmp code for FORWARD
-A ufw-before-forward -p icmp --icmp-type destination-unreachable -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type source-quench -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type time-exceeded -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type parameter-problem -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type echo-request -j ACCEPT

# allow dhcp client to work
-A ufw-before-input -p udp --sport 67 --dport 68 -j ACCEPT

#
# ufw-not-local
#
-A ufw-before-input -j ufw-not-local

# if LOCAL, RETURN
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN

# if MULTICAST, RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN

# if BROADCAST, RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN

# all other non-local packets are dropped
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP

# allow MULTICAST mDNS for service discovery (be sure the MULTICAST line above
# is uncommented)
-A ufw-before-input -p udp -d 224.0.0.251 --dport 5353 -j ACCEPT

# allow MULTICAST UPnP for service discovery (be sure the MULTICAST line above
# is uncommented)
-A ufw-before-input -p udp -d 239.255.255.250 --dport 1900 -j ACCEPT

# don't delete the 'COMMIT' line or these rules won't be processed
COMMIT

UFW的规则。

ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
20/tcp                     ALLOW IN    Anywhere
21/tcp                     ALLOW IN    Anywhere
22/tcp                     ALLOW IN    Anywhere
25/tcp                     ALLOW IN    Anywhere
53/tcp                     ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
110/tcp                    ALLOW IN    Anywhere
143/tcp                    ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere
587/tcp                    ALLOW IN    Anywhere
993/tcp                    ALLOW IN    Anywhere
995/tcp                    ALLOW IN    Anywhere
3306/tcp                   ALLOW IN    Anywhere
8080/tcp                   ALLOW IN    Anywhere
8081/tcp                   ALLOW IN    Anywhere
10000/tcp                  ALLOW IN    Anywhere
53/udp                     ALLOW IN    Anywhere
3306/udp                   ALLOW IN    Anywhere
2408/tcp                   ALLOW IN    173.245.48.0/20
2408/tcp                   ALLOW IN    103.21.244.0/22
2408/tcp                   ALLOW IN    103.22.200.0/22
2408/tcp                   ALLOW IN    103.31.4.0/22
2408/tcp                   ALLOW IN    141.101.64.0/18
2408/tcp                   ALLOW IN    108.162.192.0/18
2408/tcp                   ALLOW IN    190.93.240.0/20
2408/tcp                   ALLOW IN    188.114.96.0/20
2408/tcp                   ALLOW IN    197.234.240.0/22
2408/tcp                   ALLOW IN    198.41.128.0/17
2408/tcp                   ALLOW IN    162.158.0.0/15
2408/tcp                   ALLOW IN    104.16.0.0/12
2408/tcp                   ALLOW IN    172.64.0.0/13
2408/tcp                   ALLOW IN    131.0.72.0/22
22/tcp (OpenSSH)           ALLOW IN    Anywhere
143/tcp (Dovecot IMAP)     ALLOW IN    Anywhere
993/tcp (Dovecot Secure IMAP) ALLOW IN    Anywhere
25/tcp (Postfix)           ALLOW IN    Anywhere
465/tcp (Postfix SMTPS)    ALLOW IN    Anywhere
587/tcp (Postfix Submission) ALLOW IN    Anywhere
20/tcp (v6)                ALLOW IN    Anywhere (v6)
21/tcp (v6)                ALLOW IN    Anywhere (v6)
22/tcp (v6)                ALLOW IN    Anywhere (v6)
25/tcp (v6)                ALLOW IN    Anywhere (v6)
53/tcp (v6)                ALLOW IN    Anywhere (v6)
80/tcp (v6)                ALLOW IN    Anywhere (v6)
110/tcp (v6)               ALLOW IN    Anywhere (v6)
143/tcp (v6)               ALLOW IN    Anywhere (v6)
443/tcp (v6)               ALLOW IN    Anywhere (v6)
587/tcp (v6)               ALLOW IN    Anywhere (v6)
993/tcp (v6)               ALLOW IN    Anywhere (v6)
995/tcp (v6)               ALLOW IN    Anywhere (v6)
3306/tcp (v6)              ALLOW IN    Anywhere (v6)
8080/tcp (v6)              ALLOW IN    Anywhere (v6)
8081/tcp (v6)              ALLOW IN    Anywhere (v6)
10000/tcp (v6)             ALLOW IN    Anywhere (v6)
53/udp (v6)                ALLOW IN    Anywhere (v6)
3306/udp (v6)              ALLOW IN    Anywhere (v6)
22/tcp (OpenSSH (v6))      ALLOW IN    Anywhere (v6)
143/tcp (Dovecot IMAP (v6)) ALLOW IN    Anywhere (v6)
993/tcp (Dovecot Secure IMAP (v6)) ALLOW IN    Anywhere (v6)
25/tcp (Postfix (v6))      ALLOW IN    Anywhere (v6)
465/tcp (Postfix SMTPS (v6)) ALLOW IN    Anywhere (v6)
587/tcp (Postfix Submission (v6)) ALLOW IN    Anywhere (v6)
2408/tcp                   ALLOW IN    2400:cb00::/32
2408/tcp                   ALLOW IN    2606:4700::/32
2408/tcp                   ALLOW IN    2803:f800::/32
2408/tcp                   ALLOW IN    2405:b500::/32
2408/tcp                   ALLOW IN    2405:8100::/32
2408/tcp                   ALLOW IN    2a06:98c0::/29
2408/tcp                   ALLOW IN    2c0f:f248::/32

更新：

还有一些奇怪的 SSH(?) 连接：

网络统计-nt | grep：22

tcp        0     69 MYSERVERIP:22        STRANGEIP_1:44930      FIN_WAIT1
tcp        0     68 MYSERVERIP:22        STRANGEIP_2:37007      ESTABLISHED
tcp        0      1 MYSERVERIP:22        STRANGEIP_3:40132      LAST_ACK
tcp        0     68 MYSERVERIP:22        STRANGEIP_4:50132   ESTABLISHED
tcp        0     68 MYSERVERIP:22        STRANGEIP_5:38939      ESTABLISHED
tcp        0      0 MYSERVERIP:22        MYIP:52118      ESTABLISHED
tcp        0     68 MYSERVERIP:22        STRANGEIP_6:43152     ESTABLISHED
tcp        0     68 MYSERVERIP:22        STRANGEIP_7:39321   ESTABLISHED
tcp        0     64 MYSERVERIP:22        MYIP:52001      ESTABLISHED
tcp        0     68 MYSERVERIP:22        STRANGEIP_8:39732      ESTABLISHED

网络统计-nputw | grep 'sshd'

tcp        0     68 MYSERVERIP:22        STRANGEIP_2:37007      ESTABLISHED 2525/sshd: unknown
tcp        0     68 MYSERVERIP:22        STRANGEIP_5:38939      ESTABLISHED 2558/sshd: unknown
tcp        0      0 MYSERVERIP:22        MYIP:52118      ESTABLISHED 15911/sshd: root@no
tcp        0     68 MYSERVERIP:22        STRANGEIP_7:39321   ESTABLISHED 2466/sshd: root [pr
tcp        0     64 MYSERVERIP:22        MYIP:52001      ESTABLISHED 15554/sshd: root@pt
tcp        0     68 MYSERVERIP:22        STRANGEIP_8:39732      ESTABLISHED 2596/sshd: unknown

以上是现在，但服务器似乎没有问题，并且 UFW 没有记录初始请求。

签入 /var/log/auth.log 后，上面的内容只是authentication failure. 我不知道他们出现在 netstat 中。

此致

ping icmp ddos syslog ufw
Martin Hope
djoproject
Asked: 2020-10-05 09:05:25 +0800 CST
  • 5

当向目标地址发送 ICMPv4 回显请求时224.0.0.1，接收请求的 Linux 主机会忽略它。使用的目标 MAC 地址是01:00:5e:00:00:01。

让这些 Linux 主机应答的唯一方法是将 Kernel 参数设置net.ipv4.icmp_echo_ignore_broadcasts为 value 0。这将指示内核响应多播和广播 ICMPv4 请求，并为广播安全威胁打开大门。

为什么这个参数会过滤多播流量？有什么攻击可以证明它是正当的吗？

使用 ICMPv6 和等价的目标地址ff02::1，Linux 主机不会过滤流量。是否存在将来也会被过滤的风险？ICMPv4 是否存在 ICMPv6 不存在的威胁？

Linux 主机：

  • Linux 发行版：Ubuntu 20.04.1 LTS Focal
  • Linux内核：5.4.0
icmp linux-kernel multicast ipv4
Martin Hope
JeremyCanfield
Asked: 2020-09-03 03:33:34 +0800 CST
  • -1

我有两台机器，server1 和 server2。在 server2 上，我停止了 firewalld。

[root@server2 ~]# systemctl stop firewalld

从 server1，nmap 返回Host is up.

[root@server1 ~]$ nmap -sn server2

Starting Nmap 6.40 ( http://nmap.org ) at 2020-09-02 11:27 CDT
Nmap scan report for server2 (10.17.45.13)
Host is up (0.00045s latency).
Nmap done: 1 IP address (1 host up) scanned in 0.01 seconds

我在 server2 上启用了 firewalld。

[root@server2 ~]# systemctl start firewalld

从 server1，nmap 返回Host seems down，因此server2上的 firewalld 导致 nmap 返回 Host 似乎已关闭。

[root@server1 ~]$ nmap -sn server2

Starting Nmap 6.40 ( http://nmap.org ) at 2020-09-02 11:29 CDT
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 0.01 seconds

在 server1 上，ping/echo/ICMP 有效。

[root@server1 ~]$ ping -c4 server2
PING server2 (10.17.45.13) 56(84) bytes of data.
64 bytes from server2 (10.17.45.13): icmp_seq=1 ttl=64 time=0.436 ms
64 bytes from server2 (10.17.45.13): icmp_seq=2 ttl=64 time=0.388 ms
64 bytes from server2 (10.17.45.13): icmp_seq=3 ttl=64 time=0.338 ms
64 bytes from server2 (10.17.45.13): icmp_seq=4 ttl=64 time=0.390 ms

--- server2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.338/0.388/0.436/0.034 ms

以下是server2 上public和区域的防火墙设置。dropicmp-block 为空意味着没有 ICMP 类型被阻止，并且 icmp-block-inversion 设置no为允许所有 IMCP 流量。

[root@server2 ~]# firewall-cmd --zone=public --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eno16777984
  sources:
  services: ssh dhcpv6-client
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

[root@server2 ~]# firewall-cmd --zone=drop --list-all
drop
  target: DROP
  icmp-block-inversion: no
  interfaces:
  sources:
  services:
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

/var/log/firewalld当 nmap 返回时没有记录任何内容Host seems down。

ping icmp firewalld nmap
Martin Hope
J. Doe
Asked: 2020-02-05 11:53:19 +0800 CST
  • 1

当我从对称 nat 下的网络发送 tcp 或 udp 数据包时，我希望端口与我的计算机选择的端口不同，所以它是。但是当我发送一个低 ttl 的 udp 数据包，但它仍然设法离开 ISP 网络时，我收到一个错误 icmp 数据包，其中包含我最初作为有效负载发送的 udp 数据包，但端口由我生成系统 。

在这一点上，我怀疑 NAT 是否也没有掌握 ICMP 数据包的内容。因为我知道有必要更改真正重要的层的标头而不是有效负载。因此，在 ICMP 数据包的情况下，只有源 IP 地址，而不像我认为的那样，还有回显“子数据包”的 ip 和端口。

firewall router networking nat icmp
Martin Hope
THESorcerer
Asked: 2016-12-17 03:42:28 +0800 CST
  • 0

我有一个 Linux 路由器，它通过 pppoe 使用动态 IP 连接到互联网

我希望它不响应来自外部（互联网）的 ping（或任何其他类型的 icmp），但我希望来自内部（LAN）的 ping（以及所有 icmp，如 traceroute、tcptraceroute、mtr 等）从服务器到外部目标工作，我该怎么做？

firewall linux iptables icmp