Я всегда думал, что шлюзы по умолчанию должны находиться в той же сети, что и сервер / клиент, пытающийся подключиться к Интернету. Однако сегодня я арендовал сервер у Hetzner, и сервер может подключаться к Интернету, хотя, как мне кажется, шлюз по умолчанию определенно не подключен к той же сети. Также сетевая маска, похоже, установлена на / 32.
root@test:~# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 138.201.187.120 netmask 255.255.255.255 broadcast 138.201.187.120
inet6 fe80::9400:ff:fe3b:eece prefixlen 64 scopeid 0x20<link>
inet6 2a01:4f8:c17:69b0::1 prefixlen 64 scopeid 0x0<global>
ether 96:00:00:3b:ee:ce txqueuelen 1000 (Ethernet)
RX packets 1166 bytes 638244 (638.2 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 653 bytes 92539 (92.5 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 112 bytes 8824 (8.8 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 112 bytes 8824 (8.8 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
root@test:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.31.1.1 0.0.0.0 UG 0 0 0 eth0
172.31.1.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
root@test:~# ip route
default via 172.31.1.1 dev eth0
172.31.1.1 dev eth0 scope link
root@test:~# ping ipv4.google.com
PING ipv4.l.google.com (172.217.21.238) 56(84) bytes of data.
64 bytes from fra16s13-in-f14.1e100.net (172.217.21.238): icmp_seq=1 ttl=54 time=4.83 ms
64 bytes from fra16s13-in-f14.1e100.net (172.217.21.238): icmp_seq=2 ttl=54 time=4.96 ms
64 bytes from fra16s13-in-f14.1e100.net (172.217.21.238): icmp_seq=3 ttl=54 time=5.01 ms
^C
--- ipv4.l.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 4.837/4.938/5.010/0.073 ms
root@test:~#
root@test:~# traceroute ipv4.google.com
traceroute to ipv4.google.com (216.58.207.78), 30 hops max, 60 byte packets
1 _gateway (172.31.1.1) 0.139 ms 0.091 ms 0.062 ms
2 12643.your-cloud.host (136.243.182.17) 0.320 ms 0.103 ms 0.075 ms
3 * * *
4 213-239-251-233.clients.your-server.de (213.239.251.233) 1.479 ms 213-239-251-237.clients.your-server.de (213.239.251.237) 0.722 ms 1.320 ms
5 core21.fsn1.hetzner.com (213.239.239.125) 0.417 ms 0.310 ms 0.278 ms
6 core4.fra.hetzner.com (213.239.245.18) 5.536 ms core4.fra.hetzner.com (213.239.245.14) 4.880 ms core0.fra.hetzner.com (213.239.252.33) 5.539 ms
7 72.14.218.94 (72.14.218.94) 5.094 ms 5.085 ms 5.113 ms
8 108.170.251.193 (108.170.251.193) 5.018 ms * 108.170.252.65 (108.170.252.65) 6.311 ms
9 108.170.235.246 (108.170.235.246) 7.428 ms 72.14.232.50 (72.14.232.50) 4.903 ms 72.14.234.227 (72.14.234.227) 4.951 ms
10 108.170.252.18 (108.170.252.18) 5.287 ms fra16s25-in-f14.1e100.net (216.58.207.78) 4.804 ms 108.170.251.145 (108.170.251.145) 5.646 ms
root@test:~#
Спасибо!
Точнее, шлюз должен быть на том же физический сеть в качестве компьютера, поскольку для его достижения (или на самом деле до любого компьютера в сети) требуется отправка пакетов ARP. Для этого в любой локальной сети требуется запись маршрута, определяющая компьютеры, подключенные к сети. Вот как будет выглядеть запись маршрута для более общей настройки сети:
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.193.254 0.0.0.0 UG 0 0 0 enp0s3
192.168.193.0 0.0.0.0 255.255.255.0 U 0 0 0 enp0s3
Как видно из второй строки, четко определено, как связаться с сервером шлюза. В Gateway столбец 0.0.0.0, что означает «не использовать шлюз для этих адресов», поэтому он определяет эти адреса как доступные напрямую. К сожалению, на выходе route -n не является интуитивным в этом смысле, но если вы используете ip route вместо этого вы увидите несколько более прямое представление:
default via 192.168.193.254 dev enp0s3
192.168.193.0/24 dev enp0s3 scope link
Вот, dev enp0s3 scope link означает "это ссылка на enp0s3 устройство, поэтому к нему можно получить прямой доступ ». Поскольку сам шлюз находится в этой подсети, компьютер знает, что к нему можно подключиться напрямую, поэтому при необходимости он знает, как направлять пакеты во внешний мир.
Если бы второй записи не было, шлюз был бы недоступен, даже если он находится в той же сети.
В вашем случае для этой цели служит вторая строка записи маршрута, хотя она предназначена для одного хоста, а не для сети:
172.31.1.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
или, как выход или ip route показывает:
172.31.1.1 dev eth0 scope link
Таким образом, решение состоит в том, что ваш компьютер и шлюз, вероятно, находятся в одной физической сети, и вашему серверу сообщается, как добраться до шлюза. С этого момента не имеет значения, используют ли они одну и ту же логическую сеть или нет.
Кроме того, не имеет значения, какова сетевая маска, если таблица маршрутизации содержит записи о компьютерах. Установка сетевой маски определяет только способ заполнения таблицы маршрутизации, но если у вас есть /24 запись подсети в таблице маршрутизации (как в моем первом примере) и установите маску сети на /32, сервер с радостью свяжется с каждым компьютером, указанным в таблице маршрутизации.
Это работает и в обратном направлении: если у вас есть /24 netmask, но не записи маршрутизации "on-link", тогда локальная сеть будет недоступна.