Внатрешна апликација се разрешува на Windows домаќинот во моментот кога VPN се поврзува, а гостинот Ubuntu зад NAT на VirtualBox сѐ уште не може да го најде. Гостинот има свој резолвер и NAT адаптерот може да ракува со DNS на повеќе од еден начин. Замената на резолверот на гостинот со јавен сервер ги прави обичните мрежни места функционални, а приватните имиња неуспешни, што го пренасочува проблемот наместо да го реши. Изведете ги четирите проверки по ред и застанете на првата што не важи.

Потврдете кој режим на адаптер го отстранувате

Само адаптер во обичен режим NAT се однесува како што опишува оваа статија. Мостовиот адаптер стои на физичката мрежа со сопствен идентитет, NAT мрежата е именуван виртуелен прекинувач со сопствени поставки за DHCP и DNS, а VPN клиентот внатре во гостинот додава сосема втор резолвер. Потврдете го режимот пред да читате понатаму, бидејќи поправката се разликува во секој од тие случаи.

Една виртуелна машина може да носи два адаптера во различни режими, а засегнатиот не е секогаш првиот.

Потврдете и дека домаќинот воопшто го разрешува името. Отворете ја истата апликација на домаќинот со подигнат тунел, користејќи го истото целосно квалификувано име што ќе го користи гостинот. Ако и домаќинот не успее, гостинот не е виновен и никаква промена на виртуелната мрежа нема да го поправи тоа.

Следете едно име низ резолверот на гостинот

Изберете едно внатрешно име и едно јавно контролно име, потоа тестирајте ги двете на двете места. Јавно име што се разрешува додека приватното не, ја лоцира грешката на приватната патека, а не во разрешувањето имиња општо. Тестирањето само на приватното име ве остава неспособни да разликувате расипан резолвер од расипана рута.

Внатре во гостинот, погледнете за што е навистина конфигуриран резолверот. На гостин Ubuntu со systemd-resolved, статусот по врска ги покажува серверите што пристигнале, а датотеката resolv.conf може да содржи само stub адреса, што е точно, а не сомнително. Рачно уредена датотека или посебен клиент за шифриран DNS можат да ги испратат барањата сосема на друго место. Запишете што најдовте пред да го смените.

resolvectl status
resolvectl query app.internal.example

Овде одвојте го разрешувањето од достапноста. Адреса што пристигнува додека услугата останува недостапна е прашање на рутирање или политика, не на DNS.

Пробајте го режимот на резолверот на домаќинот на тој адаптер

Опциите за NAT DNS на VirtualBox опишуваат различни механизми, а разликата е важна кога сопствениот резолвер на домаќинот се менува со тунелот. DNS проксито ги препраќа барањата на гостинот до сервери што му биле дадени. Режимот на резолверот на домаќинот ги пресретнува барањата и го повикува DNS API на домаќинот, а тоа е режимот што следи Windows резолвер преконфигуриран од VPN клиент.

Вклучете го погрешниот механизам и командата сѐ уште ќе успее додека однесувањето не се менува, што е збунувачки начин да изгубите попладне.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

Запишете ги тековните поставки на виртуелната машина, исклучете ја и насочете се кон адаптерот што го потврдивте претходно. Последната цифра во опцијата е број на адаптер, а не константа, така што нејзината примена на машина чиј засегнат адаптер е вториот е тивка операција без ефект. Стартувајте го гостинот и проверете ја конфигурацијата на резолверот што навистина ја добил, бидејќи рачна поставка во гостинот го надминува сето она што го нуди NAT слојот. Запомнете дека режимот на резолверот на домаќинот исто така претпоставува дека сопствената DNS патека на домаќинот е онаа што сакавте да ја споделите.

Повторете ги истите тестови низ повторно поврзување на VPN

Повторете ги двете барања во гостинот, потоа отворете ја вистинската апликација и оставете ја сама да го провери сертификатот. Тестот само по адреса е корисен за изолирање на разрешувањето имиња и не е еднаков на работна TLS сесија, затоа не застанувајте на ping. Потоа, во одобрен прозорец, исклучете и повторно поврзете го тунелот на домаќинот и повторете уште еднаш. Однесување што се задржува само при првата врска по подигањето е проблем на животниот циклус за пријавување, а не DNS мистерија што треба да се брка со друг резолвер.

Работењето на јавното разрешување не докажува дека приватните барања останале на патеката што ја бара вашата политика.

Кога режимот на резолверот на домаќинот не менува ништо, вратете ја запишаната конфигурација и задржете ги четирите набљудувања: што вратил домаќинот, што вратил гостинот, режимот на адаптерот и состојбата на резолверот. Недостапен внатрешен сервер, филтер што го исклучува сообраќајот на хипервизорот и препишување на страната на гостинот секое бара различна корекција. Претворањето на адаптерот во мост го менува дизајнот на мрежата и не е ресетирање на DNS.

Поврзани статии