두 개의 SSID, 두 개의 출구: 어느 정책이 어디서 이기는가

한 게이트웨이의 두 SSID는 두 네트워크처럼 보이지만 게이트웨이가 그렇게 다루기 전까지는 두 네트워크가 아닙니다. 액세스 포인트가 각 SSID를 자체 VLAN에 매핑하지 않으면 무선은 둘 다 같은 브리지로 넘깁니다. 그리고 인터페이스가 분리되어 있어도 트래픽은 게이트웨이가 그 인그레스에 적용하는 경로와 방화벽 정책을 따릅니다. SSID는 레이블이고, 정책은 여러분이 적어 두는 것입니다.

SSID는 정책이 아니다

라우터를 만지기 전에 두 네트워크의 이름을 정하고 의도한 출구를 적어 두십시오. 홈은 일반 WAN으로, 업무는 VPN 인터페이스로 가며 어느 쪽도 다른 쪽의 경로를 물려받지 않습니다. 두 SSID가 분할되지 않은 하나의 브리지에 놓이면 이름은 아무것도 만들어 내지 못한 것입니다. 그 평평한 브리지가 이 설계가 조용히 실패하는 가장 흔한 방식입니다.

액세스 포인트는 이들을 별도 인터페이스로 제시해야 하며, 태그하거나 따로 브리지해야 합니다. 이는 세부 사항이 아니라 전제 조건입니다. 첫 규칙 전에 매핑을 적어 두십시오.

인그레스 인터페이스로 분류하라

패킷이 게이트웨이로 들어오는 지점에서 분류하십시오. 정책 규칙의 인그레스 인터페이스 선택자는 소스 접두사와 별개이며, 이 트래픽이 업무에서 왔다고 말하는 정직한 방법입니다. 소스 주소만 일치시키면 업무 쪽 클라이언트가 홈 주소를 주장하고 홈의 경로를 택할 수 있습니다.

ip rule show

소스를 인그레스에 대해서도 검증하여 두 시험이 서로 모순되지 않고 일치하게 하십시오. 둘 중 하나만 확인하는 규칙은 절반의 정책입니다.

게이트웨이 자체의 터널을 배제하라

게이트웨이 자체의 외부 VPN 연결은 동작하는 언더레이 위에 유지하십시오. 전달되는 업무 클라이언트를 위해 쓴 규칙이 그들을 운반하는 터널을 재귀적으로 잡아서는 안 되는데, 부하가 걸릴 때만 나타나는 루프를 만드는 고전적인 방법이기 때문입니다. 로컬 출력 경로를 예외로 두거나 규칙을 전달 트래픽으로 한정하십시오. 루프 사례는 단일 핑이 아니라 큰 전송으로 시험하십시오.

번역에도 같은 주의가 필요합니다. VPN 출구가 소스로 게이트웨이의 터널 주소를 요구한다면 VPN 인터페이스를 떠나는 업무 소스에만 적용하십시오. 홈의 일반 WAN 변환은 다른 범위이며, 조건 없는 masquerade 규칙 하나로 둘을 모두 표현할 수 없습니다.

두 규칙을 나란히 적어 그 쌍이 무관한 두 줄이 아니라 설계로 보이게 하십시오. 소스와 의도한 출구를 밝히는 주석이면 충분합니다.

실패 상태를 의도적으로 결정하라

VPN 경로가 사라질 때 무슨 일이 일어나는지 정하십시오. 업무 네트워크에서는 일반 WAN으로의 폴백 없이 거부하는 것이 정직한 답인데, 분리된 SSID의 요점은 그 트래픽이 잘못된 경로로 나가지 않는 것이기 때문입니다. 자동 재연결은 편의 기능이며 차단 정책이 아닙니다. 로그를 전혀 남기지 않는 거부 규칙은 고장 난 네트워크와 구별할 수 없습니다.

ip route show table work

각 SSID에서 새 연결을 시험한 다음 터널을 제거하고 다시 시험하십시오. 홈은 일반 경로를 유지하고 업무는 닫힌 채 실패해야 합니다. 두 개의 IPv4 서브넷이 그것에 대해 아무 말도 하지 않으므로 IPv6는 따로 확인하고, 정책 규칙 참조는 위에서 사용한 선택자를 문서화합니다.