So, I need a way to access Azure File Share by some VPN.
Yes, you could.
You could setup Windows Azure (Server 2012) as an SSTP and L2TP VPN Provider, your client PC connects to this VPN. I test it in my lab, it works for me. I could mount file share even though ISP block 445 Port. More information about how to setup Azure Windows as a VPN provider, please refer to the article.
Also, you could refer to this link which is the same with you.
My route table is configured to forward traffic to this IP address through my Virtual Private Gateway.
I don't think there is a possibility of this specific approach working, because...
I have the route table of my gateway subnet configured to forward traffic destined for the Microsoft.Sql regional endpoint public IP address to my proxy VM as if it were a virtual appliance.
This route table applies to traffic originating in that subnet, and that isn't where the traffic originates.
You need to tunnel this traffic between the two machines, not just route it, because the source and destination addresses that the network sees need to be the addresses of the individual VMs. That's part of what a tunnel does -- speaking generically and over-simplified, a tunnel wraps traffic from/to hosts with addresses a and b inside outer packets with from/to hosts with addresses x and y so that intermediate networks and gateways need not understand the "real" source and destination. Platform limitations probably make it impossible to simply route and forward this traffic as unencapsulated IP traffic with source and destination intact. (Or, without a proper tunnel, you'd need to NAT or double-NAT the traffic on the instances on both ends.)
There are a number of tunnel solutions operating at different layers, including openvpn and HAProxy, but the simplest -- for proof-of-concept purposes, at least -- is an SSH tunnel.
From the EC2 instance, assuming the database is using TCP port 1433:
$ ssh -L 1433:private-ip-of-db:1433 -i keyfile.pem username@ip-of-azure-vm
With this SSH connection open, there is also a socket listening to TCP port 1434 on the EC2 instance, and any connection to the private IP of the EC2 instance on that port will be tunneled across the open SSH connection and relayed to the database. The database will see the source IP of the connection as being the IP of the azure VM... so security settings need to allow traffic accordingly, and you wouldn't use the public IP address you discussed -- you'd use the EC2 instance's IP and control access via the EC2 security group, and you'd need to give the Azure VM access to the database. From the perspective of anything accessing the database, the EC2 instance appears to be the SQL Server.
SQL Server may offer one or more gotchas that requires more ports or a different port than I've shown above, but the general idea here is solid -- I've used this strategy for other protocols like RDP (TCP port 3389) and MySQL (TCP port 3306) but don't recall ever trying it with MSSQL.
Best Answer
You need to enable NSG Flow Logging. Check the article below:
https://docs.microsoft.com/en-us/azure/network-watcher/network-watcher-nsg-flow-logging-overview
This will give you:
I believe you need to create and associate the subnet (or individual NIC) to an NSG, even if it only has the default rules - which allows traffic in/out of VPN and within the VNet.
Once you have the logs configured, you can analyse it with Log Analytics (OMS)