Кораци VPN руковања: шта се дешава пре него што крене саобраћај

Клик на Повежи покреће четири одвојена посла који успевају или не успевају независно. Клијент мора стићи до ослушкивача, договорити ко је саговорник, извести кључеве и затим предати исправан тунел остатку система. Већина неуспелих веза дијагностикује се у погрешном послу. Зато је прва грешка важнија од трећег покушаја.

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

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

Истек времена, одбијање сертификата и одбијен налог три су различита квара са три различите провере. Њихово прво раздвајање спречава да се мрежни проблем исправља као проблем акредитива.

Докажите саговорника, затим изведите кључеве

Сваки протокол треба начин да препозна предвиђени сервер, било кроз подешени јавни кључ или ланац сертификата. Пријава корисника је додатак тој провери, а не њена замена. Сервер који прихвати вашу лозинку није доказао ништа о сопственом идентитету. Зато заједничка тајна откуцана у клијенту није замена за проверу ко је одговорио.

Размена затим изводи кључеве саобраћаја из сопствених улаза протокола, а лозинка за пријаву обично није кључ који се утискује на сваки пакет. Дугорични идентитетски материјал и краткотрајни сесијски кључеви имају различит животни век и различите задатке. Управо о том раздвајању говори унапредна тајност.

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

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

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

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

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

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

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

Радите фазе горе наведеним редом и зауставите се на првој која произведе грешку. Свака каснија фаза наслеђује стање претходних, па неуспех у трећој фази не говори ништа о четвртој.

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