IPv6 경로를 자동 구성하는 방법


0

LAN 뒤에있는 시스템에 IPv6 연결을 제공하는 간단한 라우터를 구성했습니다. 라우터에는 2 개의 네트워크 인터페이스 (eth0, eth1)가 있고 머신에는 1 (eth0)이 있습니다.

라우터의 eth0은 로컬 네트워크에만 액세스하고 eth1은 인터넷에 액세스합니다. 모든 커널 매개 변수를 구성했는데 정상적으로 작동합니다.

라우터의 IP는 라우터에 fd00::1dhcpd를 설치하고 범위를 구성했습니다 fd00::100 - fd00::fffe.

이 네트워크에서 일부 컴퓨터를 시작하면 예를 들어 dhcpd에서 IP가 할당 fd00::fffa되지만 명백한 이유로 인터넷에 액세스 할 수 없습니다. 경로가 없습니다.

직접 경로를 추가 sudo route -6 add 2000::/3 gw fd00::1하면 컴퓨터가 재부팅 될 때까지 인터넷에 액세스하기 시작합니다.

모든 컴퓨터의 init 스크립트에이 경로를 직접 추가 할 수 있지만이 네트워크에서 컴퓨터를 시작할 때 다른 작업없이 IPv6 인터넷에 액세스 할 수 있도록 자동 구성해야합니다.

몇 가지 제안에 따라 라우터에 radvd도 설치 하고이 옵션을 삽입했습니다.

route 2000::/3 {};

가장 잘못되었을 수도 있지만 문서 나 예제를 찾을 수 없습니다. 작동하지 않습니다. dhcpd 시스템을 비활성화하면 임의의 임의의 IPv6 주소를 자동 구성하고 서로를 볼 수 없으면 라우터를 ping 할 수 없습니다.

LAN의 모든 컴퓨터에 대해 IPv6을 자동 구성하도록 LAN을 어떻게 설정합니까?

참고 : 각 컴퓨터에 공개 IPv6을 갖길 원하지 않아도 NAT는 괜찮습니다.


DHCPv4 / IPv4 통신 (필자가 알고있는 것은 아니지만 유사 할 수 있음)을 사용하면 라우팅 정보 ( "기본 게이트웨이"포함)가 더 선택적 일 수 있습니다. 지시 사항은 사용중인 소프트웨어에 따라 다를 수 있습니다. 라우터가 DHCPv6으로 주소를 할당하는 것 같습니다. 사용중인 라우터를 왜 공유하지 않습니까? 또한 사용중인 운영 체제 (아마도 sudo를 언급 했으므로 Unix-ish) 및 DHCP 클라이언트 (예 : ISC DHCP dhclient 또는 dhcpcd)는 구체적이고 적용 가능한 지침을 원할 경우 필요할 수 있습니다.
TOOGAM

그것은 라우터에 충분 해야하는 2 개의 인터페이스가있는 Linux 상자 일뿐입니다. :)
Petr

답변:


0

구성과 관련된 두 가지 문제를 즉시 발견했습니다. RFC 4193 주소는 전 세계적으로 라우팅 할 수 없습니다. 즉,이 주소는 외부 세계와 통신 할 수 없습니다.

NAT를 사용할 수는 있지만 NAT는 수많은 문제를 일으키는 것으로 알려져 있습니다. NAT는 IP 주소 부족을 일시적으로 해결하기위한 해결 방법입니다. IPv6은 그 문제를 해결합니다. 사람들이 NAT를 사용하여 해결하려고 시도한 다른 모든 문제에는 NAT와 관련이없는 더 나은 솔루션이 있습니다.

또한 RFC 4193의 사양에 따라 접두사가 명확하게 생성되지 않았습니다. 관련 견적 :

로컬로 할당 된 글로벌 ID는 의사 랜덤 알고리즘으로 생성해야합니다.

네트워크 구성에서이 두 가지 문제가 클라이언트와 외부 통신을 방해하는지 여부는 테스트를 통해서만 확인할 수 있습니다. 차선의 IPv6 구성을 감지하고 감지 된 경우 IPv6 사용을 완전히 피하는 소프트웨어가 있습니다. 일부 클라이언트 소프트웨어는 설정에서 IPv6 연결 사용을 거부 할 가능성이 높습니다.

그것은 클라이언트가 RFC 4193 주소를 사용하여 외부와 통신하도록하는 것은 불가능하지 않다고 말했다. 다음은 radvd.conf과거에 간략하게 사용한 파일입니다. 이 구성으로 일부 클라이언트는 할당 된 RFC 4193 주소를 사용하여 외부 통신을 시도했습니다.

