Azureko VMak ezin du IMDS edo WireServer iritsi VPN-a abiarazi ondoren

VM-a martxan dago, VPN bezeroak konektatuta dagoela dio, eta minutu batzuk geroago Azure agenteak osasungaitza dela jakinarazten hasiko da. Batzuetan SSH bizirik dirau eta ataritik abiatutako Run Command ez, eta horrek jendea agentera bidaltzen du bideratze-taularen ordez. Gonbidatuaren beraren birbidaltze-erabakiak aldatu ziren tunela igo zenean, eta bi plataforma-helbide izaten dira lehen biktimak. Bideratze-sintoma gisa tratatzen dut, agentearen hutsegite gisa tratatu aurretik.

Sintomak agente hautsia ematen du

Beheko bi helbideak konponbide gisa proposatzen dira, eta ez dira zerbitzu bera. Bati /32 bat kopiatzea bestearentzat funtzionatu zuelako da aldi baterako irtenbidea inork kentzera ausartzen ez den konfigurazio iraunkor bihurtzeko modua.

Funtzionatzen duen ordena hau da: lehenik egiaztatu huts egiten duen deialdiak zein helbide duen benetan helburu, eta gero irakurri gonbidatuak nola ebazten duen. Gainerako guztia asmatzea da, urrats gehiagorekin eta aldaketa-leiho luzeagoarekin.

168.63.129.16 ez da helburu publiko bat

168.63.129.16 Azure plataformaren helbide birtual berezia da, eta haren eginkizunetako bat WireServer da, VM agenteak oihularekin hitz egiteko erabiltzen duena. Microsoftek dokumentatzen du agentearen trafikoak TCP 80 eta 32526 portuetara eskuragarri egon behar duela. Ez da interneteko ostalari arrunta, eta ez da tunel osoko VPN batek urruneko irteera batera eraman beharko lukeen zerbait. Horregatik, osasuntsu dirudien tunelek agentea gosez utz dezake oraindik.

Plataformaren helbidearen dokumentazioak ere dio helbide hori ez dagoela erabiltzaileak definitutako bideen mende, eta hori Azure oihularen propietatea da, ez zure gonbidatuari buruzko promesa. Tokiko suebaki-arau batek edo VPN bezeroaren beraren bideratze-politikak oraindik hautsi dezake bidea, eta bietako bat ere ez da VNet-en bideratze-taulan bizi.

Agentea bada arazoa jakinarazten duena, egiaztatu zerbitzuaren egoera eta helbide horretarako bidea, ezer berriz instalatu aurretik.

169.254.169.254-k bere arauak ditu

169.254.169.254 Azure Instance Metadata Service zerbitzuaren link-local helbidea da. Haren aurreko eskaerek baldintza propioak dituzte: NIC nagusia eta IP nagusia, helbidea onartzen duen DHCP konfigurazioa, eta edozein HTTP proxy saihestea. Hauek urruneko VPN irteera batetik edo interneteko pasabide arbitrario batetik bidaltzea ez da Microsoftek deskribatzen duen sarbide-eredua.

Proxy klausula horrek bidea konpondu eta huts egiteak oraindik ikusten dituen jendea harrapatzen du. Gonbidatuko HTTP proxy batek IMDS hauts dezake ip route get espero duzun interfazea zehazki itzultzen duen bitartean, beraz, egiaztatu proxy bazterketak bideez gain.

Ez itsatsi metadatuen erantzunik laguntza-txartel batean hau arazten duzun bitartean. Istripua baino gehiago irauten duten kredentzialak eta instantzia-xehetasunak eraman ditzakete.

Irakurri gonbidatuaren politikaren bideratzea, ez bakarrik taula nagusia

Linux gonbidatu batean, hiru irakurketa-soileko komandok geruzak bereizten dituzte: ip -4 rule show politikaren arauetarako, gero ip -4 route get 168.63.129.16 eta ip -4 route get 169.254.169.254 kernelak benetan hartzen dituen erabakietarako. Exekutatu VPN-a konektatu aurretik eta ondoren. Irteera horien arteko aldea zure aldaketa-multzoa da, eta bezeroak zer egin zuen buruzko edozein susmo baino erabilgarriagoa da.

Politika-arauak instalatzen dituen VPN bezero batek taula nagusia ukitu gabe utz dezake eta bilaketa horiek oraindik berbideratu. Horregatik, taula nagusia soilik konpontzen duen soluzioak ostalari batean funtzionatzen duela dirudi eta hurrengoan ezer ez du egiten. NIC anitzeko gonbidatuek arazo bera gehitzen dute beste aldetik, erantzuna arauak zein NIC eta iturburu-helbide hautatzen dituen araberakoa baita.

Egin aurre /32 bide biak pasabide zaharretik gehitzen dituen errezetari. Link-local plataforma-bidea eta WANeko hurrengo jauzi orokorra objektu desberdinak dira, eta salbuespen orokor batek benetako politika-gatazka ezkutatzen du.

Eduki administrazioa eta berreskuratzea bereizita

Zure SSH edo RDP erantzuna tunel osoko default batek har dezake ere, baina administratzailearen behatutako helbidea du helburu, ez plataformaren muturretako bat. Diagnostikatu bere eskaera-erantzun bikote propioan oinarrituta, eta eduki berreskuratze-kanal independente bat, serie-kontsola adibidez, VPN politika aldatu aurretik. Hedapen batek VM berrabiarazten badu eta agenteak osasungaitza dela jakinarazten badu, aztertu erregistratutako ekintza eta zerbitzu arduraduna, bidea aldaketak berrabiaraztea eragin zuela suposatu ordez.

Gero egiaztatu hiru fluxuak bereizita: benetan nahi zenuen baliabide pribatua, onartutako agente eta plataformaren komunikazioa, eta administrazio-bidea. Horietako bat berreskuratzeak ez du frogatzen beste biak bizirik atera direnik.

Idatzi onartutako salbuespena gonbidatuaren sarearen eta VPN konfigurazioaren jabearen izenean, berriz konektatzean eta berrabiaraztean zer gertatzen den barne. Azureko UDRak ez dira gonbidatuaren bideratze-taula, eta haiek editatzeak ez du tokiko politika-arau bat konponduko.