Чекори на VPN-ракување: што се случува пред да потече сообраќајот

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

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

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

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

Докажете го партнерот, потоа изведете клучеви

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

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

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

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

Во OpenVPN распоредување засновано на TLS контролниот канал преговара за безбедносните параметри, додека податочниот канал го носи сообраќајот на тунелот, па опцијата на податочниот канал и проблемот со сертификатот живеат на различни места. IKEv2 ги автентицира двата учесника и потоа воспоставува IPsec безбедносни асоцијации со сопствени рокови. WireGuard изведува клучеви преку својата размена заснована на Noise и намерно ја држи машината на состојби мала. Знаењето кој од трите го работите одлучува кој дневник вреди да се чита.

Слично изгледачки клиенти не значат заменливи пораки под нив, а поле за конфигурација што постои во еден производ може да нема пандан во друг. Копирањето профил меѓу нив е претпоставка, а не миграција.

Што не прави ракувањето

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

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

Работете ги фазите по горниот ред и застанете на првата што произведува грешка. Секоја подоцнежна фаза го наследува состојбата на претходните, па неуспехот во третата фаза не кажува ништо за четвртата.

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