If you can access the instances at the IP layer then you will always be able to connect using either SQL Authentication (if enabled) and even Windows Authentication using the runas /netonly trick. Say you are in the domain 'foo' and you want to connect to an instance in the domain 'bar', and there is no trust relationship between 'foo' and 'bar'. Since the instance in the 'bar' domain can only authenticate an user in the 'bar' domain you would normally have to be running as 'bar\user' to connect to this instance, but of course your host in 'foo' will not let you run as 'bar\user'. runas /netonly to the rescue: start your client process (eg. SSMS) using the /netonly option:
runas /netonly bar\user "c:\program files\...\ssms.exe"
When launched this way (you'll be prompted for bar\user password) the SSMS will authenticate to any resource over the network as 'bar\user' and you'll succeed to connect to the 'bar' based SQL Server instance. This trick works with local accounts as well, so instead of bar\user you can use <machinename>\Administrator to appear to that machine as the local administrator.
If the destination server is unreachable at the IP layer then you have no option, you must make it reachable, either by VPN, or by DirectAccess, even a netcat bridge can work with the /netonly trick.
