지사 서브넷을 본사 SonicWall 인터넷 출구로 라우팅하기

지사 전화는 본사를 통해 나가야 하지만 지사 노트북은 계속 로컬 WAN을 사용하며, 라우팅 정책만으로는 이를 제공하지 못합니다. 지사 라우트가 터널을 선택할 수는 있지만 터널 정책이 트래픽을 수락해야 하고, 본사가 이를 전달하고 변환해야 하며, 응답은 같은 경로로 돌아와야 합니다. 이 세 가지 중 하나라도 빠지면 증상은 터널이 켜져 있는 동안에만 인터넷을 잃는 일부 클라이언트입니다.

선택기부터 시작하고 라우트부터 시작하지 마십시오

라우팅 정책은 소스를 기준으로 일치하므로 소스가 무엇보다 먼저 안정적이어야 합니다. 선택한 장치를 관리자가 유지하는 주소 그룹에 두거나, 더 좋게는 구성원 자격이 장치 역할을 따르는 전용 세그먼트에 두십시오. 일반 DHCP 변동이 일치하는 주소를 다른 머신으로 옮길 수 있으면 정책은 조용히 잘못된 클라이언트를 선택하며, 첫 보고는 보통 느린 브라우징에 관한 것이지만 실제로는 우회 경로입니다.

그룹 이름은 층이나 부서가 아니라 그것이 지원하는 정책을 따서 붙이십시오. 라우팅 규칙이 둘보다 오래 살아남으므로 어떤 장치가 들어 있는지, 누가 하나를 추가할 수 있는지 기록하십시오.

지사 정책을 추가하고 그 순서를 지키십시오

지사 SonicWall에서 라우트 정책은 소스 그룹을 선택하고 의도한 목적지를 지정하며 터널 인터페이스를 게이트웨이로 설정하며, 이는 지원되는 터널 인터페이스 설계의 목적입니다. 첫 일치가 이기고 터널로 밀어 넣은 사설 프리픽스는 본사에 도착해도 버려질 뿐이므로, 로컬 및 사설 목적지 규칙은 광범위한 인터넷 규칙 위에 두십시오. 방화벽 자체의 VPN 피어로 가는 라우트도 유지해야 하며, 그렇지 않으면 터널 전송이 의존하는 정책을 따르게 됩니다. 이 중 어느 것도 기존의 모든 정책 기반 터널을 변환하도록 강요하지 않으며, 터널 인터페이스는 여러 지원 선택지 중 하나입니다.

순서는 실수로 바뀌는 부분입니다. 예외를 추가하는 사람은 이를 광범위한 규칙 위에 삽입해야 하고, 광범위한 규칙을 편집하는 사람은 저장 한 번으로 전체 설계를 뒤집을 수 있습니다. 인터페이스 이름 지정과 정책 표시가 릴리스 간에 실제로 달라지므로, 의도한 순서를 정책 옆에 적고 펌웨어 업데이트 후 다시 확인하십시오.

본사에서 경로를 완성하십시오

본사의 터널 정책은 이제 지사 라우트가 선택하는 트래픽을 수락해야 합니다. 본사의 사설 LAN으로 범위가 제한된 사무실 간 선택기는 임의의 공용 목적지를 운반할 권한이 아니므로, 정책에는 지사 소스와 실제로 의도하는 목적지 범위가 필요합니다. 그런 다음 본사는 들어오는 트래픽을 자체 액세스 규칙에 따라 인터넷 업링크로 전달하며, SonicWall의 중앙 출구 예시에는 중앙 WAN에서 원격 네트워크의 소스 변환이 포함됩니다. 이 변환이 없으면 원격 측은 사설 지사 주소를 보고 그곳으로 돌아갈 라우트가 없습니다.

응답은 계약의 나머지 절반입니다. 응답은 터널을 통해 또는 이를 위해 생성된 상태 저장 변환을 통해 돌아와야 하며, 사설 사이트 트래픽은 공용 이그레스와 다른 NAT 처리가 필요할 수 있습니다. 모든 내부 소스를 숨기는 하나의 광범위한 변환 규칙은 이후의 로깅과 문제 해결을 훨씬 읽기 어렵게 만들므로, 이러한 규칙을 구분 가능하게 유지하십시오.

터널이 끊길 때 그룹이 무엇을 할지 결정하십시오

중앙 출구가 선호가 아니라 요구 사항이라면, 사용자가 온라인 상태로 남아 있더라도 로컬 WAN으로 폴백하는 것은 규정 준수 실패입니다. SonicOS는 선택된 트래픽이 의도하지 않은 대체 경로를 택하지 못하도록 하는 지원 방법으로 터널 인터페이스를 드롭하는 라우트를 문서화합니다.

해당 라우트의 범위와 우선순위를 설치된 릴리스에 맞추고, 레이블을 믿는 대신 터널을 내려 테스트하십시오. 절대 로컬로 나가서는 안 되는 그룹은 닫힌 상태로 실패해야 하며, 가용성이 더 중요한 그룹은 합법적으로 폴백할 수 있으며, 둘 다 결정이므로 어느 것도 기본값으로 일어나서는 안 됩니다.

세 클라이언트에서 확인한 뒤 깔끔하게 롤백하십시오

중앙 게이트웨이로의 핑은 선택된 클라이언트가 아니라 방화벽에서 시작되므로 잘못된 것을 테스트합니다. 대신 장치에서 테스트하되, 선택된 장치, 로컬에 남아 있어야 하는 일반 장치, 로컬 서비스에 의존하는 장치 등 셋을 테스트하십시오.

ip -4 route get 203.0.113.10
curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://example.com
traceroute -n -m 6 203.0.113.10

공용 요청이 실제로 어디에서 나왔는지 비교하십시오. 선택된 클라이언트는 본사의 출구를 통해 인터넷에 도달해야 하고, 일반 클라이언트는 원격 측에서 지사 자체 주소를 계속 제시해야 하며, 203.0.113.10은 관심 있는 목적지의 대체물로 사용되는 문서용 주소입니다. 지사 리졸버에 질의하는 클라이언트는 소스가 다른 라우터 발 조회를 생성해 결과적으로 다른 라우트를 만들 수 있으므로, 같은 단계에 DNS를 포함하십시오.

롤백은 저장된 정책 순서와 주소 그룹입니다. 이전 순서를 복원하고, 정책에서 그룹을 제거하고, 두 장치 클래스를 다시 테스트하십시오. 다음 엔지니어가 누군가 편집하기 전에 어느 규칙이 광범위했는지 알아야 하므로, 내보낸 구성을 변경 기록과 함께 보관하십시오.