VPN башталгандан кийин Azure VM IMDS же WireServer-ге жетпейт
Конок VPN 168.63.129.16 жана 169.254.169.254 маршрутун уурдашы мүмкүн. Статикалык /32 кошуудан мурун policy routing окуңуз жана админ кирүүнү өзүнчө кармаңыз.
VM иштеп жатат, VPN кардары туташкандыгын айтат, бир нече мүнөттөн кийин Azure агенти ден соолугу начар экенин билдире баштайт. Кээде SSH турат, порталдын Run Command турбайт, бул адамдарды маршрут таблицасына эмес, агентке кароого түртөт. Туннель көтөрүлгөндө коноктун өзүнүн өткөрүү чечимдери өзгөрдү, жана адатта платформанын эки дареги биринчи курмандык болот. Мен муну агенттин бузулушу деп эсептегенге чейин маршруттоо белгиси деп карайм.
Белги сынган агентке окшош
Төмөнкү эки дарек тең чечим катары сунушталат, бирок алар бир кызмат эмес. Бирөө үчүн /32 көчүрүү, анткени ал экинчиси үчүн иштеди — убактылуу айланып өтүү жолу эч ким өчүрүүгө батынгыс туруктуу конфигурацияга айлануучу так ушул жол.
Иштеген тартип: адегенде ийгиликсиз чакырык чын эле кайсы дарекке багытталганын ырастоо, анан конок аны кантип чечээрин окуу. Калганынын баары кошумча кадамдар менен божомолдоо жана узагыраак өзгөртүү терезеси.
168.63.129.16 коомдук максат эмес
168.63.129.16 — Azure платформасынын атайын виртуалдык дареги, анын бир ролу WireServer, аны VM агенти фабрика менен сүйлөшүү үчүн колдонот. Microsoft агенттин TCP 80 жана 32526 портторуна трафиги жеткиликтүү бойдон калышы керек экенин документтештирет. Бул кадимки интернет хост эмес жана толук туннелдүү VPN аны алыскы чыгууга ташыбашы керек. Ошондуктан саламаттык көрүнгөн туннель да агентти ачка калтырышы мүмкүн.
Платформа дарегинин документтери бул дарек колдонуучу аныктаган маршруттарга баш ийбей турганын да айтат; бул Azure фабрикасынын касиети, коногуңуз жөнүндө убада эмес. Жергиликтүү firewall эрежеси же VPN кардарынын өз маршруттоо саясаты жолду дагы эле буза алат, жана алардын эч бири VNet маршрут таблицасында жашабайт.
Эгер маселени агент билдирсе, бир нерсени кайра орнотуудан мурун кызматтын абалын жана ошол дарекке барар жолду текшериңиз.
169.254.169.254 өз эрежелерине ээ
169.254.169.254 — Azure Instance Metadata Service кызматынын link-local дареги. Ага багытталган суроолордун өз талаптары бар: негизги NIC жана негизги IP, даректи колдогон DHCP конфигурациясы жана каалаган HTTP проксини айланып өтүү. Аларды алыскы VPN чыгуусунан же каалаган интернет дарбазасынан жиберүү Microsoft сүрөттөгөн кирүү модели эмес.
Бул прокси пункту маршрутту оңдоп, дагы эле ката көргөндөрдү кармайт. Коноктогу HTTP прокси IMDSти буза алат, ал эми ip route get күткөн интерфейсти так кайтарат, андыктан маршруттар менен катар проксинин өзгөчөлүктөрүн да текшериңиз.
Муну жөндөп жатканда метаберилиштердин жоопторун колдоо билетине чаптабаңыз. Алар окуядан узак жашаган тиркемелерди жана инстанстын чоо-жайын алып жүрүшү мүмкүн.
Коноктун саясий маршруттоосун окуңуз, жаңы негизги таблицаны эле эмес
Linux коногунда үч окуу-гана буйрук катмарларды бөлөт: саясат эрежелери үчүн ip -4 rule show, анан ядро чын эле кабыл алган чечимдер үчүн ip -4 route get 168.63.129.16 жана ip -4 route get 169.254.169.254. Аларды VPN туташканга чейин жана андан кийин иштетиңиз. Ошол эки чыгыштын айырмасы — сиздин өзгөртүүлөр жыйнагы, жана кардар эмне кылганы тууралуу каалаган божомолдон пайдалуу.
Саясат эрежелерин орноткон VPN кардары негизги таблицаны тийбей калтырып, ошол издөөлөрдү бурмалай алат. Ошондуктан негизги таблицаны гана оңдогон чечим бир хостто иштеп, кийинкисинде эч нерсе кылбайт. Көп NICтүү коноктор ошол эле маселени экинчи тараптан кошот, анткени жооп эреженин кайсы NIC жана баштапкы даректи тандашына көз каранды.
Эски дарбаза аркылуу эки /32 маршрутун тең кошкон рецептке каршы тургула. link-local платформа жолу жана жалпы WAN кийинки секирик ар башка объектилер, ал эми жалпы өзгөчөлүк чыныгы саясий кагылышты жашырат.
Администрациялоо жана калыбына келтирүүнү өзүнчө кармаңыз
Сиздин SSH же RDP жообун толук туннелдин демейкиси да кармап калышы мүмкүн, бирок ал платформанын четки чекитин эмес, администратордун байкалган дарегин максат кылат. Аны өз суроо-жооп жубу боюнча диагностикалаңыз жана VPN саясатын өзгөртүүдөн мурун сериялык консоль сыяктуу көз карандысыз калыбына келтирүү каналын кармаңыз. Эгер жайгаштыруу VMди кайра баштаса жана агент начар ден соолукту билдирсе, маршруттун өзгөрүшү кайра баштоого себеп болду деп божомолдоонун ордуна жазылган аракетти жана жооптуу кызматты текшериңиз.
Анан үч агымды өзүнчө текшериңиз: чындап керек болгон жеке ресурс, колдоого алынган агент жана платформа байланышы жана администрациялоо жолу. Бирин калыбына келтирүү калган экөө аман калганынын далили эмес.
Бекитилген өзгөчөлүктү конок тармагынын жана VPN конфигурациясынын ээсинин атына жазыңыз, ага кайра туташуу жана кайра баштоо учурунда эмне болорун да кошуңуз. Azure UDRлери коноктун маршрут таблицасы эмес, аларды оңдоо жергиликтүү саясат эрежесин оңдобойт.