Reenvío de puertos para SQL Server y recurso compartido de archivos en redes LAN en cascada

Tengo una aplicación cliente que accede a SQLServer y archivos compartidos de Windows en un servidor, hasta ahora en una LAN privada que funciona perfectamente. El servidor tiene una dirección IP fija y SQLServer se está ejecutando en el puerto estático 2301. Ahora necesito conectar otra única. Cliente en la red en el lado WAN de mi enrutador .

192.168.178.X (a company network)
  +- MyNewClient - how to connect to MyServer SQLServer & share from here? 
  +- (other clients, not mine, but they are not a security concern)
  +- MyRouter (Asus RT-AC68U) WAN:192.168.178.22, LAN:192.168.17.1
       +- MyServer 192.168.17.11 (file share & SQL Server on port 2301)
       +- MyUsualClient1
       +- MyUsualClient2
       +- MyFixedIPDevice 192.168.17.77 (used by MyUsualClients)

La red de la compañía cambia cada semana (sitio diferente) pero me gustaría que todo lo que está debajo de MyRouter permanezca igual. Por eso me gustaría evitar desactivar NAT o usar un interruptor en lugar de MyRouter.

No soy un experto en redes, pero creo que la "magia" para que esto funcione es el reenvío de puertos en mi enrutador. El problema es que todas las preguntas / artículos que encontré en la web se centran en acceder a SQLServer o archivos a través de Internet, pero no en el simple caso de una "subred un nivel superior".

Encontré la tabla "VirtualServer / port forwarding" en mi enrutador Asus RT-AC68U y ingresé ServiceName = SQLServer, PortRange = 2301, LocalIP = 192.168.17.11, LocalPort = 2301, Protocol = TCP y luego trató de conectarse desde MyNewClient utilizando 192.168.178.22,2301 / SQLEXPRESS, pero eso da como resultado un "error relacionado con la red". ¿Debería esta configuración funcionar al menos en teoría? Si es así, ¿qué podría estar mal? La cadena de conexión 192.168.17.11,2301 / SQLEXPRESS funciona perfectamente desde MyUsualClients.

ACTUALIZACIÓN para SQL Server - SOLUCIONADO

¡Consiguió esto para trabajar! La configuración de reenvío de puertos desde arriba fue correcta. Sin embargo, el número de puerto aparentemente debe estar EN EL FINAL de la cadena de conexión cuando se conecta a través del reenvío de puertos: 192.168.17.11/SQLEXPRESS,2301

Lo mismo para compartir archivos de Windows / SMB? Escuché sobre el puerto 445, ¿es eso suficiente para una configuración "local"? Entonces, ¿cómo me conecto desde el lado del cliente / Explorador de Windows?

ACTUALIZACIÓN: Reenvío para SMB - la autenticación falla ??? Con \ 192.168.178.22 en el Explorador de archivos de Windows, parece que se establece una conexión con el reenvío de puertos utilizando el puerto 445 solamente. Pero cuando el servidor quiere credenciales, no acepta el mismo nombre de usuario / contraseña que usualmente (= de x.x.17.x) acepta. Así que parece que la autenticación no pasa correctamente a través del enrutador. ¿Alguna pista a alguien?

— Andreas Steidle
fuente

Compruebe las reglas de firewall de Windows en el servidor SQL. Los ámbitos de firewall de Windows a menudo están predeterminados para permitir el acceso solo desde la "subred local". Cuando ve MyNewClient tratando de acceder desde una subred diferente a la del servidor propio subred local (x.x.178.x en lugar de x.x.17.x) la rechazará. Por cierto, lo que quiere es una regla de firewall en su enrutador eso lo hace cumplir para su subred de interfaz WAN, que puede hacer fácilmente en Windows, pero no sé cómo hacerlo en un AC68U

— qasdfdsaq

Tengo esto funcionando ahora simplemente cambiando la composición de la cadena de conexión (ver actualización arriba). No toqué la configuración del firewall para el servidor SQL en el servidor. Sigue siendo el mismo que para la LAN local directa.

— Andreas Steidle