Ubuntu 14.04 가상 머신의 커널 라우팅 문제

Ubuntu 14.04 가상 머신의 커널 라우팅 문제

일부 Linux VM(클라우드 기반, 여러 공급자, 주로 Ubuntu 14.04 및 16.04)에서 이상한 네트워크 동작이 발생하고 있습니다. 사이에 Strongswan 게이트웨이가 있는 두 개의 서로 다른 네트워크가 있습니다.

사이트 A: 네트워크 - 기본 라우터에 구성된 10.104.16.0/20 VPN 게이트웨이 및 라우팅(VM에는 구성이 필요하지 않음)

사이트 B: 네트워크 - 10.240.132.0/25 Strongswan Gateway - 10.240.132.15 사이트 A와 통신하기 위해 필요에 따라 각 가상 머신에 대한 경로를 구성합니다.

사이트 A 가상 머신과 통신해야 하는 사이트 B의 가상 머신 중 하나에 있는 커널 라우팅 테이블:

# route -vn
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.240.132.1    0.0.0.0         UG    0      0        0 eth0
10.104.16.0     10.240.132.15   255.255.240.0   UG    0      0        0 eth0
10.240.132.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0

이제 문제는 다음과 같습니다... 모든 것이 정상이면 VM은 사이트 A의 VM에 ping을 보내고 이는 Traceroute 명령의 출력입니다.

# traceroute 10.104.19.4
traceroute to 10.104.19.4 (10.104.19.4), 30 hops max, 60 byte packets
 1  10.240.132.15 (10.240.132.15)  0.248 ms  0.228 ms  0.220 ms
 2  * * *
 3  10.104.19.4 (10.104.19.4)  15.048 ms  15.042 ms  15.028 ms

그런 다음 갑자기 가상 머신이 사이트 A 리소스를 ping할 수 없으며 Traceroute 출력은 다음과 같습니다.

# traceroute 10.104.19.4
traceroute to 10.104.19.4 (10.104.19.4), 30 hops max, 60 byte packets
 1  10.104.19.4 (10.104.19.4)  0.552 ms  0.567 ms  0.616 ms
 2  * 10.104.19.4 (10.104.19.4)  0.659 ms  0.707 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *^C

완전히 무작위로 보입니다. 결국 이런 일이 발생하면 경로를 삭제한 다음 다시 추가하겠습니다.

# route del -net 10.104.16.0 gw 10.240.132.15 netmask 255.255.240.0
# route add -net 10.104.16.0 gw 10.240.132.15 netmask 255.255.240.0

물론, 이렇게 하면 문제가 일시적으로 해결되지만 오래 지속되지는 않습니다. 무엇이 잘못되고 있는지, 내가 뭘 잘못하고 있는지 아시나요?

감사합니다;)

답변1

알았어, 신경 쓰지 마... 정확히 5분마다 오전 9시, 오전 9시 5분, 오전 9시 10분에 연결이 끊어진다는 것을 깨달은 후... Strongswan 로그를 보고 Times 아래에 있을 것이라는 것을 알았습니다. 서비스를 다시 시작하려면: 지정된 시간(프로세스가 SIGKILL 명령을 수신함)

우리는 선장과 이야기를 나눴고 그는 말했습니다.

글쎄, Strongswan 서버에는 원격 IP를 ping하고 원격 IP가 발견되지 않으면 서비스를 다시 시작하는 cron 작업이 있을 수 있습니다.

물론. 그리고 해당 원격 IP는 오래 전에 사라졌고 이 문서화되지 않은 작업을 비활성화하거나 업데이트한 사람이 없었기 때문에 서비스는 처음부터 다시 시작되었습니다. Postgres 데이터베이스를 복사할 때 이 문제를 발견하기 전까지는 말이죠.

관련 정보