Mikrotik RouterOS의 정적 라우팅 기본 사항

라우팅은 TCP/IP 네트워크를 통해 패킷을 전송하기 위한 최상의 경로를 찾는 프로세스입니다. IPv4 네트워크에 연결된 모든 장치에는 프로세스 및 라우팅 테이블이 포함되어 있습니다.

이 기사는 HOWTO가 아니며, 예를 들어 RouterOS의 정적 라우팅을 설명하고 나머지 설정(예: 인터넷 액세스를 위한 srcnat)을 의도적으로 생략했기 때문에 자료를 이해하려면 네트워크 및 RouterOS에 대한 일정 수준의 지식이 필요합니다.

스위칭 및 라우팅

스위칭은 하나의 Layer2 세그먼트(이더넷, ppp, ...) 내에서 패킷을 교환하는 프로세스입니다. 장치가 패킷의 수신자가 자신과 동일한 이더넷 서브넷에 있는 것을 확인하면 arp 프로토콜을 사용하여 mac 주소를 학습하고 라우터를 우회하여 패킷을 직접 전송합니다. ppp(point-to-point) 연결에는 두 명의 참가자만 있을 수 있으며 패킷은 항상 하나의 주소 0xff로 전송됩니다.

라우팅은 Layer2 세그먼트 간에 패킷을 전송하는 프로세스입니다. 장치가 수신자가 이더넷 세그먼트 외부에 있는 패킷을 보내려는 경우 라우팅 테이블을 살펴보고 다음 패킷을 보낼 위치를 알고 있는(또는 패킷의 원래 보낸 사람을 모를 수 있는) 게이트웨이로 패킷을 전달합니다. 이 사실을 알지 못합니다).

라우터를 생각하는 가장 쉬운 방법은 두 개 이상의 Layer2 세그먼트에 연결되고 라우팅 테이블에서 최상의 경로를 결정하여 세그먼트 간에 패킷을 전달할 수 있는 장치로 생각하는 것입니다.

모든 것을 이해했거나 이미 알고 있다면 계속 읽으십시오. 나머지는 작지만 매우 큰 정보에 익숙해지는 것이 좋습니다. 조.

RouterOS 및 PacketFlow의 라우팅

정적 라우팅과 관련된 거의 모든 기능이 패키지에 있습니다. 체계. 비닐 봉투 라우팅 동적 라우팅 알고리즘(RIP, OSPF, BGP, MME), 라우팅 필터 및 BFD에 대한 지원을 추가합니다.

라우팅 설정을 위한 기본 메뉴: [IP]->[Route]. 복잡한 체계는 패킷에 라우팅 표시로 미리 레이블을 지정해야 할 수 있습니다. [IP]->[Firewall]->[Mangle] (쇠사슬 PREROUTING и OUTPUT).

PacketFlow에는 IP 패킷 라우팅 결정이 이루어지는 세 곳이 있습니다.

1. 라우터가 수신한 라우팅 패킷. 이 단계에서 패킷을 로컬 프로세스로 보낼지 아니면 네트워크로 더 보낼지 결정합니다. 운송 패키지 수신 출력 인터페이스
2. 로컬 발신 패킷 라우팅. 발신 패킷 수신 출력 인터페이스
3. 발신 패킷에 대한 추가 라우팅 단계를 통해 라우팅 결정을 변경할 수 있습니다. [Output|Mangle]

• 블록 1, 2의 패킷 경로는 블록 XNUMX, XNUMX의 규칙에 따라 다릅니다. [IP]->[Route]
• 지점 1, 2 및 3의 패킷 경로는 다음 규칙에 따라 달라집니다. [IP]->[Route]->[Rules]
• 블록 1, 3의 패키지 경로는 다음을 사용하여 영향을 받을 수 있습니다. [IP]->[Firewall]->[Mangle]

RIB, FIB, 라우팅 캐시

라우팅 정보 베이스
동적 라우팅 프로토콜, ppp 및 dhcp의 경로, 정적 및 연결된 경로에서 경로가 수집되는 기반입니다. 이 데이터베이스에는 관리자가 필터링한 경로를 제외한 모든 경로가 포함되어 있습니다.

조건부, 우리는 [IP]->[Route] RIB를 표시합니다.

포워딩 정보 베이스

RIB에서 최상의 경로가 수집되는 기반입니다. FIB의 모든 경로는 활성 상태이며 패킷 전달에 사용됩니다. 경로가 비활성화되면(관리자(시스템)에 의해 비활성화되거나 패킷을 전송해야 하는 인터페이스가 활성화되지 않음) FIB에서 경로가 제거됩니다.

라우팅 결정을 내리기 위해 FIB 테이블은 IP 패킷에 대한 다음 정보를 사용합니다.

• 소스 주소
• 목적지 주소
• 소스 인터페이스
• 라우팅 마크
• 서비스 약관(DSCP)

FIB 패키지에 들어가는 과정은 다음 단계를 거칩니다.

• 패키지가 로컬 라우터 프로세스용입니까?
• 패킷에 시스템 또는 사용자 PBR 규칙이 적용됩니까?
  • 그렇다면 패킷이 지정된 라우팅 테이블로 전송됩니다.
• 패킷은 기본 테이블로 전송됩니다.

조건부, 우리는 [IP]->[Route Active=yes] FIB를 표시합니다.

라우팅 캐시
경로 캐싱 메커니즘. 라우터는 패킷이 전송된 위치를 기억하고 유사한 패킷이 있는 경우(아마도 동일한 연결에서) FIB를 확인하지 않고 동일한 경로를 따라 이동하도록 합니다. 경로 캐시는 주기적으로 지워집니다.

RouterOS 관리자의 경우 라우팅 캐시를 보고 관리하기 위한 도구를 만들지는 않았지만 [IP]->[Settings].

이 메커니즘은 Linux 3.6 커널에서 제거되었지만 RouterOS는 여전히 커널 3.3.5를 사용합니다. 아마도 라우팅 캐시가 그 이유 중 하나일 것입니다.

경로 추가 대화상자

[IP]->[Route]->[+]

1. 경로를 생성하려는 서브넷(기본값: 0.0.0.0/0)
2. 패킷이 전송될 게이트웨이 IP 또는 인터페이스(여러 개가 있을 수 있음, 아래 ECMP 참조)
3. 게이트웨이 가용성 확인
4. 레코드 유형
5. 경로의 거리(미터법)
6. 라우팅 테이블
7. 이 경로를 통한 로컬 발신 패킷용 IP
8. 범위 및 대상 범위의 목적은 기사 끝에 작성됩니다.

