Methu â chyrraedd IMDS na WireServer o VM Azure ar ôl i'r VPN gychwyn

Mae'r VM i fyny, mae'r cleient VPN yn dweud ei fod wedi cysylltu, ac ychydig funudau'n ddiweddarach mae asiant Azure yn dechrau adrodd ei fod yn afiach. Weithiau mae SSH yn goroesi ac nid yw Run Command o'r porth yn gwneud, sy'n anfon pobl i edrych ar yr asiant yn lle ar y tabl llwybrau. Newidiodd penderfyniadau anfon y gwestai pan gododd y tiwnel, a dwy gyfeiriad platfform yw'r dioddefwyr cyntaf fel arfer. Rwy'n trin hynny fel symptom llwybrydio cyn ei drin fel methiant asiant.

Mae'r symptom yn edrych fel asiant wedi torri

Cynigir y ddau gyfeiriad isod fel ateb, ac nid ydynt yr un gwasanaeth. Copïo /32 ar gyfer un ohonynt oherwydd iddo weithio i'r llall yw'r union ffordd y mae gwaith dros dro yn troi'n ffurfwedd barhaol nad oes neb yn meiddio ei dynnu.

Y drefn sy'n gweithio yw cadarnhau pa gyfeiriad mae'r alwad sy'n methu yn ei dargedu mewn gwirionedd, yna darllen sut mae'r gwestai yn ei ddatrys. Unrhyw beth arall yw dyfalu gyda chamau ychwanegol a ffenestr newid hirach.

Nid yw 168.63.129.16 yn gyrchfan gyhoeddus

168.63.129.16 yw cyfeiriad platfform rhithwir arbennig Azure, ac un o'i rolau yw WireServer, y mae asiant y VM yn ei ddefnyddio i siarad â'r ffabrig. Mae Microsoft yn dogfennu bod rhaid i draffig asiant i borthladdoedd TCP 80 a 32526 aros ar gael. Nid yw'n westeiwr rhyngrwyd cyffredin, ac nid yw'n rhywbeth y dylai VPN tiwnel llawn ei gario i allanfa bell. Dyna pam y gall tiwnel sy'n edrych yn iach newynu'r asiant o hyd.

Mae dogfennaeth cyfeiriad y platfform hefyd yn dweud nad yw'r cyfeiriad hwn yn ddarostyngedig i lwybrau a ddiffinnir gan ddefnyddiwr, sy'n briodwedd o ffabrig Azure yn hytrach na phroblem am eich gwestai. Gall rheol wal dân leol neu bolisi llwybrydio'r cleient VPN ei hun dorri'r llwybr o hyd, ac nid yw'r un ohonynt yn byw yn nhabl llwybrau'r VNet.

Os yr asiant sy'n adrodd trafferth, gwiriwch gyflwr y gwasanaeth a'r llwybr i'r cyfeiriad hwnnw cyn ailosod unrhyw beth.

Mae gan 169.254.169.254 ei reolau ei hun

169.254.169.254 yw'r cyfeiriad link-local ar gyfer Azure Instance Metadata Service. Mae gan geisiadau iddo ofynion eu hunain: y NIC cynradd a'r IP cynradd, ffurfwedd DHCP sy'n cefnogi'r cyfeiriad, a chylchdroi unrhyw brocsi HTTP. Nid anfon nhw drwy allanfa VPN bell neu borth rhyngrwyd mympwyol yw'r model mynediad y mae Microsoft yn ei ddisgrifio.

Mae'r cymal procsi hwnnw'n dal pobl sydd wedi trwsio'r llwybr ac yn dal i weld methiannau. Gall procsi HTTP yn y gwestai dorri IMDS tra bod ip route get yn dychwelyd yn union y rhyngwyneb rydych yn ei ddisgwyl, felly gwiriwch eithriadau procsi yn ogystal â'r llwybrau.

Peidiwch â phosio ymatebion metadata i docyn cymorth wrth ddadfygio hyn. Gallant gario cymwysterau a manylion enghraifft sy'n goroesi'r digwyddiad.

Darllenwch lwybrydio polisi'r gwestai, nid y prif dabl yn unig

Ar westai Linux mae tair gorchymyn darllen yn unig yn gwahanu'r haenau: ip -4 rule show ar gyfer y rheolau polisi, yna ip -4 route get 168.63.129.16 a ip -4 route get 169.254.169.254 ar gyfer y penderfyniadau y mae'r cnewyllyn yn eu gwneud mewn gwirionedd. Rhedwch nhw cyn ac ar ôl i'r VPN gysylltu. Y gwahaniaeth rhwng y ddau allbwn hynny yw eich set newid, ac mae'n fwy defnyddiol nag unrhyw ddyfaliad am yr hyn a wnaeth y cleient.

Gall cleient VPN sy'n gosod rheolau polisi adael y prif dabl heb ei gyffwrdd a dal i ailgyfeirio'r chwiliadau hynny. Dyna pam y mae ateb prif dabl yn unig yn ymddangos yn gweithio ar un westeiwr ac yn gwneud dim ar y nesaf. Mae gwesteiwyr â sawl NIC yn ychwanegu'r un broblem o'r cyfeiriad arall, oherwydd mae'r ateb yn dibynnu ar ba NIC a chyfeiriad ffynhonnell y mae'r rheol yn ei ddewis.

Gwrthwynebwch y rysáit sy'n ychwanegu'r ddau lwybr /32 drwy'r hen borth. Mae llwybr platfform link-local a naid nesaf WAN cyffredinol yn wrthrychau gwahanol, ac mae eithriad blanced yn cuddio'r gwrthdaro polisi go iawn.

Cadwch weinyddiaeth ac adferiad ar wahân

Gall diofyn tiwnel llawn ddal eich ateb SSH neu RDP hefyd, ond mae'n targedu cyfeiriad arsylwedig y gweinyddwr yn hytrach nag unrhyw benelin platfform. Diagnoswch ef o'i bâr cais-ac-ateb ei hun, a chadwch sianel adfer annibynnol fel y consol cyfresol cyn newid polisi VPN. Os yw defnydd yn ailgychwyn y VM ac mae'r asiant yn adrodd ei fod yn afiach, archwiliwch y weithred a gofnodwyd a'r gwasanaeth cyfrifol yn lle tybio mai'r newid llwybr achosodd yr ailgychwyn.

Yna gwiriwch y tri ffrwd ar wahân: yr adnodd preifat roeddech ei eisiau mewn gwirionedd, y cyfathrebu asiant a phlatfform a gefnogir, a'r llwybr gweinyddol. Nid yw adfer un ohonynt yn brawf bod y ddau arall wedi goroesi.

Ysgrifennwch yr eithriad a gymeradwywyd o dan berchennog rhwydwaith y gwestai a ffurfwedd y VPN, gan gynnwys beth sy'n digwydd ar ailgysylltu ac ailgychwyn. Nid UDR Azure yw tabl llwybrau'r gwestai, ac ni fydd eu golygu yn trwsio rheol polisi leol.