interface wlan0 { 
        AdvSendAdvert on;
        MinRtrAdvInterval 3; 
        MaxRtrAdvInterval 10;
        prefix fdbd:5df9:dca3::/64 { 
                AdvOnLink on;
                AdvAutonomous on; 
                AdvRouterAddr on; 
        };
};

그러나이 구성은 모든 클라이언트에서 작동하지 않습니다. Android를 실행하는 클라이언트로 다시 테스트했습니다. 전화기에서 IPv6 주소를 구성했지만 외부 통신에 IPv6을 사용하려고 시도하지 않았습니다.

그런 다음 접두어를로 변경하여 2001:db8:dca3::/64전화기가 IPv6 패킷을 게이트웨이로 보내기 시작했습니다. 따라서 Android는 이러한 방식으로 RFC 4193 주소 사용을 거부하는 플랫폼의 한 예입니다.


나는 이것이 어떻게 유효 범위가 아닌지 알지 못합니다. 의사 무작위 생성기조차도 이론적으로 0으로 만 구성된 접두사를 생성 할 수 있습니다. 따라서 일부 소프트웨어가 그러한 주소가 유효하지 않다고 하드 코딩하면 해당 소프트웨어의 버그입니다. 또한 내가 말했듯이 기계는이 주소를 사용하여 인터넷에 연결할 수 있지만 경로를 추가해야 완벽하게 의미가 있습니다. 모든 기계가 자동으로 구성하도록이 경로를 어떻게 든 발표 할 수 있는지 궁금합니다.
Petr

@Petr 물론 난수 생성기가 해당 범위를 생성 할 수 있습니다. 그러나 일부 사람들은 RFC를 위반하고 유효한 접두사보다 훨씬 작은 하위 집합을 선택했습니다. 이 정보 fd00::/48를 통해 RFC 준수 구현의 무작위 기회보다 RFC 위반으로 인해 발생할 가능성이 훨씬 높다는 결론에 도달했습니다 . 그렇다고해서 클라이언트 소프트웨어가 임의의 접두사가 아닌 접두사를 감지하고 그로 인해 접두사를 사용하지 않는 것은 의미가 없습니다.
kasperd

@Petr 무작위가 아닌 접두사가 문제를 일으킬 수있는 이유는 충돌 위험이 훨씬 높기 때문입니다. 네트워크가 자체적으로 생성 된 임의의 접두사를 특정 목적으로 사용하는 여러 소프트웨어를 갖는 것이 완벽하게 유효합니다. 충돌 가능성이 거의 없습니다. 그러나 높은 확률로 충돌을 일으키기 위해서는 잘못 선택된 두 개의 접두사 만 필요합니다. 따라서 무작위로 보이지 않는 RFC 4193 접두사를 볼 때마다 충돌이 발생했을 가능성이 훨씬 높으므로 조사해야 할 문제의 원인 중 하나라는 것을 알고 있습니다.
kasperd

@Petr 클라이언트가 거부 할 수있는 것은 일반적으로 RFC 4193 접두사를 사용하는 것입니다. 그것들은 로컬 용도로만 사용되기 때문에 외부에서 작동한다는 보장은 없습니다. 이러한 상황에서 소프트웨어 공급 업체는 IPv6 주소 만 RFC 4193 주소 인 경우 IPv4 만 사용하는 것이 더 안정적 일 것으로 예상 할 수 있습니다. RFC 4193 주소를 거부하는 소프트웨어의 특정 예를 모르지만 Chromium이 동일한 이유로 Teredo 주소를 거부한다는 것을 알고 있습니다.
kasperd

@Petr 자동 구성 소프트웨어가 RFC 4193 주소를 허용하지만이 경우 기본 게이트웨이 자동 구성을 거부하는지 여부는 알 수 없습니다. RFC 4193 주소가 전 세계적으로 사용되어서는 안된다는 것을 감안할 때 개발자가 쉽게 떠 올릴 수 있다고 생각합니다. 개발자는 함의를 통해 신중하게 생각하지 않고 이러한 제한을 구현하는 경우가 있지만 OTOH 누군가가 적어도 한 가지 적절한 이유를 식별 한 후 그렇게 할 수도 있습니다. 누군가이 작업을 수행 한 경우 경로를 수동으로 추가하면 문제가 해결됩니다.
kasperd
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.