경로 플래그

• X - 관리자가 경로를 비활성화했습니다(disabled=yes)
• A - 경로는 패킷을 보내는 데 사용됩니다.
• D - 동적으로 추가된 경로(BGP, OSPF, RIP, MME, PPP, DHCP, 연결됨)
• C - 서브넷이 라우터에 직접 연결됨
• S - 정적 경로
• r,b,o,m - 동적 라우팅 프로토콜 중 하나에 의해 추가된 경로
• B,U,P - 필터링 경로(전송 대신 패킷 삭제)

게이트웨이에서 무엇을 지정해야 합니까: IP 주소 또는 인터페이스?

이 시스템을 사용하면 둘 다 지정할 수 있지만 맹세하지 않고 잘못한 경우 힌트를 제공하지 않습니다.

IP 주소
게이트웨이 주소는 Layer2를 통해 액세스할 수 있어야 합니다. 이더넷의 경우 이것은 라우터가 활성 ip 인터페이스 중 하나에 있는 동일한 서브넷의 주소를 가져야 함을 의미합니다. ppp의 경우 게이트웨이 주소는 활성 인터페이스 중 하나에 서브넷 주소로 지정됩니다.
Layer2에 대한 접근성 조건이 충족되지 않으면 경로가 비활성으로 간주되어 FIB에 속하지 않습니다.

인터페이스
모든 것이 더 복잡하고 라우터의 동작은 인터페이스 유형에 따라 다릅니다.

• PPP(Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN *) 연결은 두 명의 참가자만 가정하고 패킷은 항상 전송을 위해 게이트웨이로 전송됩니다. 게이트웨이가 수신자가 자신임을 감지하면 다음으로 패킷을 전송합니다. 로컬 프로세스입니다.
  
• 이더넷은 많은 참여자가 있다고 가정하고 패킷 수신자의 주소와 함께 arp 인터페이스에 요청을 보낼 것입니다. 이것은 연결된 경로에 대해 예상되고 매우 정상적인 동작입니다.
  그러나 인터페이스를 원격 서브넷의 경로로 사용하려고 하면 다음과 같은 상황이 발생합니다. 경로가 활성 상태이고 게이트웨이에 대한 ping이 통과하지만 지정된 서브넷의 수신자에게 도달하지 않습니다. 스니퍼를 통해 인터페이스를 보면 원격 서브넷의 주소가 포함된 arp 요청이 표시됩니다.
  

가능할 때마다 IP 주소를 게이트웨이로 지정하십시오. 단, 연결된 경로(자동 생성) 및 PPP(Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN*) 인터페이스는 예외입니다.

OpenVPN에는 PPP 헤더가 포함되어 있지 않지만 OpenVPN 인터페이스 이름을 사용하여 경로를 생성할 수 있습니다.

보다 구체적인 경로

기본 라우팅 규칙. 더 작은 서브넷(서브넷 마스크가 가장 큰)을 설명하는 경로가 패킷의 라우팅 결정에 우선합니다. 라우팅 테이블에서 항목의 위치는 선택과 관련이 없습니다. 기본 규칙은 더 구체적입니다.

지정된 체계의 모든 경로가 활성 상태입니다(FIB에 있음). 서로 다른 서브넷을 가리키고 서로 충돌하지 않습니다.

게이트웨이 중 하나를 사용할 수 없게 되면 연결된 경로는 비활성(FIB에서 제거됨)으로 간주되고 나머지 경로에서 패킷이 검색됩니다.

서브넷이 0.0.0.0/0인 경로는 때때로 특별한 의미가 부여되며 "기본 경로" 또는 "마지막 수단의 게이트웨이"라고 합니다. 사실 마법 같은 것은 없으며 단순히 가능한 모든 IPv4 주소를 포함하지만 이러한 이름은 작업을 잘 설명합니다. 다른 더 정확한 경로가 없는 패킷을 전달할 게이트웨이를 나타냅니다.

IPv4의 가능한 최대 서브넷 마스크는 /32이며 이 경로는 특정 호스트를 가리키며 라우팅 테이블에서 사용할 수 있습니다.

보다 구체적인 경로를 이해하는 것은 모든 TCP/IP 장치의 기본입니다.

거리

여러 게이트웨이를 통해 액세스할 수 있는 단일 서브넷에 대한 경로의 관리 필터링에는 거리(또는 지표)가 필요합니다. 메트릭이 낮은 경로는 우선 순위로 간주되어 FIB에 포함됩니다. 메트릭이 더 낮은 경로가 활성화를 중단하면 FIB에서 메트릭이 더 높은 경로로 대체됩니다.

동일한 메트릭을 가진 동일한 서브넷에 대한 여러 경로가 있는 경우 라우터는 내부 논리에 따라 그 중 하나만 FIB 테이블에 추가합니다.

메트릭은 0에서 255 사이의 값을 가질 수 있습니다.

• 0 - 연결된 경로에 대한 메트릭입니다. 거리 0은 관리자가 설정할 수 없습니다.
• 1-254 - 경로 설정을 위해 관리자가 사용할 수 있는 메트릭입니다. 값이 낮은 메트릭의 우선 순위가 더 높습니다.
• 255 - 경로 설정을 위해 관리자가 사용할 수 있는 메트릭입니다. 1-254와 달리 메트릭이 255인 경로는 항상 비활성 상태로 유지되며 FIB에 빠지지 않습니다.
• 특정 메트릭. 동적 라우팅 프로토콜에서 파생된 경로에는 표준 메트릭 값이 있습니다.

게이트웨이 확인

게이트웨이 확인은 icmp 또는 arp를 통해 게이트웨이의 가용성을 확인하기 위한 MikroTik RoutesOS 확장입니다. 10초마다 한 번씩(변경 불가) 게이트웨이로 요청을 보내고, 두 번 응답을 받지 못하면 해당 경로는 사용할 수 없는 것으로 간주되어 FIB에서 제거됩니다. 검사 게이트웨이가 비활성화된 경우 검사 경로가 계속되고 검사가 한 번 성공한 후 경로가 다시 활성화됩니다.

Check gateway는 구성된 항목과 지정된 게이트웨이가 있는 다른 모든 항목(모든 라우팅 테이블 및 ecmp 경로에 있음)을 비활성화합니다.

