第55話で、イトはVPN connected lampだけを見てsend-allしなかった。
studio destinationだけをapproved tunnelへ入れ、gateway後の正しいhost cardへ届けた。
そのhost cardには、複数のservice slotがある。
target authority cardはhttps://stage.picoroute.test:8443/control。
イトは:8443の部分をfoldし、TCP 443 slotへrequest cardを置いた。
「httpsなら443。standard numberへ直せば届くはず」
response lampは200になった。
だがservice identity trayには、controlではなくhealth fixture cardが出ている。
remote controlを確定するまで、あと六十秒。
200でも、別portの別serviceかもしれない
イトはcontrol secret cardを443 responseへ重ねようとした。
ピコはcardへ触れず、foldされたauthority cardをtransparent holderへ戻した。
イト
443で200なら、HTTPSのcontrol serviceじゃないの？
ピコ
numberはresponseの中身やtarget identityまで決めないよ
イト
hostが同じでも、portが違えば別のservice？
ピコ
scheme・host・portを保って、transportとlistenerも分けて見よう
この話のhost、URL、TCP / UDP endpoint、listener、network policy、responseは、外のInternetから切り離した学習fixtureだ。
hostnameはreserved .test、port mappingとresponse cardは説明用で、live host、localhost、production admin endpoint、real credentialを使わない。
port scanning、firewall回避、TCP handshake byte順、QUIC内部、NAT mapping、operating-system固有socket optionは再現しない。
見るのは、target authority、transport、destination port、listening service、application responseの順序だ。
portは、transport endpointで振り分けるidentifier
RFC 9293 TCPはportを、endpointでconnectionをdemultiplexするために使うconnection identifierの一部と説明する。
TCP socketは、Internet addressとTCP portを結んだaddressだ。
一つのTCP connectionは、local socketとremote socketのpairで区別される。
clientが選ぶsource portと、server側serviceを指すdestination portは同じ役割ではない。
IP addressだけならhostまでは選べる。
transport protocolとdestination portまで見ると、そのhostのどのtransport endpointへ渡すかを選べる。
「建物とdoor」は入口の比喩にはなる。
でも実際のportは壁にある物理doorではなく、packet / segment headerとhost内のnetwork stackが使うnumberだ。
TCPとUDPは、同じnumberでも別の入口
RFC 6335 Service Name and Transport Protocol Port Number Registry Proceduresは、service nameとport numberのassignmentをtransport protocolごとに扱う。
TCP 8443とUDP 8443は、numberが同じでも同じendpointではない。
TCP listenerはTCP connection requestを待つ。
UDP applicationはdatagramを別に受け取る。
このfixtureではTCP 8443にcontrol serviceがLISTENし、UDP 8443にはlistenerがない。
TCP requestを送るべきtargetへ、numberだけ合わせたUDP datagramを置いても届かない。
port numberを読むときは、transport protocolを省かない。
LISTENしているprocessが、connectionを受け取る
RFC 9293のOPEN / LISTENでは、applicationがpassive OPENを行い、TCP endpointがincoming connection requestを待つLISTEN stateを作る。
number cardが存在するだけでserviceは起動しない。
service processが対象address / portへbindしてLISTENしているか。
network policyがそのtrafficを通すか。
connectionが成立したあと、application protocolが期待どおりか。
三つを分ける。
「つながらない」だけから、no listener、firewall drop、wrong address、wrong transport、service failureの一つへ即断しない。
このclosed fixtureは各条件を別lampで示す。
IANA assignmentは、protocolの手がかり
IANA Service Name and Transport Protocol Port Number Registryは、service name、port number、transport protocol、description、reference等を別fieldで公開する。
RFC 7605がまとめるrangeは三つだ。
System portsは0–1023。
User portsは1024–49151。
Dynamic / Private portsは49152–65535。
assignmentはinteroperabilityのための共通手がかりになる。
しかしnumberだけを見て、observed flowのserviceを常に断定できるわけではない。
applicationは別portで動かせる。
registered portにlistenerがいない場合もある。
unexpected applicationが同じportで待っている場合もある。
port numberはcontent inspection、authentication、authorization、vulnerability assessmentの代わりにならない。
httpとhttpsにはdefault portがある
RFC 9110のhttp URI Schemeでは、authorityがhost identifierとoptional portを含み、portがないときTCP 80がdefaultになる。
https URI Schemeでは、portがないときTCP 443がdefaultになる。
https://stage.picoroute.test/controlなら、このTCP fixtureでは443を試す。
https://stage.picoroute.test:8443/controlなら、explicit 8443がtarget authorityの一部だ。
clientの都合で443へfoldしない。
schemeがhttpsだから、どのportでも自動的にTLS成功するわけでもない。
indicated authorityとのsecure connectionを確立し、request targetを一致させる必要がある。
same hostでも、portが違えばoriginが違う
HTTP originはscheme、host、portで区別される。
host stringが同じでも、443と8443は同じoriginではない。
cookie、permission、same-origin policy等は、このorigin boundaryを使う場面がある。
今回のTCP 443ではhealth fixtureが待ち、TCP 8443ではcontrol fixtureが待つ。
どちらもresponse status 200を返せる。
statusが同じでも、authority、service identity、path、response schemaが違う。
「200が返った」をexact target確認の代わりにしない。
イトの前に、三つの選択肢が開く
remote control確定まで、あと三十秒。
A standard 443の200をcontrol responseとして採用する
connectionはできる。
しかしexplicit 8443を捨て、health fixtureへcontrol secretを渡す。
B 8443を通すため、listenerやpolicyを見ずに全network gateを開く
届く可能性は増える。
だが原因を分けず、不要なtransport / address scopeまで広げる。
C full target authorityを保ち、transport・listener・policy・response identityを順に照合する
scheme https、host stage.picoroute.test、explicit TCP port 8443、path /controlをtarget holderへ戻す。
TCP / UDPをseparate test railへ置き、expected service identityとresponse schemaまで比較する。
ピコは443 responseも8443 gateも操作しなかった。
「よくあるnumberじゃなく、targetに書かれたendpointへ送る」
イトはCを選んだ。
443 health responseからcontrol secretを外し、secret sentを0のまま保った。
自分でauthority cardの:8443 foldを開き、TCP holder、listener lamp、network-policy gate、control-response comparatorを一列へ戻した。
TCP 8443で、expected serviceが応答した
first traceはTCP 443。
listenerはhealth fixture。
TLS fixtureはcompleteし、HTTP statusは200。
しかしservice identity / response schema comparatorはmismatchを返した。
control acceptedは0。
second traceはTCP 8443。
network policyはtarget address + TCP + destination 8443にmatchした。
control fixtureはLISTEN。
TLS fixtureを完了し、path /controlへrequestを送る。
service identityとresponse schemaはexpected pairに一致した。
control acceptedは1。
same numberのUDPは、別結果になる
イトはUDP 8443 test datagramをseparate railへ置いた。
numberは同じ8443。
しかしfixtureにUDP listenerはない。
application deliveryは0。
次に、TCP 8443のdestination addressだけを別interface cardへ変えた。
network policyはmatchしない。
listenerへ到達したconnection requestは0。
workbenchへ四つのobservable resultが残った。
TCP 443はstatus 200だがservice mismatch、secret sent 0。
TCP 8443はexpected control response、accepted 1。
UDP 8443はapplication delivery 0。
wrong-address TCP 8443はlistener arrival 0。
remote control lampがgreenになった。
open / closedを、一つの永久labelにしない
portがopenかclosedかという言い方は、観察条件を省きやすい。
どのsourceから、どのdestination addressへ、どのtransportとportで、いつ試したか。
network policy、load balancer、container、service lifecycleで結果は変わる。
timeoutだけでfirewall、listener、route failureを断定しない。
authorizedな管理画面でservice status、bind scope、policy、application logsを確認する。
公開Internetへの無断scanや、閉じたgateの回避をtroubleshootingにしない。
不要なlistenerは止め、必要なscopeだけ通し、authentication / authorization / patchingを別に保つ。
port numberを変えるだけのsecurity by obscurityへ戻らない。
numberではなく、endpoint pairを残す
机には、六つの証拠が残った。
foldを開いたfull target authority。
separate TCP / UDP rails。
target address + transport + destination portのpolicy result。
TCP 8443のLISTEN lamp。
443のwrong-service 200 card。
8443のexpected control response pair。
portを物理的なroom numberやsecurity stampとして判断しない。IP address、transport protocol、destination portを分け、serviceがLISTENしているか、network policyを通るか、application responseがexact targetと一致するかを順に確かめる。http / httpsのdefault portは省略時のruleであり、explicit portを勝手に置き換えない。
「numberはserviceの名前そのものじゃない。packetを待つendpointを選ぶ一部だった」
イトは443の200 cardをaccepted trayへ移さず、TCP 8443とexpected control responseのpairだけをcurrent endpointへ残した。
control serviceは、次のasset request cardを返した。
同じassetには、近いcache nodeと遠いoriginの二つのshelfがある。
近いshelfにcopyがあれば、いつもそこから返してよいのだろうか。
次回：近ければ、いつも最新？
イトはnear cache shelfのasset cardをすぐresponse railへ置こうとした。
「originより近いなら、このcopyを毎回返せば速いよね」
ピコはcardを取らず、freshness clockとrequest condition holderを照らした。
次回、ピコルート第57話。
イトは、近いCDNなら必ず最新だと決めなかった｜cacheはいつoriginへ戻る？