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

Първо достигнете до слушателя

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

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

Докажете партньора, после изведете ключове

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

След това обменът извежда ключове за трафика от собствените входове на протокола и паролата за влизане обикновено не е ключът, който се слага на всеки пакет. Дългосрочният материал за самоличност и краткотрайните сесийни ключове имат различен живот и различни задачи. Именно за това разделение става дума при пряката секретност.

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

Три протокола, три разговора

При OpenVPN разгръщане на базата на TLS контролният канал договаря параметрите за сигурност, докато каналът за данни носи трафика на тунела, така че опция на канала за данни и проблем със сертификат живеят на различни места. IKEv2 удостоверява и двамата участници и след това установява асоциации за сигурност IPsec със собствени срокове. WireGuard извежда ключове чрез своя обмен на базата на Noise и нарочно държи машината на състоянията малка. Знанието кой от трите управлявате решава кой журнал си струва да се чете.

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

Какво ръкостискането не прави

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

Обновяването на ключове и повторното свързване също изглеждат еднакво в повечето индикатори за състояние и нито едно от двете не ви казва дали обикновеният трафик е бил блокиран по време на прекъсването. Само политиката за отказ на клиента отговаря на този въпрос, затова четете политиката, а не иконата.

Изпълнете етапите в горния ред и спрете на първия, който даде грешка. Всеки следващ етап наследява състоянието на предишните, така че провал на третия етап не казва нищо за четвъртия.

ip -brief address show tun0
ip route get 10.60.7.15
resolvectl query intranet.corp.internal

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