일반적으로 체크 게이트웨이는 게이트웨이로의 패킷 손실 문제가 없는 한 잘 작동합니다. 검사 게이트웨이는 검사 게이트웨이 외부의 통신에서 무슨 일이 일어나고 있는지 알지 못하므로 스크립트, 재귀 라우팅, 동적 라우팅 프로토콜과 같은 추가 도구가 필요합니다.

대부분의 VPN 및 터널 프로토콜에는 연결 활동을 확인하기 위한 기본 제공 도구가 포함되어 있으므로 게이트웨이 확인을 활성화하면 네트워크 및 장치 성능에 대한 추가(하지만 매우 작은) 부하가 발생합니다.

ECMP 경로

Equal-Cost Multi-Path - 라운드 로빈 알고리즘을 사용하여 동시에 여러 게이트웨이를 사용하여 수신자에게 패킷을 보냅니다.

ECMP 경로는 관리자가 하나의 서브넷에 대해 여러 게이트웨이를 지정하여(또는 동등한 OSPF 경로가 두 개인 경우 자동으로) 생성됩니다.

ECMP는 이론적으로 두 채널 간의 로드 밸런싱에 사용됩니다. 이론적으로 ecmp 경로에 두 개의 채널이 있는 경우 각 패킷에 대해 나가는 채널이 달라야 합니다. 그러나 라우팅 캐시 메커니즘은 첫 번째 패킷이 취한 경로를 따라 연결에서 패킷을 보냅니다.

라우팅 캐시를 비활성화하면 ECMP 경로의 패킷이 올바르게 공유되지만 NAT에 문제가 있습니다. NAT 규칙은 연결의 첫 번째 패킷만 처리하고(나머지는 자동으로 처리됨) 소스 주소가 동일한 패킷은 서로 다른 인터페이스에서 나갑니다.

게이트웨이 확인이 ECMP 경로에서 작동하지 않습니다(RouterOS 버그). 그러나 ECMP에서 항목을 비활성화하는 추가 유효성 검사 경로를 생성하여 이 제한을 해결할 수 있습니다.

라우팅을 통한 필터링

유형 옵션은 패키지로 수행할 작업을 결정합니다.

• 유니캐스트 - 지정된 게이트웨이(인터페이스)로 전송
• 블랙홀 - 패킷 폐기
• 금지, 도달 불가능 - 패킷을 버리고 icmp 메시지를 발신자에게 보냅니다.

필터링은 일반적으로 잘못된 경로를 따라 패킷이 전송되는 것을 보호해야 할 때 사용되며 물론 방화벽을 통해 이를 필터링할 수 있습니다.

몇 가지 예

라우팅에 대한 기본 사항을 통합합니다.

일반적인 가정용 라우터

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1

1. 0.0.0.0/0에 대한 정적 경로(기본 경로)
2. 공급자와의 인터페이스에서 연결된 경로
3. LAN 인터페이스의 연결된 경로

PPPoE를 사용하는 일반적인 홈 라우터

1. 자동으로 추가되는 기본 경로에 대한 고정 경로. 연결 속성에 지정됩니다.
2. PPP 연결을 위한 연결 경로
3. LAN 인터페이스의 연결된 경로

XNUMX개의 공급자와 이중화가 있는 일반적인 홈 라우터

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 distance=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 distance=2

1. 메트릭 1 및 게이트웨이 가용성 확인이 있는 첫 번째 공급자를 통한 기본 경로에 대한 정적 경로
2. 메트릭 2가 있는 두 번째 공급자를 통해 기본 경로에 대한 정적 경로
3. 연결된 경로

0.0.0.0/0에 대한 트래픽은 이 게이트웨이를 사용할 수 있는 동안 10.10.10.1을 통과하고 그렇지 않으면 10.20.20.1로 전환합니다.

이러한 방식은 채널 예약으로 간주될 수 있지만 단점이 없는 것은 아닙니다. 공급자의 게이트웨이 외부(예: 운영자 네트워크 내부)에서 중단이 발생하면 라우터는 이를 알지 못하고 계속해서 경로를 활성 상태로 간주합니다.

두 공급자, 중복 및 ECMP가 있는 일반적인 홈 라우터

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.10.10.1,10.20.20.1 distance=1

1. Chack 게이트웨이 확인을 위한 정적 경로
2. ECMP 경로
3. 연결된 경로

확인할 경로는 파란색(비활성 경로의 색상)이지만 검사 게이트웨이를 방해하지 않습니다. RoS의 현재 버전(6.44)은 ECMP 경로에 자동 우선 순위를 부여하지만 다른 라우팅 테이블에 테스트 경로를 추가하는 것이 좋습니다(옵션 routing-mark)

Speedtest 및 기타 유사한 사이트에서는 속도가 증가하지 않지만(ECMP는 트래픽을 패킷이 아닌 연결로 나눕니다), p2p 응용 프로그램은 더 빠르게 다운로드해야 합니다.

라우팅을 통한 필터링

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1
add dst-address=192.168.200.0/24 gateway=10.30.30.1 distance=1
add dst-address=192.168.200.0/24 gateway=10.10.10.1 distance=2 type=blackhole

1. 기본 경로에 대한 정적 경로
2. ipip 터널을 통해 192.168.200.0/24에 대한 정적 경로
3. ISP 라우터를 통한 192.168.200.0/24에 대한 정적 경로 금지

ipip 인터페이스가 비활성화된 경우 터널 트래픽이 공급자의 라우터로 이동하지 않는 필터링 옵션입니다. 이러한 체계는 거의 필요하지 않습니다. 방화벽을 통해 차단을 구현할 수 있습니다.

라우팅 루프
라우팅 루프 - 패킷이 ttl 만료 전에 라우터 간에 실행되는 상황입니다. 일반적으로 이는 구성 오류의 결과이며 대규모 네트워크에서는 작은 네트워크에서 동적 라우팅 프로토콜의 구현으로 조심스럽게 처리됩니다.

다음과 같이 보입니다.

유사한 결과를 얻는 방법에 대한 (가장 간단한) 예:

라우팅 루프 예제는 실용적이지 않지만 라우터가 이웃의 라우팅 테이블에 대해 전혀 모른다는 것을 보여줍니다.

정책 기반 라우팅 및 추가 라우팅 테이블

경로를 선택할 때 라우터는 패킷 헤더(Dst. Address)에서 하나의 필드만 사용합니다. 이것이 기본 라우팅입니다. 원본 주소, 트래픽 유형(ToS), ECMP 없는 균형 등 다른 조건에 기반한 라우팅은 PBR(Policy Base Routing)에 속하며 추가 라우팅 테이블을 사용합니다.

