Linux 中使用 ip 命令进行静态 IP 配置会导致目标主机无法访问

Linux 中使用 ip 命令进行静态 IP 配置会导致目标主机无法访问

我是网络配置方面的新手。我想配置我的 Ubuntu 18.04 PC,以便它连接到设备。

我使用 USB 转以太网转换器,将以太网插孔连接到设备,将 USB 连接器连接到我的电脑。关于该设备,我得到的唯一信息是设备可通过 172.16.250.248 IP 地址访问。为此,我认为我需要将用于连接该设备的特定网络接口配置为静态 IP。

为此,我执行以下命令;

HOST_USB_IP=172.16.250.248
TARGET_USB_IP=172.16.250.201
INTERFACE_NAME=enxd03745fbecb2
sudo ip route del default via $HOST_USB_IP
sudo ifconfig $INTERFACE_NAME $TARGET_USB_IP netmask 255.255.0.0
sudo route add default gw $HOST_USB_IP

然而,当我尝试 ping 该设备时,出现以下信息:

PING 172.16.248.248 (172.16.250.248) 56(84) bytes of data.
From 172.16.248.201 icmp_seq=1 Destination Host Unreachable
From 172.16.248.201 icmp_seq=2 Destination Host Unreachable
From 172.16.248.201 icmp_seq=3 Destination Host Unreachable

我这里遗漏了什么?我还能尝试什么?任何指导都非常感谢。

编辑:ifconfig

enxd03745fbecb2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.16.250.201  netmask 255.255.0.0  broadcast 172.16.255.255
        inet6 fe80::d237:45ff:fefb:ecb2  prefixlen 64  scopeid 0x20<link>
        ether d0:37:45:fb:ec:b2  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 91  bytes 12018 (12.0 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1078  bytes 85079 (85.0 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1078  bytes 85079 (85.0 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

编辑:tcpdump

sudo tcpdump -v
tcpdump: listening on enxd03745fbecb2, link-type EN10MB (Ethernet), capture size 262144 bytes
08:18:17.290897 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has _gateway tell mozcelikors-monster, length 28
08:18:18.314986 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has _gateway tell mozcelikors-monster, length 28
08:18:19.338822 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has _gateway tell mozcelikors-monster, length 28
08:18:19.959793 IP (tos 0x0, ttl 255, id 22638, offset 0, flags [DF], proto UDP (17), length 203)
    mozcelikors-monster.mdns > 224.0.0.251.mdns: 0 [1a] [9q] PTR (QM)? _nfs._tcp.local. PTR (QM)? _ipp._tcp.local. PTR (QM)? _ipps._tcp.local. PTR (QM)? _ftp._tcp.local. PTR (QM)? _webdav._tcp.local. PTR (QM)? _webdavs._tcp.local. PTR (QM)? _sftp-ssh._tcp.local. PTR (QM)? _smb._tcp.local. PTR (QM)? _afpovertcp._tcp.local. (175)
08:18:20.362865 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has _gateway tell mozcelikors-monster, length 28
08:18:20.938829 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) mozcelikors-monster > ip6-allrouters: [icmp6 sum ok] ICMP6, router solicitation, length 16
      source link-address option (1), length 8 (1): d0:37:45:fb:ec:b2
08:18:21.036788 IP6 (flowlabel 0x2e07e, hlim 255, next-header UDP (17) payload length: 183) mozcelikors-monster.mdns > ff02::fb.mdns: [bad udp cksum 0x032d -> 0x63ac!] 0 [1a] [9q] PTR (QM)? _nfs._tcp.local. PTR (QM)? _ipp._tcp.local. PTR (QM)? _ipps._tcp.local. PTR (QM)? _ftp._tcp.local. PTR (QM)? _webdav._tcp.local. PTR (QM)? _webdavs._tcp.local. PTR (QM)? _sftp-ssh._tcp.local. PTR (QM)? _smb._tcp.local. PTR (QM)? _afpovertcp._tcp.local. (175)
08:18:37.770915 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has _gateway tell mozcelikors-monster, length 28
08:18:38.794818 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has _gateway tell mozcelikors-monster, length 28
08:18:39.819006 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has _gateway tell mozcelikors-monster, length 28
08:18:48.014902 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has _gateway tell mozcelikors-monster, length 28
08:18:49.034975 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has _gateway tell mozcelikors-monster, length 28
08:18:58.250915 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has _gateway tell mozcelikors-monster, length 28
08:19:07.467009 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has _gateway tell mozcelikors-monster, length 28
08:19:08.490891 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has _gateway tell mozcelikors-monster, length 28
08:19:09.514859 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has _gateway tell mozcelikors-monster, length 28
08:19:10.538961 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has _gateway tell mozcelikors-monster, length 28
08:19:11.562886 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has _gateway tell mozcelikors-monster, length 28
08:19:12.587390 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has _gateway tell mozcelikors-monster, length 28
08:19:13.611026 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has _gateway tell mozcelikors-monster, length 28
08:19:14.635375 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has _gateway tell mozcelikors-monster, length 28
08:19:15.659392 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has _gateway tell mozcelikors-monster, length 28
08:19:16.683480 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has _gateway tell mozcelikors-monster, length 28
08:19:17.706796 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has _gateway tell mozcelikors-monster, length 28
08:19:18.731178 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has _gateway tell mozcelikors-monster, length 28
08:19:19.754945 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has _gateway tell mozcelikors-monster, length 28
^C
26 packets captured
66 packets received by filter
40 packets dropped by kernel

编辑:tcpdump -vni enxd03745fbecb2

tcpdump: listening on enxd03745fbecb2, link-type EN10MB (Ethernet), capture size 262144 bytes
09:01:53.745827 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.16.250.248 tell 172.16.250.201, length 28
09:01:54.777111 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.16.250.248 tell 172.16.250.201, length 28
09:01:55.801017 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.16.250.248 tell 172.16.250.201, length 28
09:01:56.825115 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.16.250.248 tell 172.16.250.201, length 28
09:01:57.849117 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.16.250.248 tell 172.16.250.201, length 28
09:01:58.873092 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.16.250.248 tell 172.16.250.201, length 28
09:01:59.901121 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.16.250.248 tell 172.16.250.201, length 28
09:02:00.921096 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.16.250.248 tell 172.16.250.201, length 28
09:02:01.945080 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.16.250.248 tell 172.16.250.201, length 28

答案1

您运行的命令已有效地将 USB 加密狗配置为使用 172.16.250.201/16。

除非有其他如果您网络中的设备使用 172.16.250.248,则无法 ping 通任何设备。另一个设备不太可能,因为您似乎已通过 DHCP 获取该地址,从而确保不会发生地址冲突。此外,您已将据称不存在的地址设置为默认网关。

静态 IP 配置可能比较麻烦。您可能需要查找配置保留地址如果您不希望该设备的地址发生变化,请在 DHCP 服务器上为该设备指定一个。这样,默认网关和 DNS 分配仍然通过 DHCP 进行,无需手动操作。

相关内容