MikroTik VPN 사용자가 너무 멀리 닿습니다: 호스트 하나와 포트 하나로 좁히세요

터널이 올라오고 로그인이 성공하며 네트워크의 모든 호스트가 응답합니다. 이것은 고장 난 VPN이 아니라 권한 모델이 없는 VPN입니다. RouterOS는 계정을 인증한 뒤 그 패킷을 다른 누구의 패킷처럼 라우팅하므로, 한계는 방화벽이 제공해야 합니다. 로그인을 깨지 않고 그 한계를 추가하는 것이 전부입니다.

인증은 권한이 시작되는 곳에서 끝납니다

PPP 세션이 올라오면 클라이언트의 패킷은 다른 어떤 인터페이스의 트래픽처럼 forward 체인으로 들어갑니다. 라우터의 forward 정책이 관대하다면 컨설턴트는 로그인 시 그 관대함을 물려받습니다. 계정은 결코 범위를 지닌 적이 없으므로 계정에서 바꿀 것은 없습니다. 규칙 집합은 직원용으로 작성되었고 새 세션은 그저 거기에 합류했습니다.

무엇이든 쓰기 전에 요청이 어느 경로에 관한 것인지 확인하세요. 라우터 뒤 호스트로 가는 트래픽은 forward를 지납니다, 반면 라우터 자체로 가는 트래픽은 winbox와 SSH를 포함해 input을 지납니다. forward만 덮는 범위는 기기를 같은 클라이언트에게 열어 둡니다.

두 체인 모두 결정이 필요하며, 결정이 input을 닫아 두는 것이라 해도 마찬가지입니다. 그 선택은 접근 요청에 속하며 나중에 덧붙이는 생각이 아닙니다.

세션을 이름 있는 목록에 연결하세요

PPP 프로필은 세션이 시작될 때 내주는 주소를 이름 있는 주소 목록에 넣을 수 있습니다. 그러면 일시적인 터널 주소가 방화벽이 이름으로 맞출 수 있는 것이 되고, 세션이 끝나면 항목은 사라집니다. 그다음 계정은 주소를 하드코딩한 규칙이 아니라 자기 프로필에서 범위를 물려받습니다.

먼저 프로필을 만든 뒤 secret을 그것에 명시적으로 묶으세요. 기본 프로필을 가리키는 secret은 원래 문제를 재현합니다.

프로필과 목록의 역할이 분명하도록 이름을 붙이고 둘 다에 요청 참조를 주석으로 남기세요. 프로필 하나로 같은 범위의 여러 사람을 맡을 수 있고, 목록은 여전히 각 세션을 식별합니다. 사람마다 규칙을 두는 것보다 검토가 쌉니다.

/ppp profile add name=scoped-consultant remote-address=consultant-pool address-list=vpn-scoped-clients
/ppp secret add name=consultant password=... service=ovpn profile=scoped-consultant

허용된 서비스를 하나의 목록에 기록하세요

허용된 서버를 필터 규칙에 주소를 박아 넣는 대신 자체 주소 목록에 두세요. 목록은 감사·확장·주석이 가능하고, 서버가 옮겨져도 그것을 쓰는 규칙은 바뀌지 않습니다. 항목 하나는 두 번째 호스트가 올 때까지 과해 보이며, 대개 옵니다.

주소가 동적이거나 부하 분산이면 목록으로 맞추고, 예약되어 안정적이면 주소를 직접 맞추세요. 주석이 서비스와 소유자를 밝히면 어느 쪽이든 분명히 읽힙니다.

호스트뿐 아니라 프로토콜과 포트도 좁히세요. 포트 제한이 없는 호스트에 대한 accept는 그 호스트가 돌리는 모든 서비스를 열어 주며, 이는 대부분의 접근 요청이 의도하는 것보다 넓습니다. 포트는 권한의 일부이며 나중에 덧붙일 세부가 아닙니다.

/ip firewall address-list add list=vpn-targets address=10.0.0.10 comment="consultant RDP target"

어떤 넓은 accept보다 앞에 점프를 두세요

점프 규칙은 범위 목록에서 전달된 트래픽을 전체 정책이 세 줄에 들어가는 전용 체인으로 보냅니다. 첫 규칙이 허용된 목적지와 포트를 받아들이고 마지막 규칙이 나머지를 버립니다. 점프는 앞선 accept가 있으면 점프가 결코 실행되지 않기 때문에 forward의 어떤 넓은 accept보다 위에 있어야 합니다. 돌아오는 트래픽이 계속 흐르도록 established와 related accept를 점프 앞에 두세요.

어떤 fasttrack 규칙도 이 트래픽을 범위 체인 너머로 나를 수 없음을 확인하세요. Fasttrack은 필터 경로의 나머지를 우회하며, fasttrack된 범위 세션은 전혀 범위가 없습니다.

라우터 자체 서비스에 닿을 수 없어야 한다면 input 체인에 대해서도 결정을 반복하세요. 전달 트래픽을 막고 winbox를 열어 두는 범위는 절반만 끝난 것입니다.

/ip firewall filter
add chain=forward action=jump jump-target=scoped-vpn src-address-list=vpn-scoped-clients
add chain=scoped-vpn action=accept protocol=tcp dst-address-list=vpn-targets dst-port=3389
add chain=scoped-vpn action=drop

카운터와 목록 구성으로 확인하세요

클라이언트에서 허용된 서비스와 반드시 실패해야 하는 서비스를 시험한 뒤 라우터에서 규칙 통계를 읽으세요. accept와 drop 카운터는 각 패킷이 어느 경로로 갔는지 보여 주며, 클라이언트는 그것을 볼 수 없습니다. 살아 있는 세션 주소가 범위 목록에 나타났는지도 확인하세요.

목록이 비어 있다면 계정이 다른 프로필에 있거나 프로필이 주소 목록 설정을 잃은 것입니다. 허용된 서비스가 실패하는데 drop 카운터가 오르면 목적지나 포트가 클라이언트가 보내는 것과 맞지 않습니다.

무엇이든 결론 내리기 전에 같은 서비스를 이름으로도 주소로도 시험하세요. 이름 해석 실패는 클라이언트 쪽에서 막힌 포트와 똑같이 보입니다. 그런 다음 프로필, 두 목록, 유일한 허용 서비스를 접근 요청에 기록해 다음 검토가 재구성이 아니라 비교를 하게 하세요.

/ip firewall filter print stats where chain=scoped-vpn
/ip firewall address-list print where list=vpn-scoped-clients