이동하는 노트북: 안정된 이름인가, 고정된 사무실 주소인가?

집에서 관리 콘솔을 열고 노트북을 이름으로 검색하면 사무실을 떠날 때 유효하지 않게 된 주소가 나오며, 본능적으로 사무실 주소를 VPN 어댑터에 옮겨 모든 것을 계속 작동하게 하려 합니다. 그러나 그 수정은 대개 다른 무언가를 망가뜨립니다. 장치를 찾는 것, 그 트래픽을 허용하는 것, 세션을 살려 두는 것은 서로 다른 세 가지 문제이기 때문입니다. 주소 설계를 고르기 전에 이것들을 분리하십시오.

세 가지 요구 사항을 분리하십시오

세 가지 중 실제로 무엇이 실패하는지 적으십시오. 사람이나 도구가 서비스를 찾지 못하거나, 출발지 주소가 목록에 없어서 서버가 요청을 거부하거나, 인터페이스가 바뀔 때 애플리케이션이 끊깁니다. 스프레드시트에서는 똑같아 보이지만 필요한 수정은 다릅니다.

로밍 불만의 대부분은 첫 번째 분류에 들어가 DNS에서 해결됩니다. 안정된 정체성에 이름을 붙이는 것은 저렴하고 첫 번째 경우를 덮습니다. 주소 보존은 비싸고, 정책을 어차피 다시 쓸 경우에만 두 번째에 도움이 됩니다.

이름을 안정된 것으로 만드십시오

호출자가 도달할 수 있는 어떤 주소로든 확인되는 이름을 노트북에 주십시오. 이 예에서 사무실 주소는 192.168.50.42, 원격 접속 풀은 10.90.0.42를 주며, laptop17.corp.example은 연결을 따라갑니다. 마지막 옥텟이 일치해야 한다는 요구는 없으며, 그 일치를 전제로 설계하면 이득 없이 일만 늘어납니다. 레코드는 호출자가 실제로 쓸 수 있는 주소를 가리켜야 하며, 노트북이 지금까지 가졌던 모든 인터페이스를 가리켜서는 안 됩니다.

dig +short laptop17.corp.example

리졸버는 응답을 캐시하므로 변경이 모든 사람에게 즉시 적용되지는 않습니다. 짧은 TTL이 도움이 되고, 애플리케이션의 재연결 로직이 더 도움이 됩니다.

출발지 허용 목록이 실제 제약일 때

출발지 허용 목록은 어떤 변환 이후에 보호된 서비스가 받는 주소를 봅니다. 그것은 흔히 노트북 자체가 아니라 게이트웨이나 NAT 주소이며, 그래서 DNS 레코드를 편집해도 거부된 요청은 절대 고쳐지지 않습니다. 실제로 도착하는 주소에 대해 정책을 갱신하거나, 목록을 인증된 정체성으로 바꾸십시오.

서버에서 승인된 요청 하나를 잡아 출발지 필드를 읽고, 그다음 원격 경로에서 반복하십시오. 두 주소가 다르면 정책에는 두 개의 항목이나 다른 메커니즘이 필요합니다. 두 주소를 정책 항목과 함께 기록해 다음 사람이 왜 두 개인지 볼 수 있게 하십시오. 같은 링크에서 이미 활성인 주소를 다시 사용하는 것은 자체 탐지 규칙을 가진 별도의 충돌 문제입니다.

연속성이 실제로 요구하는 것

연결 연속성은 가장 어려운 요구 사항이며 가장 자주 잘못 읽히는 요구 사항입니다. TCP 연결은 두 주소와 두 포트로 식별되므로, DNS가 무엇을 말하든 새 로컬 주소는 다른 연결입니다. 중요한 애플리케이션은 다시 연결해야 하며, 이는 네트워크 요령이 아니라 세션 계층이나 재시도하는 클라이언트를 뜻합니다. 이동 중에 세션을 관찰하면 끊김은 즉시 일어나며 점진적이지 않습니다.

ss -tnp state established '( dport = :443 )'

MAC 주소를 복제하는 것도 이것을 해결하지 못합니다. DHCP 임대 정체성은 명시적 클라이언트 식별자를 쓸 수 있고, 하나의 정체성을 공유하는 두 인터페이스는 여전히 조정된 경로가 필요합니다. 이동성을 애플리케이션과 할당의 설계로 다루고, 주소가 네트워크를 따라가는 동안 장치의 정체성을 안정적으로 유지하십시오.