OpenVPN 재시작 후 IPv6 송신이 죽는다: 접두사 소유권을 확인하세요
터널이 다시 만들어지면 IPv6가 죽습니다. 무엇이든 재시작하기 전에 위임된 접두사, 클라이언트 주소, 반환 경로의 소유자가 누구인지 결정하세요.
IPv6는 OpenVPN이(가) 재시작되는 순간 트래픽 전달을 멈추고, IPv4는 계속 동작합니다. 터널 인터페이스가 다시 만들어졌고, 그 IPv6 상태를 관리하던 다른 무언가가 주소를 잃었거나 접두사를 도달 가능하게 만드는 경로를 잃었습니다. 서로 다른 세 가지 상태가 관련되어 있고, 각각 다른 소유자가 있습니다: 공급자가 위임한 접두사와 그 수명, VPN 클라이언트에 부여된 주소, 그리고 그 클라이언트 접두사를 서버로 되돌려 보내는 상위 경로입니다. 어떤 데몬을 건드리기 전에 각각의 소유자를 확인하세요. 잘못된 데몬을 재시작하면 문제가 하루 동안 숨고 다음 연결에서 돌아옵니다.
IPv6 상태의 세 조각, 세 소유자
| State | Typical owner | What breaks when it is wrong |
|---|---|---|
| Delegated prefix and lifetime | Upstream router or provider via DHCPv6-PD | Clients keep addresses that the upstream no longer routes |
| Client addresses inside the tunnel | OpenVPN server config or a delegation daemon | No global address, or an address outside the routed prefix |
| Return route for the client prefix | Upstream router, or the server's own routing table | Outbound works, replies never arrive |
터널 안의 전역 범위 주소만으로는 충분하지 않습니다. 상위 라우터는 여전히 그 접두사를 VPN 서버 쪽으로 되돌려 보내야 하며, 서버가 우연히 그 안의 주소를 갖고 있다고 해서 그렇게 해 주지는 않습니다.
그래서 공인 /64를 터널 풀에 복사하는 것도 위험합니다. 서버로 라우팅된 접두사는 상위 쪽이 on-link로 취급하는 접두사와 같지 않고, 이웃 탐색이 그 틈을 메워 주지 않습니다.
무엇이든 바꾸기 전에 서버 상태를 읽으세요
상태를 두 번, IPv6가 동작할 때와 재시작 후에 각각 캡처해 비교하면 되고, 읽기 전용 뷰로 충분하며 유지보수 시간대에도 비용이 들지 않습니다.
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwarding세 가지 구체적인 차이를 찾으세요: 사라진 경로, 사용 중단 또는 유효하지 않은 수명으로 넘어간 주소, 재위임 후 바뀌었는데 VPN 구성이 아직 예전 접두사를 광고하는 경우입니다.
주소는 사라졌는데 접두사가 그대로라면, 주소를 할당하던 데몬이 인터페이스 관리를 멈춘 것입니다. 접두사는 바뀌었는데 주소가 그대로라면, 클라이언트 구성이 낡은 것입니다. 두 고장은 브라우저에서는 똑같아 보이고 공통점이 없습니다.
dhcpcd가 터널을 관리해야 하는지 결정하세요
dhcpcd는 인터페이스를 검색하고 DHCPv6 접두사의 일부를 하위 인터페이스에 위임할 수 있으며, 구성에서 위임 대상을 명시적으로 지정할 수 있습니다. 명시적 대상이 없으면 문서화된 동작이 다른 인터페이스까지 관여할 수 있고, 그래서 터널이 아무도 계획하지 않은 주소를 갖게 됩니다.
두 조건이 있다면 터널의 정적 주소 지정을 OpenVPN에 맡기는 쪽으로 기울게 됩니다: 서버가 구성에서 고정 주소를 밀어내는 경우, 그리고 재연결 시 터널 이름이 바뀌는 경우입니다. 둘 다 해당하면 터널을 위임 데몬에서 의도적으로 제외하고, 이유를 적은 주석을 남기세요.
반대로 터널로의 위임이 의도된 것이라면, 접두사 변경 처리를 구현하세요. 위임된 접두사나 그 수명이 바뀔 때 반응하고, 서버가 광고하는 클라이언트 접두사를 갱신하고, 경로를 다시 추가한다는 뜻입니다. 그 설계에서 인터페이스를 제외하면 새 접두사를 아는 유일한 구성 요소가 사라집니다.
dhcpcd를 재시작하면 상태를 다시 만들기 때문에 뭔가 고쳐진 것처럼 보일 수 있지만, 생각하지 못한 인터페이스의 구성도 갱신하거나 철회합니다. 그 복구가 모든 VPN 재시작 후에 필요한 것은 아닙니다. 증거로 쓰던 카운터도 초기화됩니다. 실제로 바꾼 인터페이스만 대상으로 다시 로드하는 편이 낫습니다.
IPv6를 IPv4 NAT와 별도로 검증하세요
포워딩이 켜져 있고 상위 경로가 실제 클라이언트 접두사를 가리키는지 확인한 뒤, 새로 허용된 IPv6 연결을 만드세요. 클라이언트 자체의 IPv6 경로 테이블도 확인해야 합니다. 공인 주소를 보여 준다고 해서 그 요청이 터널을 썼다는 증거는 아닙니다.
IPv4 매스커레이딩은 다른 문제를 해결합니다: 사설 출발지의 반환 경로입니다. 회수된 IPv6 접두사에는 아무 효과가 없고, 추가해도 IPv6가 돌아오지 않습니다.
소유권 기록으로 마무리하세요: 어느 구성 요소가 접두사를 위임하고, 어느 것이 클라이언트 주소를 할당하고, 어느 것이 반환 경로를 들고 있으며, 재연결 시 각각에 무슨 일이 일어나는지입니다. 런북 네 줄이 다음 사람이 중요한 데몬을 찾기 위해 세 개를 재시작하는 수고를 덜어 줍니다.