시뮬레이션을 위해 서버의 네트워크 동작을 수정하려고 합니다.외부/WAN 연결 동작(무엇을 의미 하던지).
완료되면 tc qdisc add dev lo root netem delay 100ms(그리고?) 에서 발생하는 모든 트래픽에 100ms 지연을 성공적으로 추가할 수 있습니다 127.0.0.1. 예를 들어 ping 127.0.0.1응답 시간은 200ms입니다.
그러나 이는 다른 인터페이스에 대한 트래픽에도 영향을 미칩니다. 예를 들어 eth1서버에 현재 IP 주소에 대한 인터페이스가 있습니다 . 이렇게 하면 100ms 지연이 발생합니다(결과적으로 200ms 응답 시간이 발생함).192.168.0.1Aping 192.168.0.1
나는 이 행동에 혼란스러워요. 나는 lo그것과 아무 관련이 없다고 생각했지만 eth1그것은 사실이 아닌 것 같습니다.
나는 이것이 Linux 커널이 자동으로 192.168.0.1로컬 주소를 인식하고 eth1모든 트래픽을 원래 주소로 다시 라우팅한다는 것을 의미한다고 가정합니다 lo.
그렇다면 방법은 없을까장애를 입히다그런 행동?
배경:
시뮬레이션하고 싶다외부 네트워크이는 서버의 프로세스가 A서로 통신하려는 경우에도 마찬가지입니다(물론 지정된 로컬 주소 및 포트에서 TCP/IP를 통해). 본질적으로 지연을 추가하고 싶지만 eth1이는 이 질문을 넘어서는 것입니다(내다른 문제).
내 서버는 Ubuntu 18.04를 실행하고 있지만 그것은 중요하지 않다고 생각합니다.
답변1
아니요, 다른 인터페이스에는 영향을 미치지 않습니다. 그러나 관련된 라우팅은 loIP 주소가 할당된 인터페이스에 관계없이 서버에서 로컬로의 모든 액세스를 유지하고 (루프백) 인터페이스를 사용합니다 . 그래서 lo영향을 받았습니다 tc ... netem.
ip route get귀하의 경우에 이와 유사한 내용을 제공하는 다음 명령을 사용하여 이를 확인할 수 있습니다 .
$ ip route get 192.168.0.1
local 192.168.0.1 dev lo table local src 192.168.0.1 uid 1000
cache <local>
당신이 본대로루오인터페이스가 사용됩니다.
이 동작을 비활성화할 이유가 없습니다. 어떻게든 192.168.0.1로 패킷을 보내는 데 성공했다면, eth1추측해 보세요. 패킷을 보낸 인터페이스에서 패킷을 받지 못하므로 패킷이 손실됩니다. 수신한 트래픽을 송신기로 다시 보내도록 연결된 스위치 포트를 구성하는 것을 포함하여 전체 복잡한 설정을 더 상상할 수 있지만 eth1조만간 이로 인해 실험 목적이 무너지고 실험이 더 이상 예상대로 작동하지 않게 됩니다.
네트워크를 다룰 때 적절한 테스트를 위해서는 항상 로컬 테스트와 원격 테스트를 분리해야 합니다. 원격 시스템을 사용할 수 없는 경우 자체적인 독립적인 전체 네트워크 스택이 있는 다른 네트워크 네임스페이스를 사용하여 에뮬레이트할 수 있습니다. 다음은 예입니다(OP의 영향을 받지 않음 tc ... netem).
루트 사용자로서:
ip netns add remote
ip link add name vethtest up type veth peer netns remote name veth0
ip address add 192.0.2.1/24 dev vethtest
ip -n remote link set dev veth0 up
ip -n remote address add 192.0.2.2/24 dev veth0
ip netns exec remote ping 192.0.2.1
원래 인터페이스를 재사용하는 방법이 있지만 이를 위해서는 구성을 일부 중단해야 합니다.