실천 계획을 시도했지만 도움이 되지 않았습니다.

실천 계획을 시도했지만 도움이 되지 않았습니다.

우리는 Hetzner 네트워킹 팀으로부터 이 서브넷에 속하는 가상 머신의 MAC 주소를 사용하지 말라고 요청하는 이메일을 받았습니다.

Xen 서버 호스트를 라우터로 구성합니다.이 가이드를 사용하세요.

자세한 내용을 문의한 후 Hetzner 지원팀은 일반적으로 하이퍼바이저의 네트워크 구성에서는 실제 NIC의 MAC 주소를 사용하여 시스템에서 나가는 패킷만 허용해야 한다고 대답했습니다. 그러나 문제가 보이지 않으면 IPtables를 사용하여 이러한 나가는 패킷을 차단해 볼 수 있습니다.

그래서 우리의 질문은 다음과 같습니다:

Hetzner 또는 기타 전용 서버 제공업체에 이러한 문제가 발생한 경우.
어떻게 해결하셨나요?

감사해요

실천 계획을 시도했지만 도움이 되지 않았습니다.

  1. 만들다별도의 라우터 VM
  2. sysctl.conf다음 명령을 사용하여 모든 가상 머신 및 호스트에서 IPv6을 끄십시오.
  3. 두 호스트 인터페이스 모두에서 매스커레이딩

    -A POSTROUTING -o xenbr0 -j MASQUERADE
    -A POSTROUTING -o eth0 -j MASQUERADE 
    
  4. 키우다추가 xenbr0:1 인터페이스

  5. 다음을 추가하세요./etc/sysctl.conf

    net.ipv4.conf.default.proxy_arp = 1
    

구성 세부정보

호스트/라우터 구성:

[root@xenserver-custom ~]# cat /etc/sysctl.conf

net.ipv4.ip_forward = 1  
net.ipv6.conf.all.forwarding=1

net.ipv4.conf.default.proxy_arp = 0  

net.ipv4.conf.all.send_redirects = 0  
net.ipv4.conf.default.send_redirects = 0  
net.ipv4.conf.lo.send_redirects = 0  
net.ipv4.conf.xenbr0.send_redirects = 0  

[root@xenserver-custom network-scripts]# ip addr add 85.91.107.177/28 dev xenbr0