보다 구체적인 경로 라우팅 테이블 내의 기본 경로 선택 규칙입니다.

기본적으로 모든 라우팅 규칙은 기본 테이블에 추가됩니다. 관리자는 임의 개수의 추가 라우팅 테이블을 생성하고 여기에 패킷을 라우팅할 수 있습니다. 다른 테이블의 규칙은 서로 충돌하지 않습니다. 패키지가 지정된 테이블에서 적절한 규칙을 찾지 못하면 기본 테이블로 이동합니다.

방화벽을 통한 배포의 예:

• 192.168.100.10-> 8.8.8.8
  1. 192.168.100.10의 트래픽에 레이블이 지정됨 isp1을 통해 в [Prerouting|Mangle]
  2. 테이블의 라우팅 단계에서 isp1을 통해 8.8.8.8에 대한 경로 검색
  3. 경로를 찾았습니다. 트래픽은 게이트웨이 10.10.10.1로 전송됩니다.
• 192.168.200.20-> 8.8.8.8
  1. 192.168.200.20의 트래픽에 레이블이 지정됨 isp2을 통해 в [Prerouting|Mangle]
  2. 테이블의 라우팅 단계에서 isp2을 통해 8.8.8.8에 대한 경로 검색
  3. 경로를 찾았습니다. 트래픽은 게이트웨이 10.20.20.1로 전송됩니다.
• 게이트웨이 중 하나(10.10.10.1 또는 10.20.20.1)를 사용할 수 없게 되면 패킷이 테이블로 이동합니다. 본관 거기에서 적절한 경로를 찾을 것입니다

용어 문제

RouterOS에는 특정 용어 문제가 있습니다.
에서 규칙으로 작업할 때 [IP]->[Routes] 라우팅 테이블이 표시되지만 레이블은 다음과 같습니다.

В [IP]->[Routes]->[Rule] 테이블 작업의 레이블 조건에서 모든 것이 정확합니다.

특정 라우팅 테이블로 패킷을 보내는 방법

RouterOS는 다음과 같은 몇 가지 도구를 제공합니다.

• 규칙 [IP]->[Routes]->[Rules]
• 경로 마커(action=mark-routing)에서 [IP]->[Firewall]->[Mangle]
• VRF

규칙 [IP]->[Route]->[Rules]
규칙은 순차적으로 처리되며 패킷이 규칙의 조건과 일치하면 더 이상 전달되지 않습니다.

라우팅 규칙을 사용하면 수신자 주소뿐만 아니라 패킷을 수신한 소스 주소와 인터페이스에 의존하여 라우팅 가능성을 확장할 수 있습니다.

규칙은 조건과 작업으로 구성됩니다.

• 정황. 패키지가 FIB에서 확인되는 표시 목록을 실질적으로 반복합니다. ToS만 누락됩니다.
• 활동
  • 조회 - 테이블에 패킷 보내기
  • lookup only in table - 테이블에서 패키지를 잠급니다. 경로를 찾을 수 없으면 패키지가 기본 테이블로 이동하지 않습니다.
  • 드롭 - 패킷 드롭
  • 연결할 수 없음 - 발신자 알림과 함께 패킷 폐기

FIB에서 로컬 프로세스에 대한 트래픽은 규칙을 우회하여 처리됩니다. [IP]->[Route]->[Rules]:

마킹 [IP]->[Firewall]->[Mangle]
라우팅 레이블을 사용하면 거의 모든 방화벽 조건을 사용하여 패킷에 대한 게이트웨이를 설정할 수 있습니다.

실제로 모든 항목이 의미가 있는 것은 아니며 일부는 불안정하게 작동할 수 있습니다.

패키지에 레이블을 지정하는 방법에는 두 가지가 있습니다.

• 즉시 넣어 라우팅 마크
• 먼저 넣어 연결 표시, 다음을 기반으로 연결 표시 설정 라우팅 마크

방화벽에 관한 기사에서 두 번째 옵션이 바람직하다고 썼습니다. 경로를 표시하는 경우 CPU의 부하를 줄입니다. 이것은 전적으로 사실이 아닙니다. 이러한 마킹 방법이 항상 동일한 것은 아니며 일반적으로 다양한 문제를 해결하는 데 사용됩니다.

사용 예

정책 기반 라우팅을 사용하는 예제로 이동해 보겠습니다. 이 모든 것이 필요한 이유를 훨씬 쉽게 보여줄 수 있습니다.

MultiWAN 및 나가는(출력) 트래픽 반환
MultiWAN 구성의 일반적인 문제: Mikrotik은 "활성" 공급자를 통해서만 인터넷에서 사용할 수 있습니다.

라우터는 요청이 어떤 IP로 왔는지 신경 쓰지 않고 응답을 생성할 때 isp1을 통한 경로가 활성화된 라우팅 테이블에서 경로를 찾습니다. 또한 이러한 패킷은 수신자에게 가는 도중에 필터링될 가능성이 높습니다.

또 다른 흥미로운 점. ether1 인터페이스에 "단순" 소스 nat가 구성된 경우: /ip fi nat add out-interface=ether1 action=masquerade 패키지는 src와 함께 온라인 상태가 됩니다. address=10.10.10.100, 이는 상황을 더욱 악화시킵니다.

문제를 해결하는 방법에는 여러 가지가 있지만 그 중 어떤 방법이든 추가 라우팅 테이블이 필요합니다.

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 check-gateway=ping distance=1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 check-gateway=ping distance=2
add dst-address=0.0.0.0/0 gateway=10.10.10.1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 routing-mark=over-isp2

사용 [IP]->[Route]->[Rules]
지정된 소스 IP가 있는 패킷에 사용할 라우팅 테이블을 지정합니다.

/ip route rule
add src-address=10.10.10.100/32 action=lookup-only-in-table table=over-isp1
add src-address=10.20.20.200/32 action=lookup-only-in-table table=over-isp2

사용할 수 있습니다 action=lookup, 그러나 로컬 발신 트래픽의 경우 이 옵션은 잘못된 인터페이스의 연결을 완전히 제외합니다.

• 시스템은 Src로 응답 패킷을 생성합니다. 주소: 10.20.20.200
• Routing Decision(2) 단계에서 확인하는 사항 [IP]->[Routes]->[Rules] 패킷은 라우팅 테이블로 전송됩니다. ISP2 이상
• 라우팅 테이블에 따르면 패킷은 ether10.20.20.1 인터페이스를 통해 게이트웨이 2로 전송되어야 합니다.

