Нов клиент на хотспот заглавен на добивање IP не е дефект на VPN

Телефонот се поврзува со хотспотот, стои на „Добивање IP адреса“ и на крајот се откажува. Природниот заклучок е дека VPN-от на телефонот го попречува DNS, па луѓето почнуваат да ги уредуваат резолверите и додадените правила. Тоа е погрешна фаза. Клиентот никогаш не добил локална адреса, а без неа нема порта, нема резолвер и нема што да препрати, така што ниту едно поставување на VPN на телефонот домаќин не може да го објасни дефектот. Поврзувањето, доделувањето локална адреса и препраќањето се три одделни фази, и само последната го вклучува тунелот.

Трите фази и во која сте

Прво доаѓа поврзувањето: клиентот се поврзува со безжичната мрежа на хотспотот. Погрешна лозинка, несовпаѓање на WPA3 или проблем со радиокомпатибилност паѓаат овде, и клиентот обично го кажува тоа. Второ е доделувањето адреса: за IPv4 клиентот бара закуп и добива адреса плус локални поставувања на портата, додека IPv6 обично користи најави од рутерот наместо DHCP, како што опишува документацијата на AOSP за tethering. Трето е пристапот кон надвор: телефонот домаќин го препраќа дозволениот сообраќај кон избраниот пат нагоре, кој може, но не мора да биде неговиот тунел.

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

Мит: рутиран VPN го претвора локалниот DHCP во далечинско барање

Рутираниот тунел пренесува IP пакети за одредиштата што ги избира. Откривањето на DHCP е емитување во сопствениот сегмент на хотспотот, а услугата tethering на телефонот одговара локално, затоа клиентот може да добие адреса додека тунелот е активен. Само намерно премостен или препратен дизајн ја испраќа таа размена на друго место, и тоа е друг распоред со различен потпис на дефект.

Значи „VPN серверот не одговара на DHCP“ не е дијагноза, туку грешка во моделот. Локалниот посредник е на телефонот. Ако престане да одговара, причините се локални: услугата tethering, ограничувањето на клиенти, базенот за закуп или клиент што никогаш не го завршил поврзувањето како што треба. Ништо од тоа не живее на далечната страна на тунелот.

Што всушност докажува работечки постоечки клиент

Ако преносен компјутер што веќе бил поврзан уште работи, а новиот телефон не, хотспотот и патот нагоре се во основа живи. Таа споредба е корисна и не е доказ кој дел е виновен, бидејќи работечкиот клиент може едноставно да држи закуп од пред промената и тивко да го обновува.

Вреди да се проверат две локални граници додека сте таму. Хотспотот служи конечен базен за закуп и конфигурабилно ограничување на клиенти, па уред што се поврзал и заспал може да држи адреса додека нов чека. А клиент што памети статична конфигурација од друга мрежа воопшто нема да побара закуп, што однадвор изгледа исто и се поправа на клиентот, не на телефонот.

Држете ја споредбата локална и повратна

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

Доследен дефект на закупот зависен од тунелот е корисен доказ за локална политика или интеракција на имплементации. Тоа не е лиценца да ги избришете сите правила за препраќање и NAT на уредот. Тие правила заштитуваат неповрзан сообраќај, а широкото дозволување на препраќање не објаснува зошто локалната DHCP услуга престанала да одговара.

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

Што не докажува закупот

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

Работете ги фазите по ред и дефектот престанува да се преместува. Клиент заглавен на добивање адреса е локално прашање на tethering; клиент со адреса и без страници е прашање на препраќање или именување; клиент со страници и погрешен излез е прашање на покриеност на тунелот. Нивното одвојување е најголемиот дел од отстранувањето на грешки.