SoftEther 캐스케이드: 두 가상 허브를 의도적으로 연결하기
캐스케이드는 구성된 아이덴티티 아래에서 로컬 허브를 원격 허브에 연결합니다. 출구 노드가 아니며, 그 허브들이 이미 브리지하는 모든 것을 전달합니다.
캐스케이드로 연결된 두 SoftEther 허브는 하나의 브로드캐스트 도메인을 공유하므로, 루프나 두 번째 DHCP 서버는 더 이상 로컬 실수가 아니라 공유 실수가 됩니다. 이것이 전체 위험 모델입니다. 캐스케이드 자체는 구성된 클라이언트 관계로, 로컬 가상 허브가 해당 서버가 승인한 아이덴티티로 원격 서버의 허브에 외부로 접속합니다. 더 큰 가상 네트워크를 위한 구성 요소이며, 인터넷 출구가 아닙니다.
1. 링크가 무엇을 날라야 하는지 결정
기능이 아니라 요구 사항에서 시작하십시오. 캐스케이드는 허브 사이에서 데이터 링크 계층 프레임을 옮기며, 두 사이트가 하나의 이더넷 세그먼트처럼 보여야 할 때 필요한 것이 바로 이것입니다. 필요가 몇 개의 서브넷에 대한 라우팅된 접근뿐이라면 라우팅된 경로가 더 단순하고 더 눈에 띄는 방식으로 실패합니다. 캐스케이드를 선택하면 공유 브로드캐스트, 공유 검색, 하나의 루프 토폴로지에 묶입니다.
서버를 건드리기 전에 요구 사항을 한 줄로 쓰십시오. 어떤 시스템이 같은 회선에 있어야 보여야 하고, 어떤 시스템이 경로만 필요한지. 「경로」라고 답하는 모든 것은 캐스케이드 밖에 두며, 이 한 문장이 중복 주소 서비스로 끝나는 대부분의 설계를 막습니다.
2. 승인하는 아이덴티티의 범위 정하기
서버를 관리하는 자격 증명과 캐스케이드가 연결에 사용하는 아이덴티티는 서로 다른 비밀이며, 둘을 섞는 것은 긴 꼬리를 가진 흔한 지름길입니다. 원격 허브에는 이 캐스케이드의 연결을 허용하는 사용자 또는 정책 항목이 필요합니다. 그 항목이 승인이며, 로그인 성공은 원격 허브 뒤에 무엇이 있는지에 대해 아무것도 말해 주지 않습니다.
어느 허브가 시작하고, 어느 원격 허브에 참여하며, 원격 아이덴티티가 무엇에 도달할 수 있는지 기록한 뒤, 약속하기 전에 두 아키텍처를 비교하십시오.
| Requirement | Routed path | Cascaded segment |
|---|---|---|
| Broadcast domain | Separate on each side | Shared across the link |
| Address service | One DHCP server per side | Must not run two on one domain |
| Loop risk | Route loops only | Layer-two loops if segments overlap |
양쪽 끝의 자격 증명과 복구 지침을 최신으로 유지하십시오. 원격 허브에서 암호를 바꾸거나 정책을 편집하면 로컬 사용자를 건드리지 않고 캐스케이드가 끊기며, 장애는 보통 살아 있지만 비어 있는 링크로 나타납니다.
3. 허브가 이미 무엇을 나르는지 점검
허브가 고립되어 있는 경우는 드뭅니다. 이미 물리 어댑터로 브리지하거나, 가상 라우터를 통해 라우팅하거나, 다른 곳으로 캐스케이드하고 있을 수 있으며, 그 연결 각각이 새 관계로 옮겨집니다. 「우리는 그저 두 허브를 연결했을 뿐」이 「왜 이 두 사이트가 이제 하나의 세그먼트인가」로 자주 바뀌는 이유입니다.
같은 물리 세그먼트로 브리지된 뒤 서로 캐스케이드된 두 허브는 루프를 만듭니다. 스패닝 트리를 추가하거나 만들지 마십시오. 같은 시험이 다른 캐스케이드로 이미 목표에 도달하는 허브에도 적용되며, 두 번째 링크는 용량을 더하지 않고 경로를 더합니다.
경로 하나가 없기 때문에 링크를 추가하지 말고 경로를 고치십시오. 먼저 종이에 토폴로지를 그리되, 다이어그램은 두 분이면 되고 모든 브리지와 캐스케이드를 포함하면 대부분의 루프를 생기기 전에 잡아냅니다.
4. 참여 전에 주소 지정 정리
결합된 세그먼트는 중복 서브넷을 가져오고, 중복 DHCP 서버가 전형적인 증상입니다. 클라이언트는 먼저 응답하는 서버에서 임대를 받으므로 동작이 무작위로 보이고 재부팅 사이에 옮겨 다닙니다. 어느 쪽이 주소 할당을 소유하는지 미리 정하고, 먼 세그먼트에는 로컬과 겹치지 않는 범위를 주며, 캐스케이드가 온라인되기 전에 첫 불만이 있은 뒤가 아니라 다른 DHCP 서비스를 끄십시오.
DNS는 별개의 질문이며, 캐스케이드는 프레임을 나르지만 리졸버를 구성하지 않습니다. 로컬 쪽에서 확인되는 이름이 링크 건너편에서는 확인되지 않을 수 있습니다. 작동하는 ping은 둘 중 하나만 증명하므로, 조회는 IP 경로와 분리해 시험하십시오.
5. 실제 리소스로 증명
의도한 원격 세그먼트에서 허용된 서비스를 골라 응답이 캐스케이드를 통해 돌아오는지 확인하십시오. 그런 다음 이름 확인에 대해 반복하십시오. 대상이 브로드캐스트 검색에 의존한다면 단일 회선보다 브리지된 링크에서 다른 동작을 예상하고, 결함으로 기록하는 대신 계획에 넣으십시오.
마지막으로, 어느 허브가 어디로 캐스케이드하는지, 어느 아이덴티티가 승인하는지, 어느 세그먼트가 브리지되어 있는지, 각각에서 누가 주소 할당을 소유하는지 적어 두십시오. 그 메모가 다음 사람이 존재를 몰랐던 세그먼트를 내리지 않고 정책을 바꿀 수 있게 합니다.