이 방법은 Mangle 테이블을 사용하는 것과 달리 작동하는 연결 추적기가 필요하지 않습니다.

사용 [IP]->[Firewall]->[Mangle]
들어오는 패킷으로 연결이 시작되므로 표시(action=mark-connection), 표시된 연결에서 나가는 패킷의 경우 라우팅 레이블(action=mark-routing).

/ip firewall mangle
#Маркировка входящих соединений
add chain=input in-interface=ether1 connection-state=new action=mark-connection new-connection-mark=from-isp1
add chain=input in-interface=ether2 connection-state=new action=mark-connection new-connection-mark=from-isp2
#Маркировка исходящих пакетов на основе соединений
add chain=output connection-mark=from-isp1 action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=output connection-mark=from-isp2 action=mark-routing new-routing-mark=over-isp2 passthrough=no

하나의 인터페이스에 여러 개의 ip가 구성되어 있는 경우 조건에 추가할 수 있습니다. dst-address 확인하기.

• 패킷은 ether2 인터페이스에서 연결을 엽니다. 패키지가 들어갑니다 [INPUT|Mangle] 연결의 모든 패킷을 다음과 같이 표시합니다. isp2에서
• 시스템은 Src로 응답 패킷을 생성합니다. 주소: 10.20.20.200
• Routing Decision(2) 단계에서는 라우팅 테이블에 따라 패킷이 ether10.20.20.1 인터페이스를 통해 게이트웨이 1로 전송됩니다. 패키지를 로그인하여 이를 확인할 수 있습니다. [OUTPUT|Filter]
• 무대 위에 [OUTPUT|Mangle] 연결 레이블이 확인됨 isp2에서 패킷은 경로 레이블을 수신합니다. ISP2 이상
• Routing Adjusment(3) 단계는 라우팅 레이블이 있는지 확인하고 적절한 라우팅 테이블로 보냅니다.
• 라우팅 테이블에 따르면 패킷은 ether10.20.20.1 인터페이스를 통해 게이트웨이 2로 전송되어야 합니다.

MultiWAN 및 반환 dst-nat 트래픽

예를 들어 사설 서브넷의 라우터 뒤에 서버(예: 웹)가 있고 공급자를 통해 서버에 대한 액세스를 제공해야 하는 경우 수행할 작업은 더 복잡합니다.

/ip firewall nat
add chain=dstnat proto=tcp dst-port=80,443 in-interface=ether1 action=dst-nat to-address=192.168.100.100
add chain=dstnat proto=tcp dst-port=80,443 in-interface=ether2 action=dst-nat to-address=192.168.100.100

문제의 본질은 동일하며 솔루션은 Firewall Mangle 옵션과 유사하며 다른 체인만 사용됩니다.

/ip firewall mangle
add chain=prerouting connection-state=new in-interface=ether1 protocol=tcp dst-port=80,443 action=mark-connection new-connection-mark=web-input-isp1
add chain=prerouting connection-state=new in-interface=ether2 protocol=tcp dst-port=80,443 action=mark-connection new-connection-mark=web-input-isp2
add chain=prerouting connection-mark=web-input-isp1 in-interface=ether3 action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=prerouting connection-mark=web-input-isp2 in-interface=ether3 action=mark-routing new-routing-mark=over-isp2 passthrough=no

다이어그램에는 NAT가 표시되지 않지만 모든 것이 명확하다고 생각합니다.

MultiWAN 및 아웃바운드 연결

PBR 기능을 사용하여 서로 다른 라우터 인터페이스에서 다중 VPN(예에서는 SSTP) 연결을 생성할 수 있습니다.

추가 라우팅 테이블:

/ip route
add dst-address=0.0.0.0/0 gateway=192.168.100.1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=192.168.200.1 routing-mark=over-isp2
add dst-address=0.0.0.0/0 gateway=192.168.0.1 routing-mark=over-isp3

add dst-address=0.0.0.0/0 gateway=192.168.100.1 distance=1
add dst-address=0.0.0.0/0 gateway=192.168.200.1 distance=2
add dst-address=0.0.0.0/0 gateway=192.168.0.1 distance=3

패키지 표시:

/ip firewall mangle
add chain=output dst-address=10.10.10.100 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp1 passtrough=no
add chain=output dst-address=10.10.10.101 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp2 passtrough=no
add chain=output dst-address=10.10.10.102 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp3 passtrough=no

간단한 NAT 규칙, 그렇지 않으면 패킷이 잘못된 Src와 함께 인터페이스를 떠납니다. 주소:

/ip firewall nat
add chain=srcnat out-interface=ether1 action=masquerade
add chain=srcnat out-interface=ether2 action=masquerade
add chain=srcnat out-interface=ether3 action=masquerade

파싱 ​​:

• 라우터는 XNUMX개의 SSTP 프로세스를 생성합니다.
• Routing Decision (2) 단계에서는 메인 라우팅 테이블을 기반으로 이러한 프로세스에 대한 경로를 선택합니다. 동일한 경로에서 패킷은 Src를 수신합니다. ether1 인터페이스에 바인딩된 주소
• В [Output|Mangle] 다른 연결의 패킷은 다른 레이블을 받습니다.
• 패킷은 Routing Adjusment 단계에서 레이블에 해당하는 테이블에 들어가 패킷을 보낼 새로운 경로를 받습니다.
• 그러나 패키지에는 여전히 Src가 있습니다. 단계에서 ether1의 주소 [Nat|Srcnat] 주소는 인터페이스에 따라 대체됩니다.

흥미롭게도 라우터에서 다음 연결 테이블을 볼 수 있습니다.

연결 추적기가 더 일찍 작동합니다. [Mangle] и [Srcnat], 그래서 모든 연결은 동일한 주소에서 나옵니다. 자세히 보면 Replay Dst. Address NAT 다음에 주소가 있습니다.

VPN 서버(테스트 벤치에 하나 있음)에서 모든 연결이 올바른 주소에서 오는 것을 볼 수 있습니다.

길을 잡아
더 쉬운 방법이 있습니다. 각 주소에 대해 특정 게이트웨이를 간단히 지정할 수 있습니다.

/ip route
add dst-address=10.10.10.100 gateway=192.168.100.1
add dst-address=10.10.10.101 gateway=192.168.200.1
add dst-address=10.10.10.102 gateway=192.168.0.1

