Фактът, че адаптер 1 е първи в списъка на хипервизора, е ред на показване и таблицата за маршрутизация на госта не го чете. Пътя определят префиксът, метриката и всяко правило за политика, което се прилага преди тях. Затова добавянето на мостов адаптер към лабораторна VM може да създаде втори маршрут по подразбиране, докато старият NAT интерфейс все още се показва като наличен и номериран втори. Резултатът е VM, която понякога използва тунела, а понякога не, без промяна в конфигурацията, която да го обясни.

Три условия определят пътя

Трите условия са кой префикс е по-конкретен, какво правят метриките при равенство на префиксите и какви правила е приложил гостът след промяната на хардуера. На всяко от тях може да се отговори с една команда и нито едно не включва номерацията на хипервизора.

Последната точка е решението: ако не можете да кажете кой префикс печели за собствения адрес на VPN крайната точка, нямате политика за маршрутизация, а топология, която случайно работи днес.

Условие първо: кой префикс печели

Маршрут към 10.8.0.0/24 побеждава маршрута по подразбиране за адрес вътре в него, независимо от метриките и от реда на адаптерите. Затова VPN клиент, който инсталира конкретен маршрут, продължава да работи дори когато се появи втори адаптер с по-ниска метрика: конкретността печели преди да се вземе предвид цената. Проверете с ip route show таблицата, която смятате за използвана, и с ip route get 203.0.113.9 отговора, който ядрото действително би дало за конкретна дестинация.

Собственият адрес на крайната точка е тестът, който е най-важен. Ако адресът на VPN сървъра се резолвва през новодобавен мостов адаптер, тунелът може никога да не се установи или да се установи и след това да загуби собствения си транспортен път. Питайте конкретно за този адрес, вместо да предполагате, че тунелният интерфейс е отговорът.

Условие второ: какво прави метриката и какво не

Ролята ѝ е по-тясна, отколкото повечето хора очакват. Метриките решават равенство между маршрути към един и същ префикс; те не позволяват на по-общ маршрут да победи по-конкретен. По-малкото число се предпочита при равенство, а различните операционни системи броят в противоположни посоки, затова съвети, прехвърлени между Linux и Windows, често си противоречат.

В госта ip route show отпечатва метриката до всеки маршрут, а Get-NetRoute в Windows отпечатва InterfaceMetric плюс метрика на маршрута. Четете и двете, защото ефективното предпочитание може да е сбор, а не едно поле. Ако съществуват два маршрута по подразбиране, това е находката: гостът има два изхода и кой печели зависи от числа, които промяна на хардуера може да измени.

Условие трето: какво действително е приложил гостът

Конфигурацията не е същото като приложено състояние. Имената на интерфейсите не са стабилни при промени на хардуера на всяка платформа и конфигурация, която е съвпадала по име, може сега да не се прилага към нищо.

Проверявайте приложеното състояние, а не предвиденото. ip -br link показва интерфейсите, които съществуват сега, а на хост с NetworkManager nmcli connection show показва кой профил към кое устройство е вързан. Профил, който не е успял да се върже, оставя интерфейса включен без адресация, което изглежда като проблем с маршрутизацията, а е проблем с именуването. Възстановените моментни снимки влошават това, защото запазеното състояние на госта може да сочи към идентичности на адаптери, които новият хардуер вече не предоставя.

Пазете топологията на лабораторията възпроизводима

Запазете предвидените прикачвания на виртуалната мрежа заедно с конфигурацията на госта, така че съответствието между роля и адаптер да е записано, а не изведено от позиция в списък.

Обикновено четири роли са достатъчни за именуване: частна връзка, управление, външен транспорт и тунел. Всяка трябва да съответства на конкретен адаптер и конкретен интерфейс на госта, във файл.

След това тествайте действителното приложение след промяна на хардуера, рестарт или възстановена моментна снимка и включете маршрута към VPN крайната точка в този тест. Ако VM шлюз трябва да е единственият изход, проверете че тестовата VM няма нежелан втори маршрут по подразбиране, защото мостовият адаптер добавя точно втори маршрут по подразбиране. Тествайте от госта, не от конзолата на хипервизора, защото двете могат да не са съгласни кой интерфейс кой е.

Документацията за мрежи на VirtualBox описва режимите на адаптерите и към какво се прикачва всеки от тях — това е частта, която си струва да се прочете преди добавяне на втори. Лаборатория, която определя кой адаптер изпълнява коя роля, прави промяната на маршрут обяснима. Лаборатория, която разчита на номерацията на хипервизора, прави всяка промяна експеримент.

Подобни статии