OpenVPN ракување на Synology не успева? Проверете го пренасочувањето на LAN
На NAS со два порта VPN пакетот слуша на еден интерфејс. Пренасочување кон другата адреса дава TLS грешка при ракување што ниту еден сертификат не ја исправа.
Вашиот лаптоп известува дека 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 или прашајте некого надвор од мрежата, и гледајте го бројачот на рутерот за време на тој обид. Ако далечинскиот обид не успее додека локалниот успее, пренасочувањето или огнениот ѕид сѐ уште се во игра.
Запишете ја работната состојба додека работи: надворешен порт, внатрешна адреса, протокол, интерфејс на пакетот, како и името на профилот и датумот на извоз. Кога ракувањето повторно ќе не успее, разликата меѓу таа белешка и тековната конфигурација е дефектот, и никој не мора повторно да открива кој од двата порта го користи услугата.