Моя машина Ubuntu - 10.0.0.15, моя машина Windows - 10.0.0.10. Мой шлюз, который направляет интернет-трафик в локальную сеть, - 10.0.0.1.
Когда я пингую шлюз со своего компьютера с Windows, все в порядке - я получаю обратно все пакеты. То же самое верно, когда я пингую машину Ubuntu с машины Windows. Однако, когда я пингую шлюз с машины Ubuntu, теряется около 80% пакетов:
~# ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=16 ttl=64 time=0.460 ms
64 bytes from 10.0.0.1: icmp_seq=29 ttl=64 time=0.464 ms
64 bytes from 10.0.0.1: icmp_seq=30 ttl=64 time=0.477 ms
64 bytes from 10.0.0.1: icmp_seq=77 ttl=64 time=0.498 ms
64 bytes from 10.0.0.1: icmp_seq=91 ttl=64 time=0.452 ms
64 bytes from 10.0.0.1: icmp_seq=92 ttl=64 time=0.690 ms
64 bytes from 10.0.0.1: icmp_seq=94 ttl=64 time=0.539 ms
64 bytes from 10.0.0.1: icmp_seq=95 ttl=64 time=0.445 ms
64 bytes from 10.0.0.1: icmp_seq=96 ttl=64 time=0.541 ms
64 bytes from 10.0.0.1: icmp_seq=98 ttl=64 time=0.474 ms
64 bytes from 10.0.0.1: icmp_seq=99 ttl=64 time=1.40 ms
64 bytes from 10.0.0.1: icmp_seq=103 ttl=64 time=0.577 ms
64 bytes from 10.0.0.1: icmp_seq=106 ttl=64 time=0.535 ms
64 bytes from 10.0.0.1: icmp_seq=107 ttl=64 time=0.490 ms
64 bytes from 10.0.0.1: icmp_seq=109 ttl=64 time=0.477 ms
64 bytes from 10.0.0.1: icmp_seq=110 ttl=64 time=0.627 ms
64 bytes from 10.0.0.1: icmp_seq=111 ttl=64 time=0.563 ms
64 bytes from 10.0.0.1: icmp_seq=114 ttl=64 time=0.467 ms
64 bytes from 10.0.0.1: icmp_seq=115 ttl=64 time=0.535 ms
64 bytes from 10.0.0.1: icmp_seq=137 ttl=64 time=0.479 ms
64 bytes from 10.0.0.1: icmp_seq=138 ttl=64 time=0.455 ms
64 bytes from 10.0.0.1: icmp_seq=142 ttl=64 time=0.548 ms
64 bytes from 10.0.0.1: icmp_seq=143 ttl=64 time=0.448 ms
64 bytes from 10.0.0.1: icmp_seq=144 ttl=64 time=0.470 ms
64 bytes from 10.0.0.1: icmp_seq=147 ttl=64 time=0.545 ms
64 bytes from 10.0.0.1: icmp_seq=149 ttl=64 time=0.557 ms
64 bytes from 10.0.0.1: icmp_seq=152 ttl=64 time=0.547 ms
64 bytes from 10.0.0.1: icmp_seq=153 ttl=64 time=0.476 ms
64 bytes from 10.0.0.1: icmp_seq=179 ttl=64 time=0.472 ms
64 bytes from 10.0.0.1: icmp_seq=180 ttl=64 time=0.854 ms
64 bytes from 10.0.0.1: icmp_seq=188 ttl=64 time=0.494 ms
64 bytes from 10.0.0.1: icmp_seq=190 ttl=64 time=0.556 ms
64 bytes from 10.0.0.1: icmp_seq=192 ttl=64 time=0.499 ms
64 bytes from 10.0.0.1: icmp_seq=193 ttl=64 time=0.482 ms
^C
--- 10.0.0.1 ping statistics ---
194 packets transmitted, 34 received, 82% packet loss, time 197372ms
rtt min/avg/max/mdev = 0.445/0.546/1.404/0.171 ms
То же самое происходит, когда я пингую любой IP-адрес в Интернете (== через шлюз). Однако, если я пингую любую другую машину в локальной сети, все в порядке (например, машина с Windows).
Так было не всегда. Недавно я настроил туннель IPSec, так что это может быть причиной. Однако даже с остановленным туннелем IPSec я испытываю те же проблемы.
Я проверил маршрутизацию, и она работает не так, как я ожидал.
Traceroute на другой компьютер в локальной сети выглядит нормально:
~# traceroute 10.0.0.7
traceroute to 10.0.0.7 (10.0.0.7), 64 hops max
1 10.0.0.7 0.173ms 0.115ms 0.180ms
Traceroute до шлюза делает не хорошо выглядеть (пришлось CTRL+C - застрял слишком долго):
~# traceroute 10.0.0.1
traceroute to 10.0.0.1 (10.0.0.1), 64 hops max
^C
Таблица маршрутизации выглядит неплохо:
~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.0.1 0.0.0.0 UG 100 0 0 enp5s0
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 enp5s0
10.0.0.1 0.0.0.0 255.255.255.255 UH 100 0 0 enp5s0
РЕДАКТИРОВАТЬ: Я уже знаю, что проблема вызвана туннелем. Когда я отключаю службу (sudo systemctl disable strongswan) и перезагрузите компьютер, пинг работает нормально. Если я затем вручную запущу туннель (ipsec start) пинг не работает (работает описанным выше способом). Если я тогда остановлю туннель (ipsec stop) это все равно ничего не изменит. Мне нужно перезагрузить компьютер, чтобы это исправить.
Моя конфигурация IPSec:
# ipsec.conf - strongSwan IPsec configuration file
config setup
# strictcrlpolicy=yes
# uniqueids = no
conn my-tunnel
type=tunnel
keyexchange=ikev1
authby=secret
left=%defaultroute
leftid=Y.Y.Y.Y
leftsubnet=10.0.0.0/24
right=X.X.X.X
rightsubnet=192.168.0.0/24
ike=aes256-sha1-modp2048!
esp=aes256-sha1-modp2048!
keyingtries=0
ikelifetime=1h
lifetime=8h
dpddelay=30
dpdtimeout=120
dpdaction=restart
auto=start
Есть ли у вас какие-либо предложения, где я мог бы взглянуть и, возможно, решить проблему?
РЕДАКТИРОВАТЬ2: (по просьбе Кевина К. в комментариях)
Имейте в виду, что X.X.X.X - это удаленный публичный IP-адрес, который я заменил сам.
~# ip xfrm state
src 10.0.0.15 dst X.X.X.X
proto esp spi 0xc44dd838 reqid 1 mode tunnel
replay-window 0 flag af-unspec
mark 0x64/0xffffffff
auth-trunc hmac(sha1) 0x951ac2ff6fadcd180b86e91ddf850c96f9e09ec2 96
enc cbc(aes) 0x0b17feeeafb55e1693c1e1c3f8d59b3a1d2c5470e4fc7580b0887e0a8beb504d
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src X.X.X.X dst 10.0.0.15
proto esp spi 0xc364db19 reqid 1 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha1) 0x00b17673c57fac4957123718d046578689edb07a 96
enc cbc(aes) 0xedd573110a33a7ac100372fa605514703b0f9954b33a3780dd97ee8e8ac32fe5
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
~# ip xfrm policy
src 10.0.0.0/24 dst 192.168.0.0/24
dir out priority 376959
mark 0x64/0xffffffff
tmpl src 10.0.0.15 dst X.X.X.X
proto esp spi 0xc44dd838 reqid 1 mode tunnel
src 192.168.0.0/21 dst 10.0.0.0/24
dir fwd priority 376959
mark 0x64/0xffffffff
tmpl src X.X.X.X dst 10.0.0.15
proto esp reqid 1 mode tunnel
src 192.168.0.0/21 dst 10.0.0.0/24
dir in priority 376959
mark 0x64/0xffffffff
tmpl src X.X.X.X dst 10.0.0.15
proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0
src ::/0 dst ::/0
socket in priority 0
src ::/0 dst ::/0
socket out priority 0
src ::/0 dst ::/0
socket in priority 0
src ::/0 dst ::/0
socket out priority 0
Решил на время отпустить пинг. Похоже, я получаю ответ примерно на секунду, а затем он снова останавливается. В приведенном ниже примере я отправляю 10 пакетов в секунду (-i 0.1). Вы можете отличить последовательные пакеты, посмотрев на параметр icmp_seq.
root@phenom:~# ping 10.0.0.1 -i 0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=656 ttl=64 time=0.572 ms
64 bytes from 10.0.0.1: icmp_seq=657 ttl=64 time=0.501 ms
64 bytes from 10.0.0.1: icmp_seq=658 ttl=64 time=0.518 ms
64 bytes from 10.0.0.1: icmp_seq=659 ttl=64 time=0.464 ms
64 bytes from 10.0.0.1: icmp_seq=660 ttl=64 time=0.491 ms
64 bytes from 10.0.0.1: icmp_seq=661 ttl=64 time=0.561 ms
64 bytes from 10.0.0.1: icmp_seq=662 ttl=64 time=0.571 ms
64 bytes from 10.0.0.1: icmp_seq=663 ttl=64 time=0.545 ms
64 bytes from 10.0.0.1: icmp_seq=664 ttl=64 time=0.584 ms
64 bytes from 10.0.0.1: icmp_seq=665 ttl=64 time=0.549 ms
64 bytes from 10.0.0.1: icmp_seq=666 ttl=64 time=0.564 ms
64 bytes from 10.0.0.1: icmp_seq=667 ttl=64 time=0.539 ms
64 bytes from 10.0.0.1: icmp_seq=668 ttl=64 time=0.587 ms
64 bytes from 10.0.0.1: icmp_seq=669 ttl=64 time=0.531 ms
64 bytes from 10.0.0.1: icmp_seq=670 ttl=64 time=0.832 ms
64 bytes from 10.0.0.1: icmp_seq=671 ttl=64 time=0.903 ms
64 bytes from 10.0.0.1: icmp_seq=747 ttl=64 time=0.511 ms
64 bytes from 10.0.0.1: icmp_seq=748 ttl=64 time=0.483 ms
64 bytes from 10.0.0.1: icmp_seq=749 ttl=64 time=0.472 ms
64 bytes from 10.0.0.1: icmp_seq=914 ttl=64 time=0.553 ms
64 bytes from 10.0.0.1: icmp_seq=915 ttl=64 time=0.568 ms
64 bytes from 10.0.0.1: icmp_seq=916 ttl=64 time=0.553 ms
64 bytes from 10.0.0.1: icmp_seq=917 ttl=64 time=0.589 ms
64 bytes from 10.0.0.1: icmp_seq=918 ttl=64 time=0.556 ms
64 bytes from 10.0.0.1: icmp_seq=919 ttl=64 time=0.573 ms
64 bytes from 10.0.0.1: icmp_seq=920 ttl=64 time=0.574 ms
64 bytes from 10.0.0.1: icmp_seq=921 ttl=64 time=0.556 ms
64 bytes from 10.0.0.1: icmp_seq=922 ttl=64 time=0.551 ms
64 bytes from 10.0.0.1: icmp_seq=923 ttl=64 time=0.607 ms
64 bytes from 10.0.0.1: icmp_seq=934 ttl=64 time=0.848 ms
64 bytes from 10.0.0.1: icmp_seq=935 ttl=64 time=0.555 ms
64 bytes from 10.0.0.1: icmp_seq=936 ttl=64 time=1.00 ms
64 bytes from 10.0.0.1: icmp_seq=937 ttl=64 time=0.586 ms
64 bytes from 10.0.0.1: icmp_seq=938 ttl=64 time=0.566 ms
64 bytes from 10.0.0.1: icmp_seq=939 ttl=64 time=0.495 ms
64 bytes from 10.0.0.1: icmp_seq=940 ttl=64 time=0.551 ms
64 bytes from 10.0.0.1: icmp_seq=941 ttl=64 time=0.456 ms
64 bytes from 10.0.0.1: icmp_seq=953 ttl=64 time=0.453 ms
64 bytes from 10.0.0.1: icmp_seq=954 ttl=64 time=0.478 ms
64 bytes from 10.0.0.1: icmp_seq=955 ttl=64 time=0.567 ms
64 bytes from 10.0.0.1: icmp_seq=956 ttl=64 time=0.585 ms
64 bytes from 10.0.0.1: icmp_seq=957 ttl=64 time=0.488 ms
64 bytes from 10.0.0.1: icmp_seq=958 ttl=64 time=0.586 ms
64 bytes from 10.0.0.1: icmp_seq=959 ttl=64 time=0.486 ms
64 bytes from 10.0.0.1: icmp_seq=960 ttl=64 time=0.543 ms
64 bytes from 10.0.0.1: icmp_seq=961 ttl=64 time=0.442 ms
64 bytes from 10.0.0.1: icmp_seq=962 ttl=64 time=0.443 ms
64 bytes from 10.0.0.1: icmp_seq=963 ttl=64 time=0.528 ms
64 bytes from 10.0.0.1: icmp_seq=964 ttl=64 time=0.475 ms
64 bytes from 10.0.0.1: icmp_seq=965 ttl=64 time=0.474 ms
64 bytes from 10.0.0.1: icmp_seq=966 ttl=64 time=0.839 ms
64 bytes from 10.0.0.1: icmp_seq=967 ttl=64 time=0.461 ms
64 bytes from 10.0.0.1: icmp_seq=968 ttl=64 time=0.474 ms
64 bytes from 10.0.0.1: icmp_seq=969 ttl=64 time=0.474 ms
64 bytes from 10.0.0.1: icmp_seq=970 ttl=64 time=0.547 ms
64 bytes from 10.0.0.1: icmp_seq=971 ttl=64 time=0.837 ms
64 bytes from 10.0.0.1: icmp_seq=972 ttl=64 time=18.6 ms
^C
--- 10.0.0.1 ping statistics ---
1174 packets transmitted, 57 received, 95% packet loss, time 121969ms
rtt min/avg/max/mdev = 0.442/0.883/18.628/2.374 ms