☰

브리지 라우팅 및 화성 패킷

tag-icon • tag-icon routing bridge lxc
브리지 라우팅 및 화성 패킷

라우팅하려고 하는데 이제 혼자서는 해결할 수 없는 문제에 직면했습니다.

                              eth0 
                                |
                                |
                                |
    ------------------------   br0   ------------------------ 
    |                    (192.168.100.1)                    |
    |                                                       |
    |                                                       |
    |                                                       |
lxc_vpn_eth0                                          lxc_test_eth0                                              
(192.168.100.120)                                     (192.168.100.130)
    |
    |
   tun0

lxc 컨테이너(테스트)에서 다른 lxc 컨테이너(vpn)로 일부 패킷(udp)을 보내고 거기에서 해당 컨테이너 내부에서 실행되는 openvpn을 통해 보내고 싶습니다. 지금까지는 작동하지만 어떻게 든 커널 태그에 의해 martian 및 fall로 응답이 제공됩니다. 오프 브리지 br0

패킷이 통과한 3개 "위치" 모두에서 tcpdump를 사용하여 테스트했으며 결과는 다음과 같습니다. (
VPN 컨테이너에서) #tcpdump -i eth0
21:25:12.043321 IP 192.168.100.1.55081 > XX.YY.UU.VV.6969: UDP, length 16
21:25:12.097040 IP XX.YY.UU.VV.6969 > 192.168.100.1.55081: UDP, length 16

보시다시피 저는 tun0에서 패킷을 스푸핑하고 있습니다.

따라서 테스트 컨테이너의 패킷이 VPN 컨테이너에 도착하고 tun0을 통해 나가며 응답을 얻지만 이 응답 패킷이 브리지에 배치되자마자 커널 로그에 다음이 표시됩니다.
kernel: [c0] IPv4: martian source 192.168.100.120 from XX.YY.UU.VV, on dev br0

그렇다면 응답 패킷이 삭제되지 않도록 라우팅을 어떻게 구성해야 합니까? IP 192.168.100.120의 컨테이너가 있는 브리지에 이미 있어야 하며 이를 기다려야 합니다.

도움을 주셔서 미리 감사드리며, 기꺼이 더 많은 정보를 제공해 드리겠습니다... (포스트를 잠재적으로 쓸모 없는 정보로 채우고 싶지 않기 때문에 모든 라우팅 테이블을 게시하고 싶지 않습니다.)

답변1

이런 질문을 해서 죄송합니다...

몇 시간 동안의 트래픽 스니핑, 패킷 추적 및 많은 시행착오 끝에 나는 br0에서 패킷을 스푸핑하고 있다는 사실을 알아냈습니다. 아마도 컨테이너의 경우 하드웨어 스위치에 eth0에 있어야 하는 2대의 머신이 있기 때문에 이렇게 한 것 같습니다. 라우팅을 위해. 어쨌든, 이로 인해 패킷에 이상한 src 헤더가 생겼습니다...

트래픽을 가장하여이더넷 0대신에br0, 문제를 해결할 수 있었어요

관련 정보