왜 이렇게 작동하는지 이해가 안 되기 때문에 장치를 이렇게 남겨두는 것이 불안합니다.
우리는 기존 Cisco ASA를 대체하기 위해 새로운 Sonicwall을 설치했습니다.
ASA에서 동일한 IP를 사용하여 기본 설정을 수행했습니다. (여기서 IP를 구성하지만 동일한 서브넷을 사용함)
X0 LAN: 172.16.5.2/30
X1 WAN: 216.40.5.100/30
그런 다음 내부 서브넷 중 하나에 대한 경로를 추가합니다.
X0 LAN 포트의 게이트웨이 172.16.5.1에 대한 10.1.0.0/16(172.16.5.1은 10.1.0.0 네트워크로 가는 경로가 있는 MPLS 공급자 라우터입니다)
그래서 이것을 설정했습니다. 작동하지 않습니다. 10.1.0.0 네트워크는 Sonicwall을 ping할 수 없고 인터넷에 접속할 수 없으며 Sonicwall은 10.1.0.0 네트워크를 ping할 수 없습니다.
이제 테스트를 위해 Sonicwall의 X2 포트를 켜고 레이어 2 브리지 모드로 전환한 다음 X0 LAN 포트에 바인딩했습니다. X2에 아무 것도 연결하지 않고 브리지만 활성화했습니다. X0 LAN과 X1 WAN이 여전히 사용되는 유일한 포트입니다. 마술처럼 모든 것이 작동하기 시작합니다. 더 많은 내부 네트워크를 위한 추가 경로를 추가하고 필요한 방화벽/Nat 규칙을 설정했으며 모든 것이 100% 작동합니다.
포트 X2를 끄고 브리지를 제거하면 모든 것이 다운됩니다.
겉보기에는 쓸모 없어 보이는 이 브리지를 추가하면 여기서 일이 작동하게 되는 이유가 무엇인지 완전히 알 수 없습니다. Cisco에는 브리징 설정이 없었습니다. 나는 많은 Sonicwall을 설치했지만 비슷한 상황은 겪어본 적이 없습니다.
다음은 스크린샷입니다.인터페이스.
답변1
방화벽 설정 방법에 대해서는 언급하지 않았습니다. 일반적으로 X0은 LAN이고 X1은 WAN입니다. 따라서 기본적으로 X1에서 X0으로의 트래픽은 차단됩니다. 그러나 나는 그것이 문제라고 생각하지 않습니다.
10.1.0.0/16에는 Sonicwall의 172.16.5.1에 대한 라우팅 가능한 인터페이스가 없습니다. 서브넷 마스크가 이를 방지합니다. 고정 경로를 추가하더라도 라우팅하려면 여전히 10.1.xx 서브넷에 라우팅 인터페이스가 필요합니다. 그렇지 않으면 SW가 패킷을 대신 X1 인터페이스로 전달할 것입니다.
브리징에 관한 한, 그것이 왜 작동하는지 전혀 모르겠습니다. 브리징의 버그를 악용하는 것 같나요?
내 생각엔 이 대답이 틀릴 수도 있다. 저라면 지울게요..
답변2
레이어 2 브리징에 대한 SonicWALL 설명서에 따르면:
레이어 2 브리지 바이패스는 현재 SonicWALL NSA E7500에 구현된 물리적 X0-X1 인터페이스 바이패스 릴레이입니다. 이 기능을 "연결 실패"라고도 합니다. 즉, Dell SonicWALL 어플라이언스에 하드웨어 또는 소프트웨어 오류가 발생할 경우 LAN-WAN 연결이 직접 연결로 되돌아갑니다. 바이패스 릴레이가 닫히면 X0과 X1 인터페이스 사이에서 네트워크 트래픽이 방해받지 않고 흐릅니다. 바이패스 릴레이가 열려 있으면 SonicWALL 어플라이언스에서 실행되는 SonicOS Enhanced에 의해 네트워크 트래픽이 처리됩니다.
따라서 인터페이스를 브리징하고 실패한 인터페이스(아무것도 연결되지 않은 X2)를 포함하면 SonicOS Enhanced OS 컨트롤을 우회하고 바로 연결되기 때문에 작동하는 것으로 보입니다.
즉, 이는 구성의 무언가가 일반 설정에서 연결을 차단하고 있는지 확인하기 위한 정교한 문제 해결 단계로 볼 수 있는 것 같습니다. 방화벽 규칙을 확인하시겠습니까?