本投稿は 2018/4 時点の Public Preview の内容です。
一般提供開始時には変更されている可能性があります。
今回の内容は公式のドキュメントから外れて、自分で調査した際の内容のまとめです。
# リソース構成はポータルから見たものですので、ドキュメントから外れていないと思いますが。
SQL Database Managed Instance (MI) は単一の Azure のリソースではなく、複数の Azure のリソースで構成されているサービスとなるようです。
デプロイをすると次のようなリソースで構成が行われます。
デプロイを実施すると、選択したサブネット内に「仮想クラスター」が作成されます。
MI はこのクラスター内に作成されます。
仮想クラスター自体は、サブネットに一つとなっているようで、複数の MI をサブネット内にデプロイした場合は、同一の仮想クラスター内に MI が配置されます。
MI 上に作成したデータベースは「Managed Database」というリソースとなるようで、データベースを作成するたびにこのリソースが追加されていくことになります。
接続時ですが、MI に直接接続をしているのではなく、ソフトウェアロードバランサーのようなものがフロントに構築されるようで、そこを介して MI に接続をするという構成となるようです。
MI はデプロイすると「database.windows.net」のサフィックスを持つサーバー名が自動的に設定され、次のような名前解決となります。
設定されている接続に使用する名称は、VNET 内だけでなく、SQL Database のように外部の DNS からも名前解決ができるようになっています。
返ってくる IP は、VNET 内の Private IP が設定された、CNAME のレコードとなります。
MI に接続する際には、この CNAME の先のサーバー (今回であれば、「tr26.japaneast1-a.worker.vnet.database.windows.net」)を介して接続が行われているようです。
VNET 内からこの CNAME の先に直接接続を使用としても、接続をすることはできないようです。
直接の接続を使用としても次のエラーとなり接続することができません。
Sqlcmd: エラー: Microsoft ODBC Driver 13 for SQL Server: Cannot open server "tr26.japaneast1-a.worker.vnet.database.windows.net" requested by the login. The login failed.。
接続先のサーバー名の情報がないと、その先の MI にリダイレクトができないようですね。
この辺は、SQL Database の Azure SQL Database 接続アーキテクチャ と、似たような考えなのかもしれません。
接続時のユーザー名を「ログイン名@MI サーバー名」として指定することで、該当の MI のインスタンスにリダイレクトはされるようなのですが、SQL Database のように @ 以降をサーバー名として使用するというロジックが無いようで、現状は接続をすることができないようです。
(SQL Server のログインとして、「ログイン名@MI サーバー名」というログイン名を作ってしまえば接続できますが)
今回の環境では、「tr26.japaneast1-a.worker.vnet.database.windows.net」がアクセス時のロードバランサーとなっていますが、かならず、これを介さないと接続ができないかというと、構成を把握することで、ロードバランサーを介さなくても接続はできるようです。
今回の構成であれば「172.23.1.4,11000」という指定で接続をすることができます。 
ここからは、情報を確認したうえでの想像ではあるのですが、Azure のリソースの「仮想クラスター」は、MI の DM 上は「fabric」という概念で管理されているのではないでしょうか。
fabric を構成しているサーバーについては、次のクエリで取得することができます。
SELECT * FROM sys.dm_hadr_fabric_nodes ORDER BY node_name
このクエリで取得できる情報は、複数の MI で同一となっており、5 個の IP が専有された形となっていますので、 Azure SQL Database マネージ インスタンスの VNet を構成する の次の記載に該当しているものなのではないでしょうか。
Azure では、独自のニーズに応じて、サブネット内で 5 個の IP アドレスを使用します。
今回は「172.23.1.4」の「TCP 11000」に接続をしていますが、この IP とポートを使用するという判断については、次のクエリで取得した情報に基づいています。
この構成の情報ですが次のクエリを実行することで取得できます。
SELECT r.node_name, ps.primary_replica_server_name, n.ip_address_or_FQDN, d.name, r.replica_role_desc, ps.service_type_desc, r.replica_address, ps.service_uri, ps.database_name FROM sys.dm_hadr_fabric_replicas r LEFT JOIN sys.dm_hadr_fabric_partition_states ps ON r.partition_id = ps.partition_id LEFT JOIN sys.databases d ON ps.service_name = d.physical_database_name LEFT JOIN sys.dm_hadr_fabric_nodes n ON r.node_name = n.node_name WHERE name IS NOT NULL
このクエリを実行すると、次のような情報が取得できます。
DB 単位に、fabric で管理されている情報が登録されているようで、DB は特定の fabric node に関連付いているようです。
この情報の中の「replica_address」がどのポートで TDS のプロトコルを受けるようになっているかの情報が含まれているものとなるようです。
(ERRORLOG から判断することもできますが)
DB0\DB.0,tds:20049,dac:20048,hadr:20044,na:12000,itds:13000,px:20046,gt:15000,
pgtds:-1,mysql:-1,sbs:17000,dtds:11000,ddac:11001,dhadr:11002,dgt:20076,
dsbs:20078,va:20080,dc:20074
「replica_address」には、上記のような情報が含まれているようで、「dtds」が TDS の TCP ポート / 「ddac」が「専用管理者接続」の TCP ポートとなるようです。
(今回は、11000 / 11001 が使われていますが、このポートから始まるのかは不明です。
これらの情報を元にすると、fabric の IP を使用して、直接接続をすることができるようです。
(Preview の状態かつ、ドキュメントに記載されていないので、いつまで接続できるかの保証はありませんが)
これを利用すると、ポートフォワードさせることで接続をさせるということもできるようです。
Windows の場合であれば、portproxy を使用することで、特定のポートのアクセスをフォワードすることができますので、次のような設定を投入します。
netsh interface portproxy add v4tov4 listenport=60001 listenaddress=172.23.2.4 connectport=11000 connectaddress=172.23.1.4
これにより、Windows の TCP 60001 への接続を MI の fabric への接続にリダイレクトすることができますので、次のような構成を組むこともできます。
Port Fowarder の TCP 60001 を Fabric の 11000 に転送して、MI に接続するという構成ですが、Port Forwader に Public IP 経由でアクセスすることができる (VM に Public IP を設定 / Public IP を持つ LB の背後に置く等) ようにしておくと、VNET 外からの環境でも Public IP を経由してアクセスすることが構成上は可能でした。
(GA したら、こういうイレギュラーな接続閉じられそうな気もしますが)
MI には、「sys.dm_hadr_fabric」で始まる DMV が多数あり、この内容を見ると、内部的な構造が見えてきて、今回のような少し特殊な接続方法を思い浮かべるための足掛かりになったりもします。
MI は、今までとは違う SQL Server の構成ですので色々と面白い情報が取れるかもしれないですね。