OpenVPN ръкостискане на Synology се проваля? Проверете препращането в LAN

Лаптопът ви съобщава, че TLS ръкостискането се е провалило, затова изкушението е да преизградите сертификатите. Преди това задайте по-скучния въпрос: на кой Ethernet порт всъщност слуша Synology? NAS с два LAN порта има два адреса и пакетът VPN Server в DSM обвързва OpenVPN слушателя си с един от тях. Когато рутерът препраща 1194 към другия адрес, нито един пакет не стига до услугата и клиентът няма с какво да преговаря.

Текстът на грешката подвежда, защото описва последното, което клиентът е опитал, а не първото, което се е объркало. Две минути сравнение на страницата на пакета с правилото на рутера решават въпроса.

Намерете адреса, към който е обвързан слушателят

DSM означава портовете си като LAN 1 и LAN 2 и всеки носи отделен адрес и подмрежа. Отворете VPN Server, прочетете интерфейса, посочен в раздела OpenVPN, след това отворете Контролен панел и запишете IPv4 адреса, който DSM има на същия интерфейс. Именно тези две стойности, а не името на хоста на NAS, трябва да посочи препращането.

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

Погледнете самия сокет през SSH, защото това е единственото място, което показва към какво демонът действително се е обвързал, а не какво има предвид страницата с настройки.

sudo netstat -anp | grep 1194

Редактирайте съществуващото препращане, вместо да добавяте ново

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

external 1194/udp  ->  192.0.2.20:1194/udp

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

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

Докажете дали пакетите изобщо пристигат

Първо стартирайте прихващане на NAS, след това се свържете от клиента и прочетете адреса на източника в изхода. Прихващане, стартирано след провала, не показва нищо и не доказва нищо.

sudo tcpdump -i any -n udp port 1194

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

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

Щом пакетите пристигат, спрете да обвинявате препращането

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

Транспортът е другото несъответствие, което си струва да се провери изрично, защото профилът и пакетът се редактират на различни места. Смяната на профил от UDP на TCP без превключване на пакета оставя клиента да чака слушател, който не съществува, и клиентът съобщава същия общ текст за ръкостискане, който съобщава за всичко останало. Прочетете реда proto във файла, след това вижте протокола, избран на страницата на сървъра, и само тогава заключете, че съвпадат. Четенето на правилата на защитната стена на DSM е третата проверка: правило, което разрешава порта от локалната подмрежа, но не от интернет, лесно се забравя след тестване и то дава връзка, която работи от кухнята и се проваля навсякъде другаде.

Тествайте пътя, който отдалечен потребител наистина изминава

Клиент в същата LAN може да достигне NAS, без изобщо да докосва препращането, така че това не доказва нищо за отдалечения достъп. Използвайте телефон с изключен Wi-Fi или помолете някого извън мрежата и наблюдавайте брояча на рутера по време на този опит. Ако отдалеченият опит се провали, докато локалният успее, препращането или защитната стена все още са в картината.

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