OpenVPN-handshake på Synology fejler? Tjek LAN-videresendelsen

Din bærbare melder, at TLS-handshaket fejlede, så fristelsen er at genopbygge certifikaterne. Spørg først om noget mere kedeligt: hvilken Ethernet-port lytter Synology egentlig på? En NAS med to LAN-porte har to adresser, og DSMs VPN Server-pakke binder sin OpenVPN-lytter til en af dem. Når routeren videresender 1194 til den anden adresse, når ingen pakke nogensinde tjenesten, og klienten har intet at forhandle med.

Fejlteksten vildleder, fordi den beskriver det sidste, klienten prøvede, ikke det første, der gik galt. To minutter med at sammenligne pakkens side med routerreglen afgør sagen.

Find den adresse, lytteren er bundet til

DSM kalder sine porte LAN 1 og LAN 2, og hver har sin egen adresse og undernet. Åbn VPN Server, læs det interface, der er nævnt på OpenVPN-fanen, åbn derefter Kontrolpanel og notér den IPv4-adresse, DSM har på samme interface. Det er disse to værdier, ikke NAS'ens værtsnavn, som videresendelsen skal navngive.

Et ekstra tilsluttet kabel skaber ikke en ekstra lytter. Begge links kan vise sig som forbundne, mens kun én adresse tager imod trafikken, og når begge interfaces ligger i samme undernet, adskiller de to adresser sig med et ciffer, som ingen læser igen, før en regel gemmes.

Se på selve socket'en over SSH, for det er det eneste sted, der viser, hvad dæmonen faktisk bandt sig til, i stedet for hvad indstillingssiden har tænkt sig.

sudo netstat -anp | grep 1194

Rediger den eksisterende videresendelse i stedet for at tilføje en ny

To regler for én ekstern port lader routeren vælge frit, og hvilken den vælger, kan ændre sig efter en firmwareopdatering eller en genstart. Åbn den regel, der allerede findes, ændr dens interne adresse, gem, åbn den derefter igen og læs værdien. Det hjælper at navngive reglen efter tjenesten, for en liste med fem identiske videresendelser er måden, hvorpå den forkerte overlever.

external 1194/udp  ->  192.0.2.20:1194/udp

Hold den interne port lig med lytteporten, og hold protokollen konsistent. UDP 1194 er standardlytteren, mens en TCP-profil har brug for sin egen lytter på pakkesiden og en tilsvarende videresendelse på routeren. Videresendelse af TCP til en tjeneste, der kun lytter på UDP, giver tavshed, ikke en fejl.

Hvis NAS'ens adresse kommer fra DHCP, skal du reservere den, før reglen gemmes. Når lejemålet udløber, tildeles adressen igen, videresendelsen peger stadig på den gamle værdi, og handshaket begynder at fejle på en dag, hvor ingen har rørt NAS'en. En statisk konfiguration på NAS-siden løser det samme problem, forudsat at adressen ligger uden for routerens DHCP-område.

Bevis, om pakkerne overhovedet ankommer

Start først en optagelse på NAS'en, forbind derefter fra klienten, og læs kildeadressen i outputtet. En optagelse, der er startet efter fejlen, viser intet og beviser intet.

sudo tcpdump -i any -n udp port 1194

Tavshed betyder, at trafikken døde før tjenesten: en forkert intern adresse, en lukket port i DSMs firewall eller et interface, der er administrativt nede. Pakker i outputtet betyder, at videresendelsen virker, og den resterende fejl ligger over netværkslaget, som er et meget mindre søgeområde.

Optagelsen navngiver også det interface, pakken ankom på, og netop den detalje adskiller en regel rettet mod den forkerte port fra en regel rettet mod en port, der ikke er oppe. Hold øje med routerens egen tæller under samme forsøg, hvis den viser en. En tæller, der ikke rykker, mens optagelsen forbliver tom, peger på routeren, mens en tæller, der rykker med en tom optagelse, peger på vejen mellem de to enheder.

Når pakkerne ankommer, hold op med at bebrejde videresendelsen

Profilen er den næste mistænkte, og den sædvanlige grund er alder. En eksporteret .ovpn-fil indeholder autoriteten og materialet fra eksportøjeblikket, så en pakke, hvis certifikat senere blev udskiftet, vil afvise en klient, der stadig bærer den gamle kopi.

Transport er den anden uoverensstemmelse, der er værd at tjekke eksplicit, fordi profilen og pakken redigeres forskellige steder. At ændre en profil fra UDP til TCP uden at skifte pakken efterlader klienten til at vente på en lytter, der ikke findes, og klienten rapporterer den samme generiske handshaketekst, som den rapporterer for alt andet. Læs proto-linjen i filen, se derefter på den protokol, der er valgt på serversiden, og konkluder først derefter, at de stemmer overens. Det tredje tjek er at læse DSMs firewallregler: en regel, der tillader porten fra det lokale undernet men ikke fra internettet, er let at efterlade efter en test, og den giver en forbindelse, der virker fra køkkenet og fejler alle andre steder.

Test den vej, en fjernbruger faktisk tager

En klient på samme LAN kan nå NAS'en uden nogensinde at røre videresendelsen, så det beviser intet om fjernadgang. Brug en telefon med Wi-Fi slået fra, eller spørg nogen uden for netværket, og hold øje med routerens tæller under det forsøg. Hvis det fjerne forsøg fejler, mens det lokale lykkes, er videresendelsen eller firewallen stadig med i billedet.

Notér den fungerende tilstand, mens den fungerer: ekstern port, intern adresse, protokol, pakkeinterface samt profilnavn og eksportdato. Når handshaket fejler igen, er forskellen mellem den note og den nuværende konfiguration fejlen, og ingen behøver at genopdage, hvilken af de to porte tjenesten bruger.