OpenVPN을 TAP에서 TUN으로 옮기기: 작동하는 마이그레이션 순서

dev tap을 dev tun으로 바꾸는 것은 터널이 무엇을 나르는지를 바꿉니다, 이름만이 아니라. TAP 인터페이스는 Ethernet 프레임을 브리지에 넘기므로 클라이언트는 사무실 스위치에 꽂힌 것처럼 동작합니다. TUN 인터페이스는 IP 패킷을 나르므로 클라이언트에는 경로가, 반대편에는 돌아올 길이 필요합니다. 클라이언트, 주소 계획, LAN의 반환 경로가 모두 그 변화와 함께 움직여야 합니다.

마이그레이션은 터널이 붙은 네트워크 재설계이며, 아래 순서는 이를 되돌릴 수 있게 유지합니다.

무엇이 실제로 Ethernet에 의존하는지 조사하십시오

호스트가 아니라 애플리케이션을 나열하십시오. 각각이 라우팅된 TCP 또는 UDP 서비스, 브로드캐스트 탐색, 사무실 LAN의 DHCP, 비IP Ethernet 프로토콜, 또는 양쪽 끝이 같은 서브넷에 있다는 가정을 쓰는지 판단하십시오. 일반 IP 접근은 라우팅 설계에서 살아남습니다. 원시 Ethernet 프레임이 필요한 프로토콜은 그렇지 않으며, 어떤 라우팅도 그것을 작동시키지 못합니다. 탐색에 의존하는 애플리케이션은 전환 전에 결정된 대체 수단이 필요합니다, 전환 중이 아니라.

그 조사는 승인 목록이기도 합니다. 마이그레이션할 수 없는 각 항목은 문서화된 예외가 되거나, 그 워크로드만을 위해 작은 TAP 세그먼트를 살려 두는 이유가 됩니다.

주소와 반환 경로 계획을 세우십시오

LAN, 이전 브리지 범위, 또는 클라이언트가 이미 도달하는 어떤 네트워크와도 겹치지 않는 클라이언트 프리픽스를 고르십시오.dev tun, topology subnet 그리고 server 10.78.0.0 255.255.255.0, 그러나 이것은 조각이며 작동하는 프로필이 아닙니다. 그 주위에 승인된 TLS, ID, 전송, 접근 정책을 유지하고, 비어 있음을 확인한 프리픽스를 사용하십시오.

그다음 클라이언트가 도달해야 할 목적지와 반환 경로를 누가 제공하는지 적으십시오. 서버에는 전달 기능이 켜져 있고 허용된 전진 경로가 필요합니다. LAN 라우터에는 새 프리픽스로 돌아가는 경로가 필요하거나, 설계에 소스 변환과 그에 따르는 가시성 비용이 필요합니다. 클라이언트 구성으로 밀어 넣은 경로는 클라이언트를 구성합니다, LAN의 응답 경로를 구성하는 것이 아니라.

별도 수신기에서 시험하십시오

작동하는 유일한 진입점을 바꾸는 대신, 새 서비스를 옛 서비스 옆에 자체 포트와 자체 주소 범위로 세우십시오. 기존 등록 절차로 시험 프로필을 발급하여 아무도 마이그레이션 때문에 CA를 다시 만들지 않게 하십시오. 시험 경로만 활성화한 대표 클라이언트 하나를 연결한 뒤, 할당된 주소, 사설 DNS, 조사 목록의 애플리케이션, 차단된 채 남아야 할 경로를 비교하십시오.

재연결과 반환 트래픽 시험도 포함하십시오. 완료되는 핸드셰이크는 반대편이 응답할 수 있는지에 대해 아무것도 말해 주지 않습니다.

롤백과 함께 클라이언트를 그룹으로 옮기십시오

실패가 장애가 아니라 지원 작업이 될 만큼 작은 그룹으로 마이그레이션하십시오. 각 그룹의 실제 워크플로가 통과할 때까지 옛 서비스를 실행하고 문서화해 두고, 롤백은 재구축이 아니라 이전 프로필로 되돌리는 것으로 쓰십시오. 그룹이 이동할 때마다 새 프리픽스에 대한 주소 기반 방화벽 규칙, 모니터링, 서버가 시작하는 모든 접근을 갱신하십시오.

그룹은 아무도 언급하지 않은 애플리케이션을 발견할 자리를 주기도 하며, 옛 경로는 비교를 위해 아직 남아 있습니다.

승인 후에만 브리지를 폐기하십시오

TAP 장치 제거는 첫 단계가 아니라 마지막 단계입니다. 무엇이든 지우기 전에 브리지가 아직 서버의 관리 주소, 모니터링 경로, 또는 무관한 워크로드를 나르는지 확인하십시오. 시작 의존성, 브리지 멤버십, DHCP 예약을 소유자를 통해 그 순서대로 폐기하고, 무엇이 제거되었는지 기록하십시오.

마이그레이션은 라우팅된 접근 모델이 조사 목록에 대해 작동할 때 끝납니다, ip link 의 출력에서 TAP 인터페이스가 사라질 때가 아니라.