OpenVPN-handskakning på Synology misslyckas? Kontrollera LAN-vidarebefordran

Din bärbara dator rapporterar att TLS-handskakningen misslyckades, så frestelsen är att bygga om certifikaten. Fråga först något tråkigare: vilken Ethernet-port lyssnar Synology egentligen på? En NAS med två LAN-portar har två adresser, och DSMs VPN Server-paket binder sin OpenVPN-lyssnare till en av dem. När routern vidarebefordrar 1194 till den andra adressen når inget paket någonsin tjänsten, och klienten har inget att förhandla med.

Feltexten vilseleder eftersom den beskriver det sista klienten försökte, inte det första som gick fel. Två minuter att jämföra paketsidan med routerregeln avgör saken.

Hitta adressen som lyssnaren är bunden till

DSM kallar sina portar LAN 1 och LAN 2, och var och en bär en egen adress och ett eget subnät. Öppna VPN Server, läs gränssnittet som nämns på fliken OpenVPN, öppna sedan Kontrollpanelen och anteckna IPv4-adressen som DSM har på samma gränssnitt. Det är dessa två värden, inte NAS:ens värdnamn, som vidarebefordran måste namnge.

En extra ansluten kabel skapar ingen extra lyssnare. Båda länkarna kan visas som anslutna medan bara en adress tar emot trafiken, och när båda gränssnitten ligger i samma subnät skiljer sig de två adresserna med en siffra som ingen läser om innan en regel sparas.

Titta på själva socketen via SSH, för det är den enda platsen som visar vad daemonen faktiskt band sig till, i stället för vad inställningssidan avser.

sudo netstat -anp | grep 1194

Redigera den befintliga vidarebefordran i stället för att lägga till en ny

Två regler för en extern port lämnar routern fri att välja, och vilken den väljer kan ändras efter en firmwareuppdatering eller en omstart. Öppna regeln som redan finns, ändra dess interna adress, spara, öppna den sedan igen och läs av värdet. Det hjälper att namnge regeln efter tjänsten, för en lista med fem identiska vidarebefordringar är sättet den felaktiga överlever på.

external 1194/udp  ->  192.0.2.20:1194/udp

Håll den interna porten lika med lyssnarporten och håll protokollet konsekvent. UDP 1194 är standardlyssnaren, medan en TCP-profil behöver en egen lyssnare på paketsidan och en motsvarande vidarebefordran i routern. Att vidarebefordra TCP till en tjänst som bara lyssnar på UDP ger tystnad, inte ett fel.

Om NAS:ens adress kommer från DHCP ska du reservera den innan regeln sparas. När lånet löper ut tilldelas adressen på nytt, vidarebefordran pekar fortfarande på det gamla värdet, och handskakningen börjar misslyckas en dag då ingen rörde NAS:en. En statisk konfiguration på NAS-sidan löser samma problem, förutsatt att adressen ligger utanför routerns DHCP-intervall.

Bevisa om paketen överhuvudtaget kommer fram

Starta först en inspelning på NAS:en, anslut sedan från klienten och läs källadressen i utdata. En inspelning som startas efter felet visar ingenting och bevisar ingenting.

sudo tcpdump -i any -n udp port 1194

Tystnad betyder att trafiken dog före tjänsten: en felaktig intern adress, en stängd port i DSMs brandvägg eller ett gränssnitt som är administrativt nere. Paket i utdata betyder att vidarebefordran fungerar, och det återstående felet ligger ovanför nätverkslagret, vilket är ett mycket mindre sökområde.

Inspelningen namnger också gränssnittet som paketet kom in på, och just den detaljen skiljer en regel riktad mot fel port från en regel riktad mot en port som inte är uppe. Följ routerns egen räknare under samma försök om den visar en. En räknare som inte rör sig medan inspelningen förblir tom pekar på routern, medan en räknare som rör sig med en tom inspelning pekar på vägen mellan de två enheterna.

När paketen kommer fram, sluta skylla på vidarebefordran

Profilen är nästa misstänkta, och den vanliga orsaken är ålder. En exporterad .ovpn-fil innehåller auktoriteten och materialet från exportögonblicket, så ett paket vars certifikat senare byttes ut kommer att avvisa en klient som fortfarande bär den gamla kopian.

Transport är den andra avvikelsen som är värd att kontrollera uttryckligen, eftersom profilen och paketet redigeras på olika ställen. Att ändra en profil från UDP till TCP utan att byta paketet lämnar klienten att vänta på en lyssnare som inte finns, och klienten rapporterar samma generiska handskakningstext som den rapporterar för allt annat. Läs proto-raden i filen, titta sedan på protokollet som valts på serversidan, och dra först då slutsatsen att de stämmer överens. Att läsa DSMs brandväggsregler är den tredje kontrollen: en regel som tillåter porten från det lokala subnätet men inte från internet är lätt att lämna kvar efter tester, och den ger en anslutning som fungerar från köket och misslyckas överallt annars.

Testa vägen som en fjärranvändare verkligen tar

En klient i samma LAN kan nå NAS:en utan att någonsin röra vidarebefordran, så det bevisar ingenting om fjärråtkomst. Använd en telefon med Wi-Fi avstängt, eller fråga någon utanför nätverket, och följ routerns räknare under det försöket. Om fjärrförsöket misslyckas medan det lokala lyckas är vidarebefordran eller brandväggen fortfarande med i bilden.

Anteckna det fungerande tillståndet medan det fungerar: extern port, intern adress, protokoll, paketgränssnitt, samt profilnamn och exportdatum. När handskakningen misslyckas igen är skillnaden mellan den anteckningen och den aktuella konfigurationen felet, och ingen behöver upptäcka på nytt vilken av de två portarna tjänsten använder.