Форум за поддръжка на OpenVPN
След това, инструменти за DNSSEC проверки. По -малко вероятно като причина, но е възможно:
VirtualBox.org
DNS Resolve Не работи върху VirtualBox VM, когато VPN е включен на хост
Дискусии, свързани с използването на VirtualBox на хостове на Windows.
5 публикации • Страница 1 на 1
Vnox Постове: 3 Присъединиха: 19. Март 2022, 09:31
DNS Resolve Не работи върху VirtualBox VM, когато VPN е включен на хост
Публикувано от Vnox »19. Март 2022, 09:33
Имам гост на Windows 10 Host и Ubuntu Server на VirtualBox. Имам OpenVPN клиент на хоста на Windows. Гост VM е настроен на Nat Network (не NAT) тип.
Всеки път, когато VPN-клиентът е включен, трафикът от хост се пренасочва чрез сървър, клиентът OpenVPN е свързан с. Но веднага губя търсене/разрешаване на DNS в гост VM (Internet работи добре както в Guest VM & Host, но DNS Resolve се проваля в моя гост VM)
Ако VPN клиентът е изключен, всичко (Интернет, DNS търсене) работи добре в моя хост, гост VM.
Всякакви предложения как да смекчите това?
Редактиране:
Версия на VirtualBox: 6.1.32
Инсталирани добавки за гости, използвайки Intel VT-X
Адаптер: Intel Pro/1000 MT Desktop
Режим PROMISCUSUED: Откажете
FTH0 Доброволец Постове: 5099 Присъединиха: 14. Февруари 2019, 03:06 Първична ОС: Mac OS X други Версия на Vbox: Пуел Оси за гости: Linux, Windows 10, . Местоположение: Германия
Re: DNS Resolve Не работи върху VirtualBox VM, когато VPN е включен на хост
Публикувано от fth0 »19. Март 2022, 10:25
Моля, опитайте 9.8.5. Активиране на DNS прокси в NAT режим и 9.8.6. Използвайки разрешаването на хоста като DNS прокси в NAT режим и ни кажете кой от тях работи за вас и кой не. Тиа.
Форум за поддръжка на OpenVPN
Правила на форума
Моля, използвайте BB маркера [OCONF] за конфигурации OpenVPN. Вижте ViewTopic.php?f = 30 & t = 21589 за пример.
15 публикации • Страница 1 на 1
зима.tal openvpn newbie Постове: 1 Присъединиха: Вторник 01 ноември 2016 г. 19:03
Търсенето на DNS не успя на хост – грешка
Публикувано от зима.Тал »Вторник, 01 ноември 2016 г. 19:08
Опитвам се да вляза в моя VPN от Mac и получавам следната грешка:
Неочаквана грешка: DNS търсенето не е успешно на хост ” [Errno 8] възобновяване, което се предоставя или сервира, или не е известно
Може ли някой да посъветва ?
Tincantech OpenVPN главен герой Постове: 11142 Присъединиха: Пет юни 03, 2016 13:17
Re: DNS търсенето не е успешно на хост – грешка
Публикувано от Tincantech »Вторник 01 ноември 2016 г. 20:29 ч
зима.Тал написа: имена на възли, нито сервиране, предоставено или не известно
Проверете името на вашия сървър.
Джон[email protected] openvpn newbie Постове: 1 Присъединиха: Вторник 17 февруари 2015 г. 22:33
Re: DNS търсенето не е успешно на хост – грешка
Публикувано от Джон[email protected] »Пет 18 ноември 2016 г. 16:10
Предполагам, че отговорът на Tincantech не е помогнал, тъй като имаме проблеми с това сред нашите потребители.
Поддръжката на OpenVPN ме информира, че са виждали проблеми, докладвани от други, като текущият им клиент Mac OpenVPN Connect за Mac OS X и Comcast DNS. Можете да заобиколите този проблем, ако не използвате Comcast DNS на вашия рутер или компютър. Поддръжката на OpenVPN имаше билета ми за това нерешено от 3 октомври.
Странният проблем е, че компютърът, на който е инсталиран клиентът на OpenVPN Connect, няма проблем да разреши DNS за свързване към клиентския уеб интерфейс на сървъра за достъп до OpenVPN. Но когато стартирате клиента OpenVPN Connect и се опитате да се свържете със сървъра за достъп на OpenVPN, клиентът има DNS грешки, решавайки DNS към сървъра за достъп на OpenVPN. Няма регистрационни файлове на сървъра за достъп за това, защото клиентът дори не може да разреши адреса на сървърите за достъп. Изглежда, че нещо не е наред с клиента OpenVPN Connect, ако не може да разреши правилно DNS.
Разочарован и озадачен.
Tincantech OpenVPN главен герой Постове: 11142 Присъединиха: Пет юни 03, 2016 13:17
Re: DNS търсенето не е успешно на хост – грешка
Публикувано от Tincantech »Пет 18 ноември 2016 г. 18:58
Джон[email protected] написа: Поддръжката на OpenVPN ме информира, че са виждали проблеми, докладвани от други, с текущия им Mac OpenVPN Connect Client за Mac OS X и Comcast DNS. Можете да заобиколите този проблем, ако не използвате Comcast DNS на вашия рутер или компютър. Поддръжката на OpenVPN имаше билета ми за това нерешено от 3 октомври.
Ако смятате, че това е грешка с OpenVPN-Connerct, тогава трябва да го докладвате за TRAC за грешки, където можете също да следвате всеки напредък.
Ако смятате, че това е грешка с Comcast DNS, моля, докладвайте им .. И ни уведомете, ако получите идентификационен номер на билета, към който също можем да се свържем и да следваме.
ZEDD45 OpenVPN Newbie Постове: 1 Присъединиха: Сряда на 04 януари 2017 г. 16:17
Re: DNS търсенето не е успешно на хост – грешка
Публикувано от zedd45 »Ср. 04 януари 2017 г. 16:21
Срещнах този проблем след надграждане до Mac OSX Sierra.
Моите колеги не срещнаха този проблем. Две неща, които трябва да се отбележи тук, които може да са допринесли за този проблем, но които не успях да потвърдя къде основната причина за проблема:
1. Моите DNS бяха предоставени чрез AT&T / настройки по подразбиране на ISP
2. DNS за AT&T използва IP6 адрес
Преминах към Google DNS, използвайки следния урок и успях да вляза отново:
https: // разработчици.Google.com/скорост/кръчма . Документи/Използване
Jwilmot OpenVPN Newbie Постове: 1 Присъединиха: Чт 12 януари 2017 г. 22:03
Re: DNS търсенето не е успешно на хост – грешка
Публикувано от Jwilmot »Чт 12 януари 2017 г. 22:05
Само за да потвърдя, решението, предоставено от ZEDD45 (използвайки обществените DNS сървъри на Google), работи за мен. Преди използвах DNS на Comcast и видях този проблем, след като надградих до OSX Sierra.
fuzzymazoid openvpn newbie Постове: 1 Присъединиха: Вторник 28 февруари 2017 г. 16:06
Re: DNS търсенето не е успешно на хост – грешка
Публикувано от Fuzzymazoid »Вторник 28 февруари 2017 г. 16:11
Току -що накарах потребител да се сблъска със същия проблем. Току -що получи нов Mac у дома, а днес беше първият му ден, който се свързва с Office VPN. Симптомите са абсолютно същите като по -горе: най -новата Mac OS, Comcast DNS, “Неочаквана грешка: DNS търсене не е успешно на хост XXXXXXX: [Errno 8] Nodename, нито сервис, предоставен или не известен”
Накарахме го да премине от сървърите на Comcast DNS към Google DNS сървъри и той успя да се свърже без проблем.
Изглежда малко вероятно, че DNS на Comcast е грешен по някакъв начин. Има ли грешка, отчетена за OpenVPN Connect, която можем да проследим?
tmacpherson openvpn newbie Постове: 1 Присъединиха: Чт 09 март 2017 г. 21:45
Re: DNS търсенето не е успешно на хост – грешка
Публикувано от tmacpherson »Чт 09 март 2017 г. 21:52
Имаме същия проблем, докато сте в VerizonWireless Network. На нашите mifi не можем да използваме името DNS за нашия VPN. Работата наоколо е да използвате iPaddress, просто направете nslookup на вашето име DNS, например nslookup myvpndnsname.mydomain.com и това ще ви даде публичния IP на вашия VPN уред. Надяваме се, че това ще бъде отстранено бързо. Имам Comcast у дома, но никога не бих използвал техните DNS в рутера си, винаги използвам публичен DNS
SomeGuy OpenVPN Power User Постове: 62 Присъединиха: Съб 17 декември 2016 г. 1:58 ч
Re: DNS търсенето не е успешно на хост – грешка
Публикувано от Някаква джип »Чт 09 март 2017 г. 22:50
Две предложения, свързани с това.
* IPv4 срещу IPv6, DNS и афинитет на Resolver: Ако стартирате A с конфигурация на клиент OpenVPN, която има ред “сървър” с FQDN (напълно квалифициран-Domain-име), който може да разреши на IPv6 и IPv4 адреси, проверете дали ще видите дали OpenVPN сървърът, на който се опитвате да се свържете с предоставя услуга за IPv4 и IPv6 клиенти. Много разделители в ОС имат афинитет да разрешат DNS AAAA записи през A или CNAME и ще са склонни да предпочитат IPv6 адресите да бъдат разрешени за име на IP, ако има както IPv4, така и IPv6 адреси.
* Домейни, които поддържат DNSSEC: Много от интернет доставчиците се движат, за да прилагат правила на DNSSEC с търсене на име на IP N DNS сървърите * Те * работят за своите клиенти. Ако друго име на домейн е лошо конфигурирано с DNSSEC или има изтекли клавиши, правилно прилагането на DNS сървъри, изпълняващи вашата заявка срещу DNS, които имат DNSSEC конфигуриран, няма да предаде никакви IP адреси на своите клиенти, тъй като резултатите не могат да бъдат валидирани. Някои ISP са експериментирали с частична поддръжка на DNSSEC или пренасочване на Kludgy към уеб страница, която казва на клиента * Web *, че опитът за разрешаване на името на IP е довел до проблеми с DNSSEC. Такава уеб страница не би била видима за „вие“, ако вашият клиент OpenVPN се пренасочи към различен IP от това, което се очаква.
Знам, че Comcast беше рано да експериментира с DNSSEC и да приеме използването на IPv6. Би ли бил някой, който среща проблема, описан в тази тема, моля, проверете дали някой от тези по -горе елементи е източникът на проблеми? Някои предложени методи за тестване са изброени по -долу:
DNS търсене, IPv4 срещу IPv6 или някакъв друг DNS проблем: Ако имате Linux черупка с инсталирана “Dig”.
В тези примери използвам “8.8.8.8 “(IP адреса на IPv4 на публичния DNS Server на Google) и 2001: 4860: 4860 :: 8888 (IP адреса на IPv6 на Google Server на Google.)
“-4” казва, използвайте моя IPV IP адрес и се свържете с IPv4 адреса на сървъра (полезно, ако използвате имена, вместо IP адреси, за които DNS сървър искате да използвате), а “-6” Използвайте IPv6 IP адрес на моята машина, за да говоря с DNS, работещ с IPv6 адрес. (Използване на IPv4 адрес за DNS след “@” вече изисква IPv4 имплицитно, но включително в случай, че замените стойността след “@” с име.)
“А” е условно запис за име на IPv4 адрес.
“AAAA” е запис за име на IPv6 адрес.
Заявка IPv6 DNS сървър на Google и поискайте запис на AAAA (IPv6 адрес, ако има такъв) за името на хоста “www.Google.com “:
$ dig +short @2001: 4860: 4860 :: 8888 -6 -t aaaa www.Google.com 2607: f8b0: 4005: 807 :: 2004
Въведете IPv4 DNS сървър на Google и поискайте запис (IPv4 адрес, ако има такъв) за името на хоста “www.Google.com “:
Dig +Short @8.8.8.8 -4 -t a www.Google.com 216.58.195.68
Пример, използващ случай, при който записът на CNAME се използва вместо запис:
Dig +Short @8.8.8.8 -4 -t cname www.Microsoft.com www.Microsoft.COM-C-2.EdgeKey.нета.
В този случай CNAME се разрешава на име, което след това можете да разрешите, и следвайте, докато не намерите IP адреса.
Ако някой от междинните CNAME във веригата към вашия краен IP адрес използва DNSSEC, тогава тези домейни също могат да бъдат изследвани за правилна конфигурация.
Заменете “www.Google.com “или” www.Microsoft.com “Със напълно квалифицираното име на Домейн в сървъра на вашия клиент” . “Конфигурация. Вижте какви резултати намирате.
След това опитайте същото спрямо предоставените DNS сървъри на вашия ISP и заменете ценените след „@“ с IP на вашия ISP сървър на ISP. Получавате ли същите резултати?
Ако резултатите не съответстват на това, което виждате от DNS на Google, как са различни? Решава ли е единият IP, докато другият не го прави? Решават ли се към различен IP? Ако е различен, кой е собственик на Netblock на IP адреса, който е неочакван резултат?
След това, инструменти за DNSSEC проверки. По -малко вероятно като причина, но е възможно:
Ако вашият домейн използва делегация с поддомейни, тогава може да се наложи да проверите името на вашия домейн, * и * поддомейни за правилни конфигурации на DNSSEC, чак до, но без да се включва име на хост за всяка делегация на под-домейн с DNSSEC.
За организации, които управляват неща, различни от VPN, те вероятно имат име на хост.домейн.TLD за „сървъра на техния клиент . “Конфигурирайте линии. Посветените доставчици на VPN услуги може да не. Когато завършите вашите DNSSEC проверки, искате да спрете „Името на хоста“ (на всеки) от „сървъра . „Конфигурирайте линия, когато я изпращате на тези два инструмента за пример на DNSSEC. (Така.Google.com “Тогава домейнът за проверка с тези инструменти би бил” Google.com “и почти сигурно не” OpenVPN.Google.com “)
Ако установите, че CNAME са били използвани за други имена в горната стъпка, ще искате да проверите състоянието на DNSSEC на тези домейни и/или поддомейни, докато най-накрая стигнете до IP адрес.
Ако установите, че проблемите, с които се сблъсквате, не са свързани с тези два въпроса (IPv6 адресът е разрешен спрямо IPv4 адреса, разрешен или проблеми с валидирането/конфигурацията на DNSSEC), моля, проследяване казвате така.
Ако установите, че едното или и двете са източник на проблеми, моля, публикувайте и тази информация.
Знаейки какъв е източникът на проблема, би помогнало да се разбере дали това е грешка или не, и ако не, как да го поправите или да го стъпвате.
Не съм имал проблеми с резолюцията на клиента на Comcast или Verizon, или Sprint, или AT&T, когато ги използвах, но използвам правилно конфигурирани домейни, използвайки DNSSEC за моите домейни за валидиране За всяко име и порт на сървъра.
TEEC OpenVPN Newbie Постове: 1 Присъединиха: Вторник 09 май 2017 г. 12:59
Re: DNS търсенето не е успешно на хост – грешка
Публикувано от Teec »Вторник 09 май 2017 г. 13:01
Имали ли сте актуализации по този проблем? Това ми пречи да имам достъп до работата ми VPN от вкъщи. Да, промяната на Google DNS помага, но след това завинтва DNS, докато е на работа, така че не искам да продължавам да превключвам напред -назад. Този брой възникна само за мен след надграждане до OSX Sierra..
maxigs openvpn newbie Постове: 1 Присъединиха: Сряда 17 май 2017 г. 8:51
Re: DNS търсенето не е успешно на хост – грешка
Публикувано от Максигс »Ср. 17 май 2017 г. 8:54
Още един тук. Вчера надградих до Сиера и имам същия проблем, който сега се опитвах да вляза в компанията VPN.
Засега го „поправих“, като добавя името на хоста към моя /etc /хост файл, за да го прескочите. Това изглежда работи засега, не е идеално, но IP рядко се променя, за да мога да живея с него.
VCardillo OpenVPN Newbie Постове: 1 Присъединиха: Пон 22 май 2017 г. 21:00 ч
Re: DNS търсенето не е успешно на хост – грешка
Публикувано от VCardillo »Пон 22 май 2017 г. 21:03
Същият проблем, с продукта на сървъра за достъп.
Gushi OpenVPN Newbie Постове: 2 Присъединиха: Сряд 19 юли 2017 г. 12:38 ч
Re: DNS търсенето не е успешно на хост – грешка
Публикувано от Гуши »Сряда 19 юли 2017 г. 12:41
Не, и ние използваме уреда с платен лиценз (което означава на теория, че нашите проблеми трябва да получат някаква поддръжка).
Заснех пакети от моя Mac, правейки DNS търсене и изрично исках AAAA запис на моя локален DNS сървър. След това връзката се проваля, вместо да се върне към искане за запис.
Лорънс.Henry OpenVPN Newbie Постове: 1 Присъединиха: Пет септември 01, 2017 13:11
Re: DNS търсенето не е успешно на хост – грешка
Публикувано от Лорънс.Хенри »Пет септември 01, 2017 13:15
И така, следвайки тази обща тема от съвети – преживяхме този проблем с някои от нашите потребители на Mac на определени интернет доставчици. Ние деактивирахме IPv6 на Macs, имайки проблема и той “отстрани” проблема.
Вижте бележките по-долу, за да деактивирате и активирате отново IPv6:
Изключване на IPv6 поддръжка за Ethernet:
Networksetup -setv6off ethernet
Деактивиране на IPv6 за безжична връзка:
Networksetup -setv6off Wi -Fi
Можете също да комбинирате и двете команди в един низ, за да деактивирате както безжичната, така и Ethernet, просто използвайте следния синтаксис:
networksetup -setv6off ethernet && networksetup -setv6off wi -fi
Не забравяйте да въведете този низ в един ред, за да издадете правилно командата.
Възстановяване на IPv6 за Wi-Fi & Ethernet в OS x
Разбира се, е възможно и обърнато на горната промяна и можете да отново активирате IPv6 поддръжка със следните командни низове, въведени в терминала:
Networksetup -setv6automatic Wi -Fi
Networksetup -setv6automatic Ethernet
Можете също така да поставите това в една команда, за да се активира IPv6 за Wi-Fi и Ethernet така:
networksetup -setv6automatic wi -fi && networksetup -setv6automatic ethernet
SomeGuy написа: Две предложения, свързани с това.
* IPv4 срещу IPv6, DNS и афинитет на Resolver: Ако стартирате A с конфигурация на клиент OpenVPN, която има ред “сървър” с FQDN (напълно квалифициран-Domain-име), който може да разреши на IPv6 и IPv4 адреси, проверете дали ще видите дали OpenVPN сървърът, на който се опитвате да се свържете с предоставя услуга за IPv4 и IPv6 клиенти. Много разделители в ОС имат афинитет да разрешат DNS AAAA записи през A или CNAME и ще са склонни да предпочитат IPv6 адресите да бъдат разрешени за име на IP, ако има както IPv4, така и IPv6 адреси.
* Домейни, които поддържат DNSSEC: Много от интернет доставчиците се движат, за да прилагат правила на DNSSEC с търсене на име на IP N DNS сървърите * Те * работят за своите клиенти. Ако друго име на домейн е лошо конфигурирано с DNSSEC или има изтекли клавиши, правилно прилагането на DNS сървъри, изпълняващи вашата заявка срещу DNS, които имат DNSSEC конфигуриран, няма да предаде никакви IP адреси на своите клиенти, тъй като резултатите не могат да бъдат валидирани. Някои ISP са експериментирали с частична поддръжка на DNSSEC или пренасочване на Kludgy към уеб страница, която казва на клиента * Web *, че опитът за разрешаване на името на IP е довел до проблеми с DNSSEC. Такава уеб страница не би била видима за „вие“, ако вашият клиент OpenVPN се пренасочи към различен IP от това, което се очаква.
Знам, че Comcast беше рано да експериментира с DNSSEC и да приеме използването на IPv6. Би ли бил някой, който среща проблема, описан в тази тема, моля, проверете дали някой от тези по -горе елементи е източникът на проблеми? Някои предложени методи за тестване са изброени по -долу:
DNS търсене, IPv4 срещу IPv6 или някакъв друг DNS проблем: Ако имате Linux черупка с инсталирана “Dig”.
В тези примери използвам “8.8.8.8 “(IP адреса на IPv4 на публичния DNS Server на Google) и 2001: 4860: 4860 :: 8888 (IP адреса на IPv6 на Google Server на Google.)
“-4” казва, използвайте моя IPV IP адрес и се свържете с IPv4 адреса на сървъра (полезно, ако използвате имена, вместо IP адреси, за които DNS сървър искате да използвате), а “-6” Използвайте IPv6 IP адрес на моята машина, за да говоря с DNS, работещ с IPv6 адрес. (Използване на IPv4 адрес за DNS след “@” вече изисква IPv4 имплицитно, но включително в случай, че замените стойността след “@” с име.)
“А” е условно запис за име на IPv4 адрес.
“AAAA” е запис за име на IPv6 адрес.
Заявка IPv6 DNS сървър на Google и поискайте запис на AAAA (IPv6 адрес, ако има такъв) за името на хоста “www.Google.com “:
$ dig +short @2001: 4860: 4860 :: 8888 -6 -t aaaa www.Google.com 2607: f8b0: 4005: 807 :: 2004
Въведете IPv4 DNS сървър на Google и поискайте запис (IPv4 адрес, ако има такъв) за името на хоста “www.Google.com “:
Dig +Short @8.8.8.8 -4 -t a www.Google.com 216.58.195.68
Пример, използващ случай, при който записът на CNAME се използва вместо запис:
Dig +Short @8.8.8.8 -4 -t cname www.Microsoft.com www.Microsoft.COM-C-2.EdgeKey.нета.
В този случай CNAME се разрешава на име, което след това можете да разрешите, и следвайте, докато не намерите IP адреса.
Ако някой от междинните CNAME във веригата към вашия краен IP адрес използва DNSSEC, тогава тези домейни също могат да бъдат изследвани за правилна конфигурация.
Заменете “www.Google.com “или” www.Microsoft.com “Със напълно квалифицираното име на Домейн в сървъра на вашия клиент” . “Конфигурация. Вижте какви резултати намирате.
След това опитайте същото спрямо предоставените DNS сървъри на вашия ISP и заменете ценените след „@“ с IP на вашия ISP сървър на ISP. Получавате ли същите резултати?
Ако резултатите не съответстват на това, което виждате от DNS на Google, как са различни? Решава ли е единият IP, докато другият не го прави? Решават ли се към различен IP? Ако е различен, кой е собственик на Netblock на IP адреса, който е неочакван резултат?
След това, инструменти за DNSSEC проверки. По -малко вероятно като причина, но е възможно:
Ако вашият домейн използва делегация с поддомейни, тогава може да се наложи да проверите името на вашия домейн, * и * поддомейни за правилни конфигурации на DNSSEC, чак до, но без да се включва име на хост за всяка делегация на под-домейн с DNSSEC.
За организации, които управляват неща, различни от VPN, те вероятно имат име на хост.домейн.TLD за „сървъра на техния клиент . “Конфигурирайте линии. Посветените доставчици на VPN услуги може да не. Когато завършите вашите DNSSEC проверки, искате да спрете „Името на хоста“ (на всеки) от „сървъра . „Конфигурирайте линия, когато я изпращате на тези два инструмента за пример на DNSSEC. (Така.Google.com “Тогава домейнът за проверка с тези инструменти би бил” Google.com “и почти сигурно не” OpenVPN.Google.com “)
Ако установите, че CNAME са били използвани за други имена в горната стъпка, ще искате да проверите състоянието на DNSSEC на тези домейни и/или поддомейни, докато най-накрая стигнете до IP адрес.
Ако установите, че проблемите, с които се сблъсквате, не са свързани с тези два въпроса (IPv6 адресът е разрешен спрямо IPv4 адреса, разрешен или проблеми с валидирането/конфигурацията на DNSSEC), моля, проследяване казвате така.
Ако установите, че едното или и двете са източник на проблеми, моля, публикувайте и тази информация.
Знаейки какъв е източникът на проблема, би помогнало да се разбере дали това е грешка или не, и ако не, как да го поправите или да го стъпвате.
Не съм имал проблеми с резолюцията на клиента на Comcast или Verizon, или Sprint, или AT&T, когато ги използвах, но използвам правилно конфигурирани домейни, използвайки DNSSEC за моите домейни за валидиране За всяко име и порт на сървъра.
OpenVPN DNS Търсенето не е успешно на хост
VPN 0 Comments
Форум за поддръжка на OpenVPN
VirtualBox.org
DNS Resolve Не работи върху VirtualBox VM, когато VPN е включен на хост
Дискусии, свързани с използването на VirtualBox на хостове на Windows.
5 публикации • Страница 1 на 1
Vnox Постове: 3 Присъединиха: 19. Март 2022, 09:31
DNS Resolve Не работи върху VirtualBox VM, когато VPN е включен на хост
Публикувано от Vnox »19. Март 2022, 09:33
Имам гост на Windows 10 Host и Ubuntu Server на VirtualBox. Имам OpenVPN клиент на хоста на Windows. Гост VM е настроен на Nat Network (не NAT) тип.
Всеки път, когато VPN-клиентът е включен, трафикът от хост се пренасочва чрез сървър, клиентът OpenVPN е свързан с. Но веднага губя търсене/разрешаване на DNS в гост VM (Internet работи добре както в Guest VM & Host, но DNS Resolve се проваля в моя гост VM)
Ако VPN клиентът е изключен, всичко (Интернет, DNS търсене) работи добре в моя хост, гост VM.
Всякакви предложения как да смекчите това?
Редактиране:
Версия на VirtualBox: 6.1.32
Инсталирани добавки за гости, използвайки Intel VT-X
Адаптер: Intel Pro/1000 MT Desktop
Режим PROMISCUSUED: Откажете
FTH0 Доброволец Постове: 5099 Присъединиха: 14. Февруари 2019, 03:06 Първична ОС: Mac OS X други Версия на Vbox: Пуел Оси за гости: Linux, Windows 10, . Местоположение: Германия
Re: DNS Resolve Не работи върху VirtualBox VM, когато VPN е включен на хост
Публикувано от fth0 »19. Март 2022, 10:25
Моля, опитайте 9.8.5. Активиране на DNS прокси в NAT режим и 9.8.6. Използвайки разрешаването на хоста като DNS прокси в NAT режим и ни кажете кой от тях работи за вас и кой не. Тиа.
Форум за поддръжка на OpenVPN
Правила на форума
Моля, използвайте BB маркера [OCONF] за конфигурации OpenVPN. Вижте ViewTopic.php?f = 30 & t = 21589 за пример.
15 публикации • Страница 1 на 1
зима.tal openvpn newbie Постове: 1 Присъединиха: Вторник 01 ноември 2016 г. 19:03
Търсенето на DNS не успя на хост – грешка
Публикувано от зима.Тал »Вторник, 01 ноември 2016 г. 19:08
Опитвам се да вляза в моя VPN от Mac и получавам следната грешка:
Неочаквана грешка: DNS търсенето не е успешно на хост ” [Errno 8] възобновяване, което се предоставя или сервира, или не е известно
Може ли някой да посъветва ?
Tincantech OpenVPN главен герой Постове: 11142 Присъединиха: Пет юни 03, 2016 13:17
Re: DNS търсенето не е успешно на хост – грешка
Публикувано от Tincantech »Вторник 01 ноември 2016 г. 20:29 ч
зима.Тал написа: имена на възли, нито сервиране, предоставено или не известно
Проверете името на вашия сървър.
Джон[email protected] openvpn newbie Постове: 1 Присъединиха: Вторник 17 февруари 2015 г. 22:33
Re: DNS търсенето не е успешно на хост – грешка
Публикувано от Джон[email protected] »Пет 18 ноември 2016 г. 16:10
Предполагам, че отговорът на Tincantech не е помогнал, тъй като имаме проблеми с това сред нашите потребители.
Поддръжката на OpenVPN ме информира, че са виждали проблеми, докладвани от други, като текущият им клиент Mac OpenVPN Connect за Mac OS X и Comcast DNS. Можете да заобиколите този проблем, ако не използвате Comcast DNS на вашия рутер или компютър. Поддръжката на OpenVPN имаше билета ми за това нерешено от 3 октомври.
Странният проблем е, че компютърът, на който е инсталиран клиентът на OpenVPN Connect, няма проблем да разреши DNS за свързване към клиентския уеб интерфейс на сървъра за достъп до OpenVPN. Но когато стартирате клиента OpenVPN Connect и се опитате да се свържете със сървъра за достъп на OpenVPN, клиентът има DNS грешки, решавайки DNS към сървъра за достъп на OpenVPN. Няма регистрационни файлове на сървъра за достъп за това, защото клиентът дори не може да разреши адреса на сървърите за достъп. Изглежда, че нещо не е наред с клиента OpenVPN Connect, ако не може да разреши правилно DNS.
Разочарован и озадачен.
Tincantech OpenVPN главен герой Постове: 11142 Присъединиха: Пет юни 03, 2016 13:17
Re: DNS търсенето не е успешно на хост – грешка
Публикувано от Tincantech »Пет 18 ноември 2016 г. 18:58
Джон[email protected] написа: Поддръжката на OpenVPN ме информира, че са виждали проблеми, докладвани от други, с текущия им Mac OpenVPN Connect Client за Mac OS X и Comcast DNS. Можете да заобиколите този проблем, ако не използвате Comcast DNS на вашия рутер или компютър. Поддръжката на OpenVPN имаше билета ми за това нерешено от 3 октомври.
Ако смятате, че това е грешка с OpenVPN-Connerct, тогава трябва да го докладвате за TRAC за грешки, където можете също да следвате всеки напредък.
Ако смятате, че това е грешка с Comcast DNS, моля, докладвайте им .. И ни уведомете, ако получите идентификационен номер на билета, към който също можем да се свържем и да следваме.
ZEDD45 OpenVPN Newbie Постове: 1 Присъединиха: Сряда на 04 януари 2017 г. 16:17
Re: DNS търсенето не е успешно на хост – грешка
Публикувано от zedd45 »Ср. 04 януари 2017 г. 16:21
Срещнах този проблем след надграждане до Mac OSX Sierra.
Моите колеги не срещнаха този проблем. Две неща, които трябва да се отбележи тук, които може да са допринесли за този проблем, но които не успях да потвърдя къде основната причина за проблема:
1. Моите DNS бяха предоставени чрез AT&T / настройки по подразбиране на ISP
2. DNS за AT&T използва IP6 адрес
Преминах към Google DNS, използвайки следния урок и успях да вляза отново:
https: // разработчици.Google.com/скорост/кръчма . Документи/Използване
Jwilmot OpenVPN Newbie Постове: 1 Присъединиха: Чт 12 януари 2017 г. 22:03
Re: DNS търсенето не е успешно на хост – грешка
Публикувано от Jwilmot »Чт 12 януари 2017 г. 22:05
Само за да потвърдя, решението, предоставено от ZEDD45 (използвайки обществените DNS сървъри на Google), работи за мен. Преди използвах DNS на Comcast и видях този проблем, след като надградих до OSX Sierra.
fuzzymazoid openvpn newbie Постове: 1 Присъединиха: Вторник 28 февруари 2017 г. 16:06
Re: DNS търсенето не е успешно на хост – грешка
Публикувано от Fuzzymazoid »Вторник 28 февруари 2017 г. 16:11
Току -що накарах потребител да се сблъска със същия проблем. Току -що получи нов Mac у дома, а днес беше първият му ден, който се свързва с Office VPN. Симптомите са абсолютно същите като по -горе: най -новата Mac OS, Comcast DNS, “Неочаквана грешка: DNS търсене не е успешно на хост XXXXXXX: [Errno 8] Nodename, нито сервис, предоставен или не известен”
Накарахме го да премине от сървърите на Comcast DNS към Google DNS сървъри и той успя да се свърже без проблем.
Изглежда малко вероятно, че DNS на Comcast е грешен по някакъв начин. Има ли грешка, отчетена за OpenVPN Connect, която можем да проследим?
tmacpherson openvpn newbie Постове: 1 Присъединиха: Чт 09 март 2017 г. 21:45
Re: DNS търсенето не е успешно на хост – грешка
Публикувано от tmacpherson »Чт 09 март 2017 г. 21:52
Имаме същия проблем, докато сте в VerizonWireless Network. На нашите mifi не можем да използваме името DNS за нашия VPN. Работата наоколо е да използвате iPaddress, просто направете nslookup на вашето име DNS, например nslookup myvpndnsname.mydomain.com и това ще ви даде публичния IP на вашия VPN уред. Надяваме се, че това ще бъде отстранено бързо. Имам Comcast у дома, но никога не бих използвал техните DNS в рутера си, винаги използвам публичен DNS
SomeGuy OpenVPN Power User Постове: 62 Присъединиха: Съб 17 декември 2016 г. 1:58 ч
Re: DNS търсенето не е успешно на хост – грешка
Публикувано от Някаква джип »Чт 09 март 2017 г. 22:50
Две предложения, свързани с това.
* IPv4 срещу IPv6, DNS и афинитет на Resolver: Ако стартирате A с конфигурация на клиент OpenVPN, която има ред “сървър” с FQDN (напълно квалифициран-Domain-име), който може да разреши на IPv6 и IPv4 адреси, проверете дали ще видите дали OpenVPN сървърът, на който се опитвате да се свържете с предоставя услуга за IPv4 и IPv6 клиенти. Много разделители в ОС имат афинитет да разрешат DNS AAAA записи през A или CNAME и ще са склонни да предпочитат IPv6 адресите да бъдат разрешени за име на IP, ако има както IPv4, така и IPv6 адреси.
* Домейни, които поддържат DNSSEC: Много от интернет доставчиците се движат, за да прилагат правила на DNSSEC с търсене на име на IP N DNS сървърите * Те * работят за своите клиенти. Ако друго име на домейн е лошо конфигурирано с DNSSEC или има изтекли клавиши, правилно прилагането на DNS сървъри, изпълняващи вашата заявка срещу DNS, които имат DNSSEC конфигуриран, няма да предаде никакви IP адреси на своите клиенти, тъй като резултатите не могат да бъдат валидирани. Някои ISP са експериментирали с частична поддръжка на DNSSEC или пренасочване на Kludgy към уеб страница, която казва на клиента * Web *, че опитът за разрешаване на името на IP е довел до проблеми с DNSSEC. Такава уеб страница не би била видима за „вие“, ако вашият клиент OpenVPN се пренасочи към различен IP от това, което се очаква.
Знам, че Comcast беше рано да експериментира с DNSSEC и да приеме използването на IPv6. Би ли бил някой, който среща проблема, описан в тази тема, моля, проверете дали някой от тези по -горе елементи е източникът на проблеми? Някои предложени методи за тестване са изброени по -долу:
DNS търсене, IPv4 срещу IPv6 или някакъв друг DNS проблем: Ако имате Linux черупка с инсталирана “Dig”.
В тези примери използвам “8.8.8.8 “(IP адреса на IPv4 на публичния DNS Server на Google) и 2001: 4860: 4860 :: 8888 (IP адреса на IPv6 на Google Server на Google.)
“-4” казва, използвайте моя IPV IP адрес и се свържете с IPv4 адреса на сървъра (полезно, ако използвате имена, вместо IP адреси, за които DNS сървър искате да използвате), а “-6” Използвайте IPv6 IP адрес на моята машина, за да говоря с DNS, работещ с IPv6 адрес. (Използване на IPv4 адрес за DNS след “@” вече изисква IPv4 имплицитно, но включително в случай, че замените стойността след “@” с име.)
“А” е условно запис за име на IPv4 адрес.
“AAAA” е запис за име на IPv6 адрес.
Заявка IPv6 DNS сървър на Google и поискайте запис на AAAA (IPv6 адрес, ако има такъв) за името на хоста “www.Google.com “:
Въведете IPv4 DNS сървър на Google и поискайте запис (IPv4 адрес, ако има такъв) за името на хоста “www.Google.com “:
Пример, използващ случай, при който записът на CNAME се използва вместо запис:
В този случай CNAME се разрешава на име, което след това можете да разрешите, и следвайте, докато не намерите IP адреса.
Ако някой от междинните CNAME във веригата към вашия краен IP адрес използва DNSSEC, тогава тези домейни също могат да бъдат изследвани за правилна конфигурация.
Заменете “www.Google.com “или” www.Microsoft.com “Със напълно квалифицираното име на Домейн в сървъра на вашия клиент” . “Конфигурация. Вижте какви резултати намирате.
След това опитайте същото спрямо предоставените DNS сървъри на вашия ISP и заменете ценените след „@“ с IP на вашия ISP сървър на ISP. Получавате ли същите резултати?
Ако резултатите не съответстват на това, което виждате от DNS на Google, как са различни? Решава ли е единият IP, докато другият не го прави? Решават ли се към различен IP? Ако е различен, кой е собственик на Netblock на IP адреса, който е неочакван резултат?
След това, инструменти за DNSSEC проверки. По -малко вероятно като причина, но е възможно:
Ако вашият домейн използва делегация с поддомейни, тогава може да се наложи да проверите името на вашия домейн, * и * поддомейни за правилни конфигурации на DNSSEC, чак до, но без да се включва име на хост за всяка делегация на под-домейн с DNSSEC.
За организации, които управляват неща, различни от VPN, те вероятно имат име на хост.домейн.TLD за „сървъра на техния клиент . “Конфигурирайте линии. Посветените доставчици на VPN услуги може да не. Когато завършите вашите DNSSEC проверки, искате да спрете „Името на хоста“ (на всеки) от „сървъра . „Конфигурирайте линия, когато я изпращате на тези два инструмента за пример на DNSSEC. (Така.Google.com “Тогава домейнът за проверка с тези инструменти би бил” Google.com “и почти сигурно не” OpenVPN.Google.com “)
Ако установите, че CNAME са били използвани за други имена в горната стъпка, ще искате да проверите състоянието на DNSSEC на тези домейни и/или поддомейни, докато най-накрая стигнете до IP адрес.
Ако установите, че проблемите, с които се сблъсквате, не са свързани с тези два въпроса (IPv6 адресът е разрешен спрямо IPv4 адреса, разрешен или проблеми с валидирането/конфигурацията на DNSSEC), моля, проследяване казвате така.
Ако установите, че едното или и двете са източник на проблеми, моля, публикувайте и тази информация.
Знаейки какъв е източникът на проблема, би помогнало да се разбере дали това е грешка или не, и ако не, как да го поправите или да го стъпвате.
Не съм имал проблеми с резолюцията на клиента на Comcast или Verizon, или Sprint, или AT&T, когато ги използвах, но използвам правилно конфигурирани домейни, използвайки DNSSEC за моите домейни за валидиране За всяко име и порт на сървъра.
TEEC OpenVPN Newbie Постове: 1 Присъединиха: Вторник 09 май 2017 г. 12:59
Re: DNS търсенето не е успешно на хост – грешка
Публикувано от Teec »Вторник 09 май 2017 г. 13:01
Имали ли сте актуализации по този проблем? Това ми пречи да имам достъп до работата ми VPN от вкъщи. Да, промяната на Google DNS помага, но след това завинтва DNS, докато е на работа, така че не искам да продължавам да превключвам напред -назад. Този брой възникна само за мен след надграждане до OSX Sierra..
maxigs openvpn newbie Постове: 1 Присъединиха: Сряда 17 май 2017 г. 8:51
Re: DNS търсенето не е успешно на хост – грешка
Публикувано от Максигс »Ср. 17 май 2017 г. 8:54
Още един тук. Вчера надградих до Сиера и имам същия проблем, който сега се опитвах да вляза в компанията VPN.
Засега го „поправих“, като добавя името на хоста към моя /etc /хост файл, за да го прескочите. Това изглежда работи засега, не е идеално, но IP рядко се променя, за да мога да живея с него.
VCardillo OpenVPN Newbie Постове: 1 Присъединиха: Пон 22 май 2017 г. 21:00 ч
Re: DNS търсенето не е успешно на хост – грешка
Публикувано от VCardillo »Пон 22 май 2017 г. 21:03
Същият проблем, с продукта на сървъра за достъп.
Gushi OpenVPN Newbie Постове: 2 Присъединиха: Сряд 19 юли 2017 г. 12:38 ч
Re: DNS търсенето не е успешно на хост – грешка
Публикувано от Гуши »Сряда 19 юли 2017 г. 12:41
Не, и ние използваме уреда с платен лиценз (което означава на теория, че нашите проблеми трябва да получат някаква поддръжка).
Заснех пакети от моя Mac, правейки DNS търсене и изрично исках AAAA запис на моя локален DNS сървър. След това връзката се проваля, вместо да се върне към искане за запис.
Лорънс.Henry OpenVPN Newbie Постове: 1 Присъединиха: Пет септември 01, 2017 13:11
Re: DNS търсенето не е успешно на хост – грешка
Публикувано от Лорънс.Хенри »Пет септември 01, 2017 13:15
И така, следвайки тази обща тема от съвети – преживяхме този проблем с някои от нашите потребители на Mac на определени интернет доставчици. Ние деактивирахме IPv6 на Macs, имайки проблема и той “отстрани” проблема.
Вижте бележките по-долу, за да деактивирате и активирате отново IPv6:
Изключване на IPv6 поддръжка за Ethernet:
Networksetup -setv6off ethernet
Деактивиране на IPv6 за безжична връзка:
Networksetup -setv6off Wi -Fi
Можете също да комбинирате и двете команди в един низ, за да деактивирате както безжичната, така и Ethernet, просто използвайте следния синтаксис:
networksetup -setv6off ethernet && networksetup -setv6off wi -fi
Не забравяйте да въведете този низ в един ред, за да издадете правилно командата.
Възстановяване на IPv6 за Wi-Fi & Ethernet в OS x
Разбира се, е възможно и обърнато на горната промяна и можете да отново активирате IPv6 поддръжка със следните командни низове, въведени в терминала:
Networksetup -setv6automatic Wi -Fi
Networksetup -setv6automatic Ethernet
Можете също така да поставите това в една команда, за да се активира IPv6 за Wi-Fi и Ethernet така:
networksetup -setv6automatic wi -fi && networksetup -setv6automatic ethernet
SomeGuy написа: Две предложения, свързани с това.
* IPv4 срещу IPv6, DNS и афинитет на Resolver: Ако стартирате A с конфигурация на клиент OpenVPN, която има ред “сървър” с FQDN (напълно квалифициран-Domain-име), който може да разреши на IPv6 и IPv4 адреси, проверете дали ще видите дали OpenVPN сървърът, на който се опитвате да се свържете с предоставя услуга за IPv4 и IPv6 клиенти. Много разделители в ОС имат афинитет да разрешат DNS AAAA записи през A или CNAME и ще са склонни да предпочитат IPv6 адресите да бъдат разрешени за име на IP, ако има както IPv4, така и IPv6 адреси.
* Домейни, които поддържат DNSSEC: Много от интернет доставчиците се движат, за да прилагат правила на DNSSEC с търсене на име на IP N DNS сървърите * Те * работят за своите клиенти. Ако друго име на домейн е лошо конфигурирано с DNSSEC или има изтекли клавиши, правилно прилагането на DNS сървъри, изпълняващи вашата заявка срещу DNS, които имат DNSSEC конфигуриран, няма да предаде никакви IP адреси на своите клиенти, тъй като резултатите не могат да бъдат валидирани. Някои ISP са експериментирали с частична поддръжка на DNSSEC или пренасочване на Kludgy към уеб страница, която казва на клиента * Web *, че опитът за разрешаване на името на IP е довел до проблеми с DNSSEC. Такава уеб страница не би била видима за „вие“, ако вашият клиент OpenVPN се пренасочи към различен IP от това, което се очаква.
Знам, че Comcast беше рано да експериментира с DNSSEC и да приеме използването на IPv6. Би ли бил някой, който среща проблема, описан в тази тема, моля, проверете дали някой от тези по -горе елементи е източникът на проблеми? Някои предложени методи за тестване са изброени по -долу:
DNS търсене, IPv4 срещу IPv6 или някакъв друг DNS проблем: Ако имате Linux черупка с инсталирана “Dig”.
В тези примери използвам “8.8.8.8 “(IP адреса на IPv4 на публичния DNS Server на Google) и 2001: 4860: 4860 :: 8888 (IP адреса на IPv6 на Google Server на Google.)
“-4” казва, използвайте моя IPV IP адрес и се свържете с IPv4 адреса на сървъра (полезно, ако използвате имена, вместо IP адреси, за които DNS сървър искате да използвате), а “-6” Използвайте IPv6 IP адрес на моята машина, за да говоря с DNS, работещ с IPv6 адрес. (Използване на IPv4 адрес за DNS след “@” вече изисква IPv4 имплицитно, но включително в случай, че замените стойността след “@” с име.)
“А” е условно запис за име на IPv4 адрес.
“AAAA” е запис за име на IPv6 адрес.
Заявка IPv6 DNS сървър на Google и поискайте запис на AAAA (IPv6 адрес, ако има такъв) за името на хоста “www.Google.com “:
Въведете IPv4 DNS сървър на Google и поискайте запис (IPv4 адрес, ако има такъв) за името на хоста “www.Google.com “:
Пример, използващ случай, при който записът на CNAME се използва вместо запис:
В този случай CNAME се разрешава на име, което след това можете да разрешите, и следвайте, докато не намерите IP адреса.
Ако някой от междинните CNAME във веригата към вашия краен IP адрес използва DNSSEC, тогава тези домейни също могат да бъдат изследвани за правилна конфигурация.
Заменете “www.Google.com “или” www.Microsoft.com “Със напълно квалифицираното име на Домейн в сървъра на вашия клиент” . “Конфигурация. Вижте какви резултати намирате.
След това опитайте същото спрямо предоставените DNS сървъри на вашия ISP и заменете ценените след „@“ с IP на вашия ISP сървър на ISP. Получавате ли същите резултати?
Ако резултатите не съответстват на това, което виждате от DNS на Google, как са различни? Решава ли е единият IP, докато другият не го прави? Решават ли се към различен IP? Ако е различен, кой е собственик на Netblock на IP адреса, който е неочакван резултат?
След това, инструменти за DNSSEC проверки. По -малко вероятно като причина, но е възможно:
Ако вашият домейн използва делегация с поддомейни, тогава може да се наложи да проверите името на вашия домейн, * и * поддомейни за правилни конфигурации на DNSSEC, чак до, но без да се включва име на хост за всяка делегация на под-домейн с DNSSEC.
За организации, които управляват неща, различни от VPN, те вероятно имат име на хост.домейн.TLD за „сървъра на техния клиент . “Конфигурирайте линии. Посветените доставчици на VPN услуги може да не. Когато завършите вашите DNSSEC проверки, искате да спрете „Името на хоста“ (на всеки) от „сървъра . „Конфигурирайте линия, когато я изпращате на тези два инструмента за пример на DNSSEC. (Така.Google.com “Тогава домейнът за проверка с тези инструменти би бил” Google.com “и почти сигурно не” OpenVPN.Google.com “)
Ако установите, че CNAME са били използвани за други имена в горната стъпка, ще искате да проверите състоянието на DNSSEC на тези домейни и/или поддомейни, докато най-накрая стигнете до IP адрес.
Ако установите, че проблемите, с които се сблъсквате, не са свързани с тези два въпроса (IPv6 адресът е разрешен спрямо IPv4 адреса, разрешен или проблеми с валидирането/конфигурацията на DNSSEC), моля, проследяване казвате така.
Ако установите, че едното или и двете са източник на проблеми, моля, публикувайте и тази информация.
Знаейки какъв е източникът на проблема, би помогнало да се разбере дали това е грешка или не, и ако не, как да го поправите или да го стъпвате.
Не съм имал проблеми с резолюцията на клиента на Comcast или Verizon, или Sprint, или AT&T, когато ги използвах, но използвам правилно конфигурирани домейни, използвайки DNSSEC за моите домейни за валидиране За всяко име и порт на сървъра.