그러나 이러한 경로는 나가는 트래픽뿐만 아니라 통과하는 트래픽에도 영향을 미칩니다. 또한 부적절한 통신 채널을 통과하기 위해 VPN 서버에 대한 트래픽이 필요하지 않은 경우 6개의 규칙을 더 추가해야 합니다. [IP]->[Routes]с type=blackhole. 이전 버전에서 - 3개의 규칙 [IP]->[Route]->[Rules].

통신 채널별 사용자 연결 분포

단순하고 일상적인 작업. 다시 말하지만 추가 라우팅 테이블이 필요합니다.

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=2 check-gateway=ping

add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=1 routing-mark=over-isp2

사용 [IP]->[Route]->[Rules]

/ip route rules
add src-address=192.168.100.0/25 action=lookup-only-in-table table=over-isp1
add src-address=192.168.100.128/25 action=lookup-only-in-table table=over-isp2

사용하는 경우 action=lookup그런 다음 채널 중 하나가 비활성화되면 트래픽이 기본 테이블로 이동하고 작업 채널을 통과합니다. 이것이 필요한지 여부는 작업에 따라 다릅니다.

의 표시 사용 [IP]->[Firewall]->[Mangle]
IP 주소 목록이 있는 간단한 예입니다. 원칙적으로 거의 모든 조건을 사용할 수 있습니다. layer7의 유일한 주의 사항은 연결 레이블과 쌍을 이루는 경우에도 모든 것이 올바르게 작동하는 것처럼 보일 수 있지만 일부 트래픽은 여전히 ​​잘못된 방향으로 이동합니다.

/ip firewall mangle
add chain=prerouting src-address-list=users-over-isp1 dst-address-type=!local action=mark-routing new-routing-mark=over-isp1
add chain=prerouting src-address-list=users-over-isp2 dst-address-type=!local action=mark-routing new-routing-mark=over-isp2

다음을 통해 하나의 라우팅 테이블에서 사용자를 "잠글" 수 있습니다. [IP]->[Route]->[Rules]:

/ip route rules
add routing-mark=over-isp1 action=lookup-only-in-table table=over-isp1
add routing-mark=over-isp2 action=lookup-only-in-table table=over-isp2

통해 [IP]->[Firewall]->[Filter]:

/ip firewall filter
add chain=forward routing-mark=over-isp1 out-interface=!ether1 action=reject
add chain=forward routing-mark=over-isp2 out-interface=!ether2 action=reject

리트리트 프로 dst-address-type=!local
추가 조건 dst-address-type=!local 사용자의 트래픽이 라우터의 로컬 프로세스(dns, winbox, ssh, ...)에 도달해야 합니다. 여러 로컬 서브넷이 라우터에 연결된 경우 예를 들어 다음을 사용하여 서브넷 간의 트래픽이 인터넷으로 이동하지 않도록 해야 합니다. dst-address-table.

사용 예에서 [IP]->[Route]->[Rules] 이러한 예외는 없지만 트래픽은 로컬 프로세스에 도달합니다. 사실은 표시된 FIB 패키지에 들어가는 것입니다. [PREROUTING|Mangle] 경로 레이블이 있고 로컬 인터페이스가 없는 기본 이외의 라우팅 테이블로 이동합니다. 라우팅 규칙의 경우 먼저 패킷이 로컬 프로세스용인지 확인하고 사용자 PBR 단계에서만 지정된 라우팅 테이블로 이동합니다.

사용 [IP]->[Firewall]->[Mangle action=route]
이 작업은 [Prerouting|Mangle] 게이트웨이 주소를 직접 지정하여 추가 라우팅 테이블을 사용하지 않고 지정된 게이트웨이로 트래픽을 보낼 수 있습니다.

/ip firewall mangle
add chain=prerouting src-address=192.168.100.0/25 action=route gateway=10.10.10.1
add chain=prerouting src-address=192.168.128.0/25 action=route gateway=10.20.20.1

Действие route 라우팅 규칙보다 우선 순위가 낮습니다([IP]->[Route]->[Rules]). 경로 표시의 경우 모든 것은 규칙의 위치에 따라 달라집니다. action=route 이상의 가치 action=mark-route, 그러면 사용됩니다(플래그에 관계없이 passtrough), 그렇지 않으면 경로를 표시합니다.
위키에는 이 작업에 대한 정보가 거의 없으며 모든 결론은 실험적으로 얻은 것입니다. 어쨌든 이 옵션을 사용할 때 다른 옵션보다 이점을 제공하는 옵션을 찾지 못했습니다.

PPC 기반 동적 밸런싱

Per Connection Classifier - 보다 유연한 ECMP 아날로그입니다. ECMP와 달리 트래픽을 연결별로 더 엄격하게 나눕니다(ECMP는 연결에 대해 아무것도 모르지만 라우팅 캐시와 쌍을 이루면 비슷한 결과를 얻음).

PCC는 지정된 필드 ip 헤더에서 32비트 값으로 변환하고 다음으로 나눕니다. 분모. 나눗셈의 나머지 부분은 지정된 값과 비교됩니다. 나머지 일치하면 지정된 조치가 적용됩니다. 더. 미친 소리처럼 들리지만 작동합니다.

주소가 XNUMX개인 예:

192.168.100.10: 192+168+100+10 = 470 % 3 = 2
192.168.100.11: 192+168+100+11 = 471 % 3 = 0
192.168.100.12: 192+168+100+12 = 472 % 3 = 1

XNUMX개 채널 간 src.address에 의한 동적 트래픽 분배의 예:

#Таблица маршрутизации
/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=2 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.30.30.1 dist=3 check-gateway=ping

add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=1 routing-mark=over-isp2
add dst-address=0.0.0.0/0 gateway=10.30.30.1 dist=1 routing-mark=over-isp3

#Маркировка соединений и маршрутов
/ip firewall mangle
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/0 action=mark-connection new-connection-mark=conn-over-isp1
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/1 action=mark-connection new-connection-mark=conn-over-isp2
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/2 action=mark-connection new-connection-mark=conn-over-isp3

add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp1 action=mark-routing new-routing-mark=over-isp1
add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp2 action=mark-routing new-routing-mark=over-isp2
add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp3 action=mark-routing new-routing-mark=over-isp3

경로를 표시할 때 추가 조건이 있습니다. in-interface=br-lan, 그것 없이 action=mark-routing 인터넷의 응답 트래픽은 라우팅 테이블에 따라 공급자에게 다시 돌아갑니다.

통신 채널 전환

Check ping은 좋은 도구이지만 가장 가까운 IP 피어와의 연결만 확인하고 공급자 네트워크는 일반적으로 많은 수의 라우터로 구성되며 가장 가까운 피어 외부에서 연결 끊김이 발생할 수 있습니다. 문제가 있습니다. 일반적으로 ping을 확인하면 글로벌 네트워크에 대한 액세스에 대한 최신 정보가 항상 표시되지 않습니다.
공급자와 대기업에 BGP 동적 라우팅 프로토콜이 있는 경우 가정 및 사무실 사용자는 특정 통신 채널을 통해 인터넷 액세스를 확인하는 방법을 독립적으로 파악해야 합니다.

일반적으로 특정 통신 채널을 통해 인터넷에서 IP 주소의 가용성을 확인하고 신뢰할 수 있는 것을 선택하는 스크립트(예: google dns: 8.8.8.8)가 사용됩니다. 8.8.4.4. 그러나 Mikrotik 커뮤니티에서는 이를 위해 더 흥미로운 도구가 조정되었습니다.

재귀 라우팅에 대한 몇 마디
다중 홉 BGP 피어링을 구축할 때 재귀 라우팅이 필요하며 추가 스크립트 없이 통신 채널을 전환하기 위해 체크 게이트웨이와 쌍을 이루는 재귀 경로를 사용하는 방법을 알아낸 교활한 MikroTik 사용자로 인해 정적 라우팅의 기본 사항에 대한 기사에 들어갔습니다.

일반적인 용어로 범위/대상 범위 옵션과 경로가 인터페이스에 바인딩되는 방법을 이해할 때입니다.

1. 경로는 해당 범위 값 및 대상 범위 값보다 작거나 같은 기본 테이블의 모든 항목을 기반으로 패킷을 보낼 인터페이스를 조회합니다.
2. 찾은 인터페이스에서 지정된 게이트웨이로 패킷을 보낼 수 있는 인터페이스를 선택합니다.
3. 찾은 연결 항목의 인터페이스를 선택하여 패킷을 게이트웨이로 보냅니다.

재귀 경로가 있으면 모든 것이 동일하지만 두 단계로 진행됩니다.

• 1-3 지정된 게이트웨이에 도달할 수 있는 연결된 경로에 하나 이상의 경로가 추가됩니다.
• 4-6 "중간" 게이트웨이에 대한 경로 연결 경로 찾기

재귀 검색의 모든 조작은 RIB에서 발생하며 최종 결과만 FIB로 전송됩니다. 0.0.0.0/0 via 10.10.10.1 on ether1.

재귀 라우팅을 사용하여 경로를 전환하는 예

구성 :

/ip route
add dst-address=0.0.0.0/0 gateway=8.8.8.8 check-gateway=ping distance=1 target-scope=10
add dst-address=8.8.8.8 gateway=10.10.10.1 scope=10
add dst-address=0.0.0.0/0 gateway=10.20.20.1 distance=2

패킷이 10.10.10.1로 전송되는지 확인할 수 있습니다.

Check gateway는 재귀적 라우팅에 대해 아무것도 모르고 단순히 ping을 8.8.8.8로 보냅니다. (기본 테이블을 기반으로) 게이트웨이 10.10.10.1을 통해 액세스할 수 있습니다.

10.10.10.1과 8.8.8.8 사이에 통신이 끊어지면 경로 연결이 끊어지지만 8.8.8.8에 대한 패킷(테스트 핑 포함)은 계속해서 10.10.10.1을 통과합니다.

ether1에 대한 링크가 끊어지면 8.8.8.8 이전의 패킷이 두 번째 공급자를 통과할 때 불쾌한 상황이 발생합니다.

이것은 8.8.8.8을 사용할 수 없을 때 NetWatch를 사용하여 스크립트를 실행하는 경우 문제가 됩니다. 링크가 끊어지면 NetWatch는 단순히 백업 통신 채널을 통해 작업하고 모든 것이 정상이라고 가정합니다. 추가 필터 경로를 추가하여 해결:

/ip route
add dst-address=8.8.8.8 gateway=10.20.20.1 distance=100 type=blackhole

하브레에 있다 기사, 여기에서 NetWatch의 상황이 더 자세히 고려됩니다.

그리고 예, 그러한 예약을 사용할 때 주소 8.8.8.8은 공급자 중 하나에 하드 코딩되므로 DNS 소스로 선택하는 것은 좋은 생각이 아닙니다.

VRF(Virtual Routing and Forwarding)에 대한 몇 마디

VRF 기술은 하나의 물리적 라우터 내에 여러 가상 라우터를 생성하도록 설계되었으며, 이 기술은 통신 사업자(일반적으로 MPLS와 함께)에서 서브넷 주소가 겹치는 클라이언트에 L3VPN 서비스를 제공하는 데 널리 사용됩니다.

그러나 Mikrotik의 VRF는 라우팅 테이블을 기반으로 구성되며 여러 가지 단점이 있습니다. 예를 들어 라우터의 로컬 IP 주소는 모든 VRF에서 사용할 수 있습니다. 자세한 내용을 읽을 수 있습니다. 링크.

vrf 구성 예:

/ip route vrf
add interfaces=ether1 routing-mark=vrf1
add interfaces=ether2 routing-mark=vrf2

/ip address
add address=192.168.100.1/24 interface=ether1 network=192.168.100.0
add address=192.168.200.1/24 interface=ether2 network=192.168.200.0

ether2에 연결된 장치에서 ping이 다른 vrf에서 라우터 주소로 이동하는 반면(이는 문제임) ping이 인터넷으로 이동하지 않는 것을 볼 수 있습니다.

인터넷에 액세스하려면 기본 테이블에 액세스하는 추가 경로를 등록해야 합니다(vrf 용어로 이를 경로 누출이라고 함).

/ip route
add distance=1 gateway=172.17.0.1@main routing-mark=vrf1
add distance=1 gateway=172.17.0.1%wlan1 routing-mark=vrf2

다음은 라우팅 테이블을 사용하는 두 가지 경로 누수 방법입니다. 172.17.0.1@main 인터페이스 이름 사용: 172.17.0.1%wlan1.

그리고 돌아오는 트래픽에 대한 표시를 설정합니다. [PREROUTING|Mangle]:

/ip firewall mangle
add chain=prerouting in-interface=ether1 action=mark-connection new-connection-mark=from-vrf1 passthrough=no
add chain=prerouting connection-mark=from-vrf1 routing-mark=!vrf1 action=mark-routing new-routing-mark=vrf1 passthrough=no 
add chain=prerouting in-interface=ether2 action=mark-connection new-connection-mark=from-vrf2 passthrough=no
add chain=prerouting connection-mark=from-vrf2 routing-mark=!vrf1 action=mark-routing new-routing-mark=vrf2 passthrough=no 

주소가 같은 서브넷
VRF 및 넷맵을 사용하여 동일한 라우터에서 동일한 주소 지정을 사용하여 서브넷에 대한 액세스 구성:

기본 구성:

/ip route vrf
add interfaces=ether1 routing-mark=vrf1
add interfaces=ether2 routing-mark=vrf2

/ip address
add address=192.168.100.1/24 interface=ether1 network=192.168.100.0
add address=192.168.100.1/24 interface=ether2 network=192.168.100.0
add address=192.168.0.1/24 interface=ether3 network=192.168.0.0

방화벽 규칙:

#Маркируем пакеты для отправки в правильную таблицу маршрутизации
/ip firewall mangle
add chain=prerouting dst-address=192.168.101.0/24 in-interface=ether3 action=mark-routing new-routing-mark=vrf1 passthrough=no
add chain=prerouting dst-address=192.168.102.0/24 in-interface=ether3 action=mark-routing new-routing-mark=vrf2 passthrough=no

#Средствами netmap заменяем адреса "эфимерных" подсетей на реальные подсети
/ip firewall nat
add chain=dstnat dst-address=192.168.101.0/24 in-interface=ether3 action=netmap to-addresses=192.168.100.0/24
add chain=dstnat dst-address=192.168.102.0/24 in-interface=ether3 action=netmap to-addresses=192.168.100.0/24

반환 트래픽에 대한 라우팅 규칙:

#Указание имени интерфейса тоже может считаться route leaking, но по сути тут создается аналог connected маршрута
/ip route
add distance=1 dst-address=192.168.0.0/24 gateway=ether3 routing-mark=vrf1
add distance=1 dst-address=192.168.0.0/24 gateway=ether3 routing-mark=vrf2

지정된 라우팅 테이블에 dhcp를 통해 받은 경로 추가
특정 라우팅 테이블에 동적 경로(예: dhcp 클라이언트에서)를 자동으로 추가해야 하는 경우 VRF가 유용할 수 있습니다.

vrf에 인터페이스 추가:

/ip route vrf
add interface=ether1 routing-mark=over-isp1

테이블을 통한 트래픽(발신 및 통과) 전송 규칙 ISP1 이상:

/ip firewall mangle
add chain=output out-interface=!br-lan action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=prerouting in-interface=br-lan dst-address-type=!local action=mark-routing new-routing-mark=over-isp1 passthrough=no

작동할 아웃바운드 라우팅을 위한 추가 가짜 경로:

/interface bridge
add name=bare

/ip route
add dst-address=0.0.0.0/0 gateway=bare

이 경로는 로컬 발신 패킷이 라우팅 결정(2)을 통과하기 전에만 필요합니다. [OUTPUT|Mangle] 라우팅 레이블을 얻으십시오. 기본 테이블의 0.0.0.0/0 이전에 라우터에 다른 활성 경로가 있으면 필요하지 않습니다.

쇠사슬 connected-in и dynamic-in в [Routing] -> [Filters]

경로 필터링(인바운드 및 아웃바운드)은 일반적으로 동적 라우팅 프로토콜과 함께 사용되는 도구이므로 패키지를 설치한 후에만 사용할 수 있습니다. 라우팅), 들어오는 필터에는 두 가지 흥미로운 체인이 있습니다.

• connected-in — 연결된 경로 필터링
• dynamic-in - PPP 및 DCHP에서 수신한 동적 경로 필터링

필터링을 사용하면 경로를 삭제할 수 있을 뿐만 아니라 거리, 라우팅 표시, 설명, 범위, 대상 범위 등 여러 옵션을 변경할 수 있습니다.

이것은 매우 정확한 도구이며 라우팅 필터 없이(스크립트는 제외) 작업을 수행할 수 있는 경우 라우팅 필터를 사용하지 말고 자신과 나중에 라우터를 구성할 사람들을 혼동하지 마십시오. 동적 라우팅의 맥락에서 라우팅 필터는 훨씬 더 자주 그리고 더 생산적으로 사용됩니다.

동적 경로에 대한 경로 표시 설정
홈 라우터의 예. 두 개의 VPN 연결이 구성되어 있고 그 안의 트래픽은 라우팅 테이블에 따라 래핑되어야 합니다. 동시에 인터페이스가 활성화될 때 경로가 자동으로 생성되기를 원합니다.

#При создании vpn подключений указываем создание default route и задаем дистанцию
/interface pptp-client
add connect-to=X.X.X.X add-default-route=yes default-route-distance=101 ...
add connect-to=Y.Y.Y.Y  add-default-route=yes default-route-distance=100 ...

#Фильтрами отправляем маршруты в определенные таблицы маршрутизации на основе подсети назначения и дистанции
/routing filter
add chain=dynamic-in distance=100 prefix=0.0.0.0/0 action=passthrough set-routing-mark=over-vpn1
add chain=dynamic-in distance=101 prefix=0.0.0.0/0 action=passthrough set-routing-mark=over-vpn2

이유는 모르겠지만 아마도 버그일 것입니다. 하지만 ppp 인터페이스에 대한 vrf를 생성하면 0.0.0.0/0에 대한 경로가 여전히 기본 테이블에 들어갈 것입니다. 그렇지 않으면 모든 것이 훨씬 쉬울 것입니다.

연결된 경로 비활성화
때로는 다음이 필요합니다.

/route filter
add chain=connected-in prefix=192.168.100.0/24 action=reject

디버깅 도구

RouterOS는 라우팅 디버깅을 위한 여러 도구를 제공합니다.

• [Tool]->[Tourch] - 인터페이스에서 패킷을 볼 수 있습니다.
• /ip route check - 패킷이 전송될 게이트웨이를 확인할 수 있습니다. 라우팅 테이블에서는 작동하지 않습니다.
• /ping routing-table=<name> и /tool traceroute routing-table=<name> - 지정된 라우팅 테이블을 사용하여 ping 및 추적
• action=log в [IP]->[Firewall] - 패킷 흐름을 따라 패킷의 경로를 추적할 수 있는 탁월한 도구입니다. 이 작업은 모든 체인과 테이블에서 사용할 수 있습니다.

출처 : habr.com