第54話で、イトは文字を適当に混ぜて暗号化にしなかった。
plaintext、secret key、nonce、contextを分け、correct conditionでだけ元へ戻るciphertextを作った。
そのciphertext cardが、今度は大きなtunnel machineの入口へ届く。
イトがapproved lab profileのconnect switchを入れると、lampがgreenになった。
机には、studio control packetとpublic knowledge packetの二枚がある。
remote stage controlまで、あと六十秒。
「VPN connectedなら、二枚ともInternetのどこへ送っても安全だよね」
イトはsend-all leverへ手を掛けた。
connected lampは、packetのrouteを答えない
ピコはleverへ触れず、二枚のdestination cardをtransparent route classifierへ立てた。
イト
tunnelがgreenなのに、まだ何を確かめるの？
ピコ
そのpacketがprofileの対象か、どのendpointまでを通るかだよ
イト
VPNをONにすれば、全部同じtunnelじゃないの？
ピコ
configurationによって、protectするtrafficと別routeへ出すtrafficが分かれるよ
この話のdevice、profile、gateway、route table、packet、destinationは、外のInternetから切り離した学習fixtureだ。
hostnameはreserved .test、address / credential / keyは説明用tokenで、live organization networkやpublic VPNへ接続しない。
specific VPN product、geo-block回避、匿名性、広告 / tracking抑制、DNS leak、kill switch、IPsecの暗号数学やpacket byte順は再現しない。
見るのは、packetのdestination、policy decision、tunnel endpoints、gateway後のrouteだ。
VPNは、一種類のproduct名ではない
VPNは、離れたhostやnetworkの間へprivateなcommunication boundaryを作る考え方だ。
remote userのdeviceからorganization gatewayへ接続する構成がある。
二つのnetwork gatewayを結ぶsite-to-site構成もある。
host同士を結ぶ構成もある。
使うprotocol、protectする層、authentication、route、endpoint、管理者は同じとは限らない。
NIST SP 800-113 Guide to SSL VPNsは一例として、remote userがorganization resourceへsecure remote accessするSSL VPNの計画・実装・構成を扱う。
「VPN serverという一台を通れば、Internet全部が同じ性質になる」と一つの図だけで固定しない。
この回ではpolicy境界を見やすくするため、IPsec tunnel-mode fixtureを使う。
policyは、PROTECT・BYPASS・DISCARDを分ける
RFC 4301 IPsec Security Architectureでは、IPsec boundaryを通るpacketをSecurity Policy Databaseとselectorで判断する。
outbound / inbound trafficには、大きく三つの処理がある。
PROTECTは、指定したIPsec security serviceを適用する。
BYPASSは、IPsec protectionを適用せずboundaryを通す。
DISCARDは、通さない。
green connected lampは、tunnelに使えるSecurity Associationがあることの手がかりにはなる。
しかし目の前のpacketがPROTECT entryへmatchした結果までは、一色のlampだけで分からない。
destination、protocol、場合によってはport等のselectorと、ordered policyを照合する。
traffic selectorは、tunnelへ入る範囲を決める
RFC 7296 IKEv2のTraffic Selectorsは、IP address range、port range、IP protocol IDで、Child SAが運ぶtrafficの範囲を表す。
これはIPsec / IKEv2 fixtureの具体例だ。
すべてのVPN製品が同じscreenや同じselector表現を持つという意味ではない。
このapproved lab profileは、studio network destinationだけをPROTECTする。
public knowledge destinationはそのselectorにmatchせず、local default routeへBYPASSする。
unknown management destinationはDISCARDする。
connection stateとpacket dispositionを別に観察する。
tunnel modeには、innerとouterのdestinationがある
RFC 4301のtunnel modeでは、outer IP headerがIPsec processingのsource / destinationを示し、inner IP headerがtunnel内packetのsource / ultimate destinationを示す。
deviceは、studio serviceへ向かうinner packetをprotectし、lab VPN gatewayへ向かうouter packetで包む。
networkはouter destinationを使ってgatewayまで運ぶ。
gatewayはIPsec processingを行い、policyを通ったinner packetをstudio側routeへ渡す。
tunnelが終わっても、inner packetのdestinationまで消えるわけではない。
gateway後のnetworkとfinal serviceには、別のrouting、access control、application protocolがある。
「tunnelへ入った」と「目的のserviceが正しい」を同じ判定にしない。
split tunnelとfull tunnelは、routeの範囲が違う
NISTのsplit tunneling glossaryは、organization-specific trafficをSSL VPN tunnelへ通し、ほかのtrafficをremote userのdefault gatewayへ通す方法を示す。
これがsplit tunnelの一例だ。
対してfull-tunnel configurationでは、より広いtraffic、場合によってはdefault routeをorganization / provider gatewayへ向ける。
どちらも「名前だけで常に安全」「常に危険」とは決まらない。
organization policy、監視 / filtering要件、利用network、performance、privacy、可用性、incident responseを含めて設計される。
利用者がrelease直前にapproved profileを勝手にfull tunnelへ変えない。
イトの前に、三つの選択肢が開く
remote stage controlまで、あと三十秒。
A connected lampだけを見て、二枚ともsend-allする
早い。
しかしどちらがtunnelへ入り、どこで出るかを確認しない。
B unapprovedなroute-all switchを入れ、全部をgatewayへ強制する
tunnel trafficは増える。
だがapproved policyを変え、public destinationまで別のtrust boundaryへ移す。
C approved profileを保ち、destinationごとにactual policy resultとrouteをtraceする
studio control packet、public knowledge packet、unknown management packetをseparate test trayへ置く。
それぞれのPROTECT / BYPASS / DISCARDと、tunnel endpoints、gateway後のnext routeを観察してから必要なpacketだけ送る。
ピコはroute-all switchにもclassifierにも触れなかった。
「green lampじゃなく、このdestinationのrouteを確かめる」
イトはCを選んだ。
send-all leverへclosed coverを戻し、unapproved route-all switchもoffのままにした。
自分でstudio destination cardをclassifierへ差し、public destination、unknown destinationの順にdry traceを開始した。
studio packetだけが、tunnelへ入った
studio destinationはapproved selectorにmatchした。
policy resultはPROTECT。
inner studio packetがprotected tunnel packetへ包まれ、outer destinationはlab gatewayになった。
gatewayでinbound policyを通り、inner packetはstudio routeへ出た。
イトはそこで初めてliveではないcontrol fixture packetを送った。
stage responseはaccepted。
public packetは、BYPASS routeへ出た
public knowledge destinationはstudio selectorにmatchしなかった。
policy resultはBYPASS。
VPN tunnelを通ったpacketは0。
それ自体は、直ちに失敗や攻撃を意味しない。
approved profileが、そのtrafficをlocal default routeへ出す設計だったという結果だ。
イトはsecret cardを載せず、known destinationとHTTPS validationを別に確認したtest requestだけを送った。
unknown management destinationはDISCARD。
secret sentは0。
selectorに合わないinbound packetは、通さない
イトはwrong inner destinationを持つtest packetを、studio tunnelのinbound sideへ置いた。
Security Associationが存在しても、received packetのheader fieldsがそのSAのselectorと一致するとは限らない。
RFC 4301のinbound processingは、SA経由で受けたpacketがinbound selectorsと整合しなければdiscardする境界を定める。
fixtureはselector mismatchを返した。
studio service deliveryは0。
workbenchへ四つのobservable resultが残った。
studio destinationはPROTECT、gateway後にaccepted。
public destinationはBYPASS、VPN tunnel packet 0。
unknown destinationはDISCARD、secret sent 0。
wrong-selector inboundはservice delivery 0。
remote stage control lampがgreenになった。
VPNとHTTPSは、重なるが同じではない
VPN tunnelは、profileが選んだtrafficをtunnel endpoints間でprotectする。
HTTPSは、browser / clientが選んだhttps originとのHTTP communicationをTLSでprotectする。
public Web accessでは、VPN内にHTTPS trafficが入ることも、split policyでVPNをbypassしたHTTPS trafficになることもある。
VPN gatewayでtunnel protectionが終わっても、HTTPSのTLS connectionがoriginまで続く構成がある。
一方、VPN connectedでも偽のdestinationを本物へ変えない。
HTTPSでもdevice malware、account permission、application内のdata利用目的までは一括保証しない。
VPN、HTTPS、destination identity、authentication、authorizationを別のlampで見る。
gatewayは、trust boundaryの一部になる
full tunnelにすれば、より広いtrafficがorganization / provider gatewayを通る。
split tunnelなら、指定trafficとlocal routeが分かれる。
どちらでも、誰がprofileとgatewayを管理し、何をrouteし、どのpolicyで記録 / filteringし、障害時にどう止めるかは選定条件になる。
ただしgatewayが見られる内容は、inner application encryption等の構成で変わる。
「VPN providerは必ず全部読める」とも、「VPNなら誰にも何も見えない」とも一律化しない。
organization-approved serviceならadmin policyとsupport routeを確認する。
consumer serviceならoperator、privacy / logging policy、client distribution、update、termination条件を確認する。
freeというlabelやreview順位だけでtrafficのtrust boundaryを渡さない。
tunnelを、route tableの外へ広げない
机には、六つの証拠が残った。
green connected lamp。
approved profileとthree policy results。
studio packetを包むinner / outer pair。
gateway後のstudio route。
VPNを通らないpublic BYPASS trace。
unknown / wrong-selectorのDISCARD tray。
VPNをconnected labelだけで判断しない。configuration / policyとdestinationのselector matchを確かめ、PROTECT / BYPASS / DISCARDを分ける。tunnel endpoints、gateway後、final destinationを一続きの安全stampにせず、HTTPS、identity、authentication、authorizationを別に確認する。split / full tunnelはapproved policyとactual routeで判断する。
「tunnelはInternetを消すんじゃない。選んだpacketに、別の区間を作るものだった」
イトはstudio packetのcyan tunnel railだけをcurrent routeへ残し、public railとdiscard gateを隠さなかった。
gateway後のinner packetは、正しいhost cardへ届いた。
だが同じhost cardには、形の違うservice doorがいくつもある。
addressが合ったあと、packetはどの入口を選ぶのだろう。
次回：同じhostの、どの入口へ渡す？
イトはhost cardへ届いたpacketを、いちばん大きなdoorへ置こうとした。
「addressが同じなら、どのdoorでも同じserviceへ届く？」
ピコはdoorを開けず、packet headerのsmall number holderだけを照らした。
次回、ピコルート第56話。
イトは、port numberを建物の部屋番号だと決めなかった｜serviceはどこで待つ？