There is no method to disable standard (expected) character set conversion that happens in a database link. Therefore, if one database stores your Cyrillic data incorrectly (e.g. in WE8DEC) and the other one correctly (e.g. in CL8MSWIN1251), then the conversion from WE8DEC to CL8MSWIN1251 will happen and will corrupt the data. To avoid this you can either protect the data by moving it as RAW or you can fix the character set of the original database.
Protecting data by casting it to RAW requires an intermediate view, as in your example, because otherwise you have no control over where the data type casting happens for a query. It may happen either in the source database, which is what we need, or in the target database, which would be too late, depending on the decisions made by the SQL engine.
You can change the (incorrect) character set of the original database using the CSREPAIR functionality of the DMU utility (
https://docs.oracle.com/cd/E89575_01/DUMAG/ch5_advanced_topics.htm#GUID-71456178-0A83-478B-BE03-272B73303FAC ) .
Another, non-trivial solution would be to use Golden Gate instead of DB link. In GG, you could override the source database character set to avoid the problematic conversion. Of course, GG replication and DB links are quite different approaches to data transfer.