[root@xenserver-custom ~]# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 0c:c4:7a:e7:dc:33  txqueuelen 1000  (Ethernet)
        RX packets 4704816217  bytes 6002063739181 (5.4 TiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6294828922  bytes 7643975899027 (6.9 TiB)
        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
        loop  txqueuelen 1  (Local Loopback)
        RX packets 518545683  bytes 6322784653872 (5.7 TiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 518545683  bytes 6322784653872 (5.7 TiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vifxxxx

.....................

xenbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 115.35.61.184  netmask 255.255.255.192  broadcast 115.35.61.191
        ether 0c:c4:7a:e7:dc:33  txqueuelen 1  (Ethernet)
        RX packets 3070611738  bytes 8670969429554 (7.8 TiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2680055664  bytes 9822630727363 (8.9 TiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

VM 게스트 구성

[root@r1213a network-scripts]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=yes
BOOTPROTO=static
IPADDR=85.91.107.184
PREFIX=28
GATEWAY=85.91.107.177
DNS1=213.133.98.98
DEFROUTE=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no

[root@r1213a network-scripts]# ifconfig
eth0      Link encap:Ethernet  HWaddr B6:8F:14:74:A6:B6
          inet addr:85.91.107.184  Bcast:85.91.107.191  Mask:255.255.255.240
          inet6 addr: fe80::b48f:14ff:fe74:a6b6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:27122939 errors:0 dropped:2 overruns:0 frame:0
          TX packets:2218911 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:5404322465 (5.0 GiB)  TX bytes:1061055301 (1011.9 MiB)


[root@r1213a network-scripts]# ip route
default via 85.91.107.177 dev eth0
85.91.107.176/28 dev eth0  proto kernel  scope link  src 85.91.107.184

[root@r1213a network-scripts]# traceroute google.com
traceroute to google.com (172.217.18.110), 30 hops max, 60 byte packets
 1  xenserver.localdomain (85.91.107.177)  0.081 ms  0.029 ms  0.039 ms
 2  static.129.61.69.159.clients.your-server.de (159.69.61.129)  0.390 ms  0.410 ms  0.370 ms
 3  core22.fsn1.hetzner.com (213.239.245.121)  0.393 ms  0.416 ms  0.424 ms
 4  core0.fra.hetzner.com (213.239.252.33)  5.207 ms  5.184 ms core0.fra.hetzner.com (213.239.252.29)  5.049 ms
 5  72.14.218.94 (72.14.218.94)  5.273 ms  5.249 ms 72.14.218.176 (72.14.218.176)  4.990 ms
 6  108.170.251.193 (108.170.251.193)  5.139 ms *  5.019 ms
 7  209.85.241.75 (209.85.241.75)  5.834 ms 216.239.40.58 (216.239.40.58)  5.092 ms 172.253.64.119 (172.253.64.119)  5.707 ms
 8  108.170.251.144 (108.170.251.144)  15.292 ms zrh04s05-in-f110.1e100.net (172.217.18.110)  4.952 ms  4.903 ms

답변1

호스트에서 나가는 패킷을 MASQUERADE로 만들면 이 문제가 해결될 수 있다고 생각합니다. iptables규칙을 따르면 이 문제를 해결할 수 있습니다.

iptables -t nat -A POSTROUTING -i eth0 -j MASQUERADE

이 규칙은 나가는 패킷을 해당 인터페이스의 패킷으로 다시 쓰도록 커널에 지시하는 eth0동시에 응답 트래픽을 보낸 사람에게 다시 반환할 수 있도록 역방향 매핑도 유지합니다.

그러나 VM 패킷이 전달이 아닌 브리징을 통해 전달되므로 규칙이 iptables해당 트래픽에 적용되지 않는 경우가 있습니다.이 링크그에 대한 간략한 요약입니다.

답변2

지원 했어해결책superuser.com에서. 이것은 나에게 효과적입니다

모든 크레딧은 Alexey Degtyarev에게 돌아갑니다.

해결책을 지적해주신 Hetzner 네트워크 팀에게도 감사드립니다만, 동일한 네트워크에서 두 번째 xenbr을 생성하고 VIF를 할당하려고 하다가 잘못된 방향으로 가게 되었습니다. 하지만 VM을 다시 시작한 후 VIF 번호가 다시 생성되므로 작동하지 않습니다.

Hetzner에는 전용 서버와 함께 사용할 수 있는 두 가지 유형의 추가 IP 주소, 즉 단일 IPv4 및 IPv4 서브넷이 있습니다. 각 IP에 대해 MAC 주소가 제공되며 새 VM 인스턴스의 네트워크 인터페이스에서 해당 MAC을 사용해야 합니다. 각 추가 서브넷에 대해 새 네트워크를 설정하고 해당 네트워크와 서버의 기본 네트워크(eth0과 연결됨) 간의 라우팅을 설정해야 합니다.

XenServer에서는 Linux 콘솔을 사용하여 이 작업을 수행할 수 있습니다.

xe network-create name-label="Additional network" name-description="46.xx.yy.zz/28"

팁 1: 가상 머신 중 하나를 Xen Center의 새 네트워크에 할당할 때까지 xapi0 브리지는 호스트에 표시되지 않았습니다. 다른 사람에게 이런 일이 발생하면 팁 하나만으로 시간을 절약할 수 있습니다.

그러면 XenServer의 새 브리지에 연결된 새 네트워크가 생성됩니다(기본값은 xapi0). 그런 다음 네트워크의 첫 번째 사용 가능한 IP 주소(넷마스크 기반)를 브리지에 할당합니다.

ip addr add 46.xx.yy.1/28 dev xapi0

이제 새 가상 머신을 추가하고 자동 생성된 MAC를 기본 네트워크 대신 새로 생성된 네트워크에 연결할 수 있습니다. 트래픽은 XenServer 내에서 전환되고 라우팅됩니다.

이 설정을 완료한 후 Hetzner 네트워킹 팀으로부터 스위치 포트에서만 MAC가 표시되도록 허용하라는 확인을 받았습니다.

팁 2: eth0에 더 이상 문제가 되는 트래픽이 없는지 호스트 측에서 확인할 수 있습니다.

tcpdump -i eth0 -en|egrep -i 'mac1|mac2'

이 모든 것은 xapi0에서 볼 수 있습니다

tcpdump -i xapi0 -en|egrep -i 'mac1|mac2'

여기서 mac1,mac2 - Hetzner가 금지한 것으로 보고된 MAC 주소입니다.

관련 정보