O que você está tentando fazer, se eu estou entendendo corretamente, é efetivamente uma forma de roteamento de políticas com algum NAT envolvido. Parece que você está apenas procurando criar um alias para algum host fora de uma sub-rede roteada específica que esteja nessa sub-rede.
Você pode criar regras DNAT sem o SNAT (ou mascaramento) correspondente. A razão pela qual isso não é feito é simplesmente que a maioria dos NAT é projetada para hackear um problema de conectividade em que os endereços no "interior" do NAT não seriam passíveis de serem roteados do "fora". Se, de fato, o host 192.168.1.1 tiver uma rota de volta para 192.168.2.0/24 ou seja o que for, você pode, de fato, apenas configurar uma regra DNAT, se bem me lembro:
iptables -t nat -A PREROUTING -s 192.168.2.0/24 -d 192.168.2.1 -j DNAT --to 192.168.1.1
Agora, pare por um momento e não faça isso ainda.
Isso funciona quando 192.168.2.1 é um endereço de destino (e cria uma peculiaridade em que o endereço que responde ao tráfego é diferente do destino original). Eu não acho que é isso que você quer fazer, a partir de sua descrição, embora eu sinceramente não tenha certeza. Fazer o DNAT não ajudará se o host 192.168.2.1 funcionar como um roteador e não como um destino. Se é para funcionar como um roteador, o NAT (ou PAT) não ajudará em nada.
Parece que você tem tráfego de VPN que acaba sendo ligado a essa sub-rede 192.168.2.0/24 se estou lendo corretamente e preenchendo os espaços em branco como estão, e precisa sair para o mundo amplo ou algum subconjunto dele através deste gateway 192.168.1.1. Nesse caso, a coisa a fazer é simplesmente atribuir 192.168.2.1/24 (que eu suponho que você tenha definido como o gateway padrão nos clientes VPN) para o seu roteador , verifique se o encaminhamento está habilitado, e você é bom de ir - os clientes VPN não precisam se preocupar com o próximo salto sendo 192.168.1.1 como seu gateway original não-VPN (gateway doméstico); eles são completamente inconscientes disso enquanto o pacote transita. ISPs usam esse tipo de esquema com endereços RFC1918 o tempo todo para evitar desperdício de endereços roteáveis acidentalmente; não é um requisito que todos os roteadores ao longo do caminho tenham endereços exclusivos (embora, quando isso acontece, a solução de problemas seja muito mais fácil). O truque aqui é que os pontos de extremidade de uma conexão TCP não precisam saber nada além do endereço IP do próximo salto.
Se você já estiver fazendo isso e tiver problemas, verifique o caminho de retorno. É provável que seu gateway em 192.168.1.1 não esteja fazendo NAT para esses endereços ao enviar seu tráfego para fora de seu NAT (que ele ainda verá como 192.168.2.0/24), esteja fazendo o firewall deles ou não tenha uma rota apropriada de volta para 192.168.2.0/24.
Se eu entendi mal sua intenção em ambos os aspectos, há uma terceira coisa que pode ajudá-lo. A única maneira que você pode especificar um gateway no iptables é com o alvo TEE, que clona o pacote e encaminha o clone inalterado para algum host arbitrário. Você precisaria lidar com o pacote não-clonado de alguma forma, no entanto. Esse alvo pode ser adicionado na cadeia de PREROUTING do mangle:
iptables -t mangle -A PREROUTING -s 192.168.2.0/24 -j TEE --gateway 192.168.1.1
Isso é uma coisa estranha de se fazer; isso é projetado para registrar o tráfego, não roteando-o. Você poderia descartar o pacote original em algum estágio posterior do iptables, suponho, embora isso seja uma bagunça e eu realmente não o recomende.
Como um ponto aleatório, você pode adicionar endereços IP adicionais a interfaces usando o comando ip addr add . Não use net-tools (ifconfig); é antigo e falta muitos recursos e só vai lhe dar dores de cabeça a longo prazo.