Is it possible to have change tracking ONLY on a replication server, not original?
if you can consider not only SQL Server options take a look at GoldenGate.
We have a project to deliver content (ongoing changes) + change tracking from Oracle to Greenplum database. GoldenGate supports SQL Server as well, so idea and even parameter files for the processes are the same.
On a high-level it looks like:


capture transactions record info on source system (EXTRACT process)
deliver to the target independent system (it can be SQL Server, or whatever supported by GoldenGate) - (PUMP process)
apply changes not as DML operations but as full records with additional attributes like "operation name", "commit timestamp" and else you can get from trail files generated on source (REPLICAT process).
You can record only PK values or full row values into change tracking. It's just a matter of design.


EXTRACT and PUMP processes are quite simple. The most interesting here is REPLICAT config:

REPLICAT &lt;PROCESS NAME&gt;
INCLUDE ./dirprm/DBLOGIN.inc
INCLUDE ./dirprm/REPORT.inc
MACRO #map_history
PARAMS (#table)
BEGIN
IGNORETRUNCATES
MAP &lt;SRC_SCHEMA&gt;.#table, TARGET &lt;TGT_SCHEMA&gt;.#table,
  INSERTALLRECORDS,
  COLMAP (USEDEFAULTS,
    OPERATION = @GETENV('GGHEADER', 'OPTYPE'),
    CSN = @GETENV('TRANSACTION', 'CSN'),
    RSN = @COMPUTE(@COMPUTE(@NUMSTR(@GETENV('RECORD', 'FILESEQNO')) * 100000000000) + @NUMSTR(@GETENV('RECORD', 'FILERBA'))),
    CSN_TIMESTAMP = @GETENV('GGHEADER', 'COMMITTIMESTAMP')
  );
END;
INCLUDE ./dirprm/DML_REPLICAT.inc
#map_history(&lt;TABLE1&gt;)
#map_history(&lt;TABLE2&gt;)
...
#map_history(&lt;TABLEN&gt;)


This works well for hundreds of millions operations per day (including LOBs).

Hope it helps to get an idea of the one of the potential solution.