Synology NAS med två LAN-portar: varför VPN-handskakningen misslyckas

Den bärbara datorn rapporterar ett TLS-handskakningsfel, vilket låter som ett certifikatproblem och oftast inte är det. På en NAS med två Ethernet-portar är den vanligaste orsaken en router-vidarebefordran riktad mot adressen som paketet inte lyssnar på, och klientens meddelande är identiskt i båda fallen. Paketet svarar inte på den andra porten bara för att båda kablarna är inkopplade. Innan någon utfärdar ett certifikat igen ska ni bevisa att ett paket överhuvudtaget når NAS:en.

Vad klienten rapporterar och vad som faktiskt hände

Ett handskakningsfel från en OpenVPN-klient är ett samlingsbegrepp. Det täcker avvikelse i certifikat, avvikelse i transport, en lyssnare på en annan port och en vidarebefordran som inte levererade något. Därför är meddelandet oanvändbart som utgångspunkt och användbart bara som bekräftelse. Behandla det som ett påstående att sessionen inte upprättades, och inget mer specifikt.

Porten och den bundna adressen är de två fakta som avgör om ett paket någonsin anländer.

Skriv ner båda innan ni ändrar något, för en trolig rättelse tillämpad på fel lager är vägen där ett problem på femton minuter blir en hel eftermiddag. Notera gränssnittet, adressen på det, porten och transporten. Dessa fyra värden utgör hela den inkommande vägen, och nästa avsnitt förklarar var var och en av dem bor.

Hitta adressen som paketet lyssnar på

DSM numrerar Ethernet-portarna och varje port bär sin egen adress. Sidan VPN Server anger gränssnittet som OpenVPN-tjänsten använder, och nätverkspanelen visar adressen som är konfigurerad på det gränssnittet. Läs dem i den ordningen, från tjänsten och utåt, så att ni beskriver det som lyssnar i stället för det ni antar att den borde använda.

Tjänsten binder en adress. Att båda portarna är anslutna och aktiva gör inte att tjänsten svarar på den andra. En statisk adress på det ena gränssnittet bredvid en DHCP-adress på det andra ger er två liknande värden som lätt förväxlas vid en blick, särskilt när de bara skiljer sig i sista oktetten. Kopiera adressen från panelen i stället för att skriva den ur minnet. Bekräfta sedan på NAS:en vad som faktiskt är bundet till porten.

sudo ss -lunp | grep 1194

Om den utskriften anger en adress ni inte förväntade er, är vidarebefordran riktad mot fel gränssnitt och allt annat här är bokföring. Rätta regeln innan ni läser vidare, annars slutar ni med att felsöka ett certifikat på grund av ett paket som aldrig lämnade routern.

Reparera vidarebefordran och håll sedan ögonen på räknaren

Redigera den befintliga vidarebefordringsregeln i stället för att lägga till en ny för samma externa port. Två regler kan finnas sida vid sida i en routers tabell och bara en vinner någonsin, vilket gör en felsökningssession till en diskussion om vilken som är den riktiga. Peka den interna adressen mot värdet ni läste från NAS:en och låt den interna porten matcha det tjänsten lyssnar på.

Om DSM får den adressen via DHCP ska ni först skapa en reservation. En ändring av lånet bryter tyst en vidarebefordran som fungerade i går.

sudo tcpdump -i any -n udp port 1194

Börja fånga innan klienten försöker ansluta och läs källadressen i allt som dyker upp. Ingenting alls betyder att något på vägen kastade det: vidarebefordran, DSM:s brandvägg eller gränssnittet det var riktat mot, och certifikat kan inte vara orsaken så länge det gäller. Något som kommer från klientens offentliga adress utan svar betyder att NAS:en tog emot begäran och valde att inte svara. Det är olika fynd, och bara det andra skickar er tillbaka till paketets egna inställningar.

Först då tittar ni på certifikat och transport

När paketen anländer ska ni exportera profilen igen efter varje certifikatändring, eftersom den gamla filen fortfarande bär den utfärdare den skapades med. En profil som redigerats för hand för en annan transport låter klienten vänta på en lyssnare som inte finns, och den rapporterar samma generiska fel som allt annat. Jämför transporten i profilen med den transport som paketet är inställt att betjäna. Två profiler för två transporter är en legitim design, och en profil redigerad för båda är det inte.

Testa utifrån ert eget nätverk som sista steg, eftersom en anslutning inifrån LANet kan lyckas via en väg som aldrig rör vidarebefordran.

Håll den exporterade profilen, gränssnittets adress och vidarebefordringsregeln tillsammans i en anteckning. När en adress ändras är den anteckningen skillnaden mellan en reparation och en repris. Ingenting på den här vägen krävde en ominstallation av ett paket, vilket är värt att komma ihåg innan nästa omstart får skulden.