IPv6는 공용을 서브넷으로 라우팅합니다.

IPv6는 공용을 서브넷으로 라우팅합니다.

공급자에서 클라이언트로의 Linux/Debian IPV6 라우팅이 작동하지 않습니다.
IPV4 NAT/라우팅은 iptables안정적으로 작동 dnsmasq하지만 IPv6에서 전달이 활성화된 경우에도 작동하도록 할 수 없습니다.
RADVD가 새 네트워크를 출시하지만 공용 IPv6 주소에 액세스할 수 없습니다.

단순화된 도면

                                        SW
                                         |    +---------+
                                         +--->| client  |
             PUBLIC              PRIVATE |    +---------+
                                         |
    ~/-(PR)-+       +---(ER)---+         | C0 +--(CL)---+
     public |P0  E0 | extender | E1      +--->| client  |
     vendor |<----->|  router  |<------->|    +---------+
            |       +----------+         |
 ~/---------+                            |    +---------+
                                         +--->| client  |
                                         |    +---------+

 Where:
    PR ISP Public router
       P0 Public network interface
    ER extender router Debian based, trying to configure
       E0 Public network interface
       E1 Private network interface
    CL Test Client
       C0 Private network interface

radvdumpER(주소 편집)을 사용하여 공개 경로 표시

    ...
    route 2600:..:5b10::/60
    {
            AdvRoutePreference high;
            AdvRouteLifetime 1209600;
    }; # End of route definition

ER에서는 radvdE1(2600:..:5b11)에 새 /64 네트워크를 게시하고
CL은 게시된 네트워크를 수신하여 2600:..:5b11 네트워크의 전역 주소로 자체 구성합니다.
ER은 ping6을 수행하고 ipv6.google.com, P0, E0, E1 및 C0에 연결할 수 있습니다.
CL은 ping6을 수행하고 E0 및 E1에 연결할 수 있지만.. P0(공개 주소도 아님)

ER->E1 에 tcpdumpER의 주기적인 라우터 광고를 표시합니다 .
CL에서 공개 주소를 ping하면 ER-E1에서 캡처되는 내용은 다음과 같습니다.

fe80::..:d477 is ER-E1
fe80::..:dff6 and 2600:..:5b11:..:f48 are CL-C0
fe80::..:f380 is PR-p0
2607:f8b0:4002:c0c::8a is ipv6.google.com

IP6 fe80::..:d477 > ff02::1: ICMP6, router advertisement, length 56
IP6 2600:..:5b11:..:f48 > 2607:f8b0:4002:c0c::8a: ICMP6, echo request, seq 1, length 64
IP6 fe80::..:dff6 > fe80::..:d477: ICMP6, neighbor solicitation, who has fe80::..:d477, length 32
IP6 fe80::..:d477 > fe80::..:dff6: ICMP6, neighbor advertisement, tgt is fe80::..:d477, length 24
IP6 fe80::..:d477 > fe80::..:dff6: ICMP6, neighbor solicitation, who has fe80::..:dff6, length 32
IP6 fe80::..:dff6 > fe80::..:d477: ICMP6, neighbor advertisement, tgt is fe80::..:dff6, length 24
IP6 fe80::..:d477 > ff02::1: ICMP6, router advertisement, length 56

CL에 대한 Ping이 메시지 없이 중단됩니다(시간 초과까지).

ER->E0 tcpdump(단순화):

IP6 2600:..:5b11:..:f48 > 2607:f8b0:4002:c0c::8a: ICMP6, echo request, seq 1, length 64
IP6 fe80::..:c446 > fe80::19d7:1db3:c381:23a: ICMP6, neighbor advertisement, tgt is fe80::..:c446, length 24
IP6 fe80::..:c446 > fe80::..:f380: ICMP6, neighbor solicitation, who has fe80::..:f380, length 32
IP6 fe80::..:f380 > fe80::..:c446: ICMP6, neighbor advertisement, tgt is fe80::..:f380, length 24
IP6 fe80::..:f380 > fe80::..:c446: ICMP6, neighbor solicitation, who has fe80::..:c446, length 32
IP6 fe80::..:c446 > fe80::..:f380: ICMP6, neighbor advertisement, tgt is fe80::..:c446, length 24

ER 라우팅 테이블(eth0=E0 eth1=E1)

2600:..:5b10::13 dev eth0 proto kernel metric 256  pref medium
2600:..:5b10::/64 dev eth0 proto kernel metric 256  expires 1209445sec pref medium
2600:..:5b10::/64 dev eth0 proto kernel metric 303  mtu 1500 pref medium
2600:..:5b11::/64 dev eth1 proto kernel metric 256  pref medium
fe80::/64 dev eth0 proto kernel metric 256  pref medium
fe80::/64 dev eth1 proto kernel metric 256  pref medium
default via fe80::..:f380 dev eth0 metric 303  mtu 1500 pref medium
default via fe80::..:f380 dev eth0 proto ra metric 1024  expires 1645sec hoplimit 64 pref medium

이 시점에서는 방화벽이 포함되지 않으며 ip6tables도 포함되지 않습니다.

ER에서는 모든 기본값에 대해 전달=1 및 프록시_ndp=1을 설정했습니다.

답변1

보시다시피 ping echo 요청은 E1에 도착하고 E0에 발행되므로 ER에서는 모든 것이 정상입니다.

그러나 PR에 문제가 있습니다. 핑 에코 응답이 도착하면 대상 주소를 갖게 됩니다 2600:...:5b11:...:f48. 그러나 PR은 5b10/60P0 뒤에 있는 서브넷에 대해서만 알고 있으며 E0을 통해 연결할 수 있는 다른 서브넷이 있다는 것을 알지 못합니다 5b11/64. 그래서 나의추측하다(인터페이스 덤프에서 이를 확인해야 함) 2600:...:5b11:...:f48P0에서 이웃 요청을 수행하는 PR이지만 ER은 응답하지 않으므로(주소를 소유하지 않기 때문에) PR은 패킷을 삭제합니다.

이런 방식으로 서브넷을 사용하여 IPv6을 설정해 본 적이 없으므로 무엇을 권장해야 할지 잘 모르겠습니다. 내가 시도한 첫 번째 일은 E0에 광고를 5b11/64하고 이 추가 정보로 인해 P0이 패킷을 전달하는지 확인하는 것이었습니다.

편집하다

내가 찾은NDPPD, 이웃은 프로토콜 에이전트 악마를 발견합니다. PR이 이웃 요청을 보냈지만 응답을 받지 못한 경우 ER에서 ndppd를 사용하면 문제가 해결될 수 있습니다.

나는 아직 그것을 직접 사용하지 않았습니다.

관련 정보