Таймаут на VPN връзка: DNS, транспорт, договаряне или вход

„Връзката изтече“ е най-неконкретната грешка, която VPN клиент може да отпечата. Тя означава, че една операция е пропуснала крайния си срок, а всеки етап от разрешаването на името до отговора при вход има срок. Клиентите, които показват само последното съобщение, правят етапите да изглеждат еднакви, затова хората увеличават таймаута, сменят порта и преинсталират профила, в този ред, без да научат нищо. Сравняването на етапите е по-бързо: всеки се проваля на различно място и всеки провал оставя различен вид доказателство.

Четири етапа, четири различни провала

Последователността е фиксирана дори когато клиентът я скрива: името трябва да се разреши, към получения адрес трябва да се установи транспорт, протоколът трябва да договори своите параметри и ключове, а акаунтът трябва да бъде удостоверен. Ръководството на OpenVPN за отстраняване на проблеми с връзката следва същия ред за собствения си клиент, а останалите го следват отблизо. Таймаут на втори етап и таймаут на четвърти етап нямат нищо общо освен думата на екрана.

Четете журнала за последния ред, който показва напредък, а не последния ред преди грешката. Повечето клиенти отпечатват нещо като разрешен адрес, установен сокет, започнало ръкостискане или заявка за удостоверяване, и етапът след този ред е този, който е изтекъл.

Разрешаването на име се проваля преди всякакъв контакт

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

Стар адрес, копиран от форумна публикация, е честа причина за таймаут, който изглежда като сървърен проблем, защото адресът сега принадлежи на нещо друго или на нищо. Използвайте текущия профил на оператора вместо да подменяте адрес, който е работил преди. Липсата на отговор на ping не е доказателство в нито една посока: много крайни точки изпускат ICMP, докато обслужват напълно добре.

Настройката на транспорта чака пакет, който няма да дойде

Когато DNS е наред и клиентът все пак изразходва целия таймаут, заподозрян е транспортният слой. При TCP можете да тествате порта директно; Test-NetConnection под Windows или nc -vz под Linux ви казва дали нещо приема връзката, и това е по-полезно от ping. При UDP не можете да тествате по същия начин, защото на този слой няма ръкостискане, което да завърши, и тази асиметрия поражда много погрешни изводи.

Това, което доказва TCP тестът, е ограничено: услуга, която приема порт 443, не е непременно VPN слушателят, а крайна точка само с UDP няма TCP порт, за да приеме каквото и да е. Пренаписването на профил от UDP на TCP не създава слушател от другата страна; то само променя какво чака вашият клиент. Ако мрежата филтрира протокола, промяната произвежда различен таймаут на същия етап.

Порталите за прихващане заслужават отделна проверка на този етап. Докато порталът не упълномощи устройството, изходящият трафик отива към портала и опитът за тунел просто виси. Първо завършете портала в браузър, после опитайте отново и не променяйте профила, докато порталът е все още в очакване.

Договарянето и входът означават, че сървърът е отговорил

Щом тунелът достигне сървъра, клиентът започва ръкостискане и грешката променя характера си. Застойът тук е за съвместимост, а не за достижимост: несъвпадащи версии на протокола, настройка за шифър или канал за данни, която другата страна няма да приеме, или профил, който очаква функция, която сървърът не предлага. OpenVPN променяше настройките си по подразбиране за договаряне между основни версии достатъчно често, че профил, написан за едно поколение, може да достигне сървъра и все още да не се вдигне.

Удостоверяването е последният етап и най-лесният за погрешно четене. Изричното отхвърляне е отговор, което означава, че пътят работи и проблемът е идентичността, сертификатът или състоянието на акаунта. Поток за единен вход през браузър е трети случай: клиентът чака действие, което не сте предприели, или браузър, който не може да стартира, и нищо няма да дойде, докато не завършите тази стъпка.

Сравнете доказателствата, преди да промените повторението

Дръжте устройството и профила фиксирани и променяйте по едно нещо наведнъж, като започнете с мрежата. Ако същият профил се свързва през мобилна точка и изтича в Wi-Fi на хотел, променливата е пътят, а не сървърът. Ако се проваля навсякъде, променливата е профилът или крайната точка. Ако се проваля само в определен час от деня, запишете клеймото за време и го сравнете със събития от страна на сървъра, преди да предполагате нещо за натоварването.

За услуга, която администрирате, решаващото сравнение е дали опитът изобщо пристига. Връзка, която достига слушателя и после застоява, принадлежи на етапа на договаряне; тази, която никога не се появява в погледа на слушателя, е транспортен или резолверен проблем и никаква настройка на повторението няма да го помръдне. Сървърните журнали също разделят отхвърлен вход от тихо изпускане, което е разликата между поправка на идентичност и поправка на защитна стена.

Запишете версията на клиента, името на профила, времето на опита с часовата му зона и първата полезна грешка вместо последния ред за прекъсване. Премахнете ключовете и материала с идентификационни данни, преди да споделите извадката. След това направете една смислена корекция и опитайте отново, защото по-дълъг срок помага само на документираната бавна операция и не прави нищо за грешен адрес или блокиран порт.