Synology NAS met twee LAN-poorten: waarom de VPN-handshake mislukt

De laptop meldt een TLS-handshakefout, wat naar een certificaatprobleem klinkt en meestal niet zo is. Op een NAS met twee Ethernet-poorten is de meest voorkomende oorzaak een router-doorsturing naar het adres waarop het pakket niet luistert, en de melding van de client is in beide gevallen identiek. Het pakket antwoordt niet op de tweede poort alleen omdat beide kabels zijn aangesloten. Voordat iemand een certificaat opnieuw uitgeeft, moet u bewijzen dat een pakket de NAS überhaupt bereikt.

Wat de client meldt en wat er werkelijk gebeurde

Een handshakefout van een OpenVPN-client is een verzamelnaam. Hij dekt een certificaatafwijking, een transportafwijking, een luisteraar op een andere poort en een doorsturing die niets afleverde. Daarom is de melding nutteloos als uitgangspunt en alleen nuttig als bevestiging. Behandel hem als de vaststelling dat de sessie niet tot stand kwam, en niets specifieker.

De poort en het gebonden adres zijn de twee feiten die bepalen of een pakket ooit aankomt.

Noteer beide voordat u iets wijzigt, want een plausibele correctie op de verkeerde laag is de manier waarop een probleem van vijftien minuten een hele middag wordt. Noteer de interface, het adres daarop, de poort en het transport. Die vier waarden vormen het hele inkomende pad, en de volgende paragraaf legt uit waar elk ervan zit.

Vind het adres waarop het pakket luistert

DSM nummert de Ethernet-poorten en elk heeft zijn eigen adres. De pagina VPN Server noemt de interface die de OpenVPN-dienst gebruikt, en het netwerkpaneel toont het adres dat op die interface is geconfigureerd. Lees ze in die volgorde, van de dienst naar buiten, zodat u beschrijft wat er luistert in plaats van wat u aanneemt dat het zou moeten gebruiken.

De dienst bindt één adres. Dat beide poorten zijn aangesloten en actief, zorgt er niet voor dat de dienst op de tweede antwoordt. Een statisch adres op de ene interface naast een DHCP-adres op de andere geeft u twee vergelijkbare waarden die op het oog makkelijk te verwisselen zijn, vooral als ze alleen in het laatste octet verschillen. Kopieer het adres uit het paneel in plaats van het uit het geheugen te typen. Bevestig daarna op de NAS wat er werkelijk aan de poort is gebonden.

sudo ss -lunp | grep 1194

Als die uitvoer een adres noemt dat u niet verwachtte, is de doorsturing op de verkeerde interface gericht en is al het overige hier administratie. Corrigeer de regel voordat u verder leest, anders eindigt u met het debuggen van een certificaat vanwege een pakket dat de router nooit heeft verlaten.

Herstel de doorsturing en kijk dan naar de teller

Bewerk de bestaande doorstuurregel in plaats van een tweede toe te voegen voor dezelfde externe poort. Twee regels kunnen naast elkaar bestaan in de tabel van een router en slechts één wint ooit, wat een debugsessie verandert in een discussie over welke de echte is. Richt het interne adres op de waarde die u van de NAS hebt gelezen, en laat de interne poort overeenkomen met waarop de dienst luistert.

Als DSM dat adres via DHCP krijgt, maak dan eerst een reservering. Een wijziging van de lease breekt stilletjes een doorsturing die gisteren werkte.

sudo tcpdump -i any -n udp port 1194

Begin met opnemen voordat de client probeert te verbinden, en lees het bronadres in alles wat verschijnt. Helemaal niets betekent dat iets onderweg het heeft weggegooid: de doorsturing, de DSM-firewall of de interface waarop het gericht was, en certificaten kunnen niet de oorzaak zijn zolang dat geldt. Iets dat van het openbare adres van de client komt zonder antwoord betekent dat de NAS het verzoek ontving en ervoor koos niet te antwoorden. Dat zijn verschillende bevindingen, en alleen de tweede stuurt u terug naar de instellingen van het pakket zelf.

Pas dan kijkt u naar certificaten en transport

Zodra pakketten aankomen, exporteert u het profiel opnieuw na elke certificaatwijziging, want het oude bestand draagt nog de autoriteit waarmee het is gemaakt. Een met de hand bewerkt profiel voor een ander transport laat de client wachten op een luisteraar die niet bestaat, en het meldt dezelfde algemene fout als al het andere. Vergelijk het transport in het profiel met het transport dat het pakket is ingesteld om te bedienen. Twee profielen voor twee transporten is een legitiem ontwerp, en één profiel dat voor beide is bewerkt niet.

Test als laatste stap van buiten uw eigen netwerk, omdat een verbinding van binnen de LAN kan slagen via een pad dat de doorsturing nooit raakt.

Bewaar het geëxporteerde profiel, het interfaceadres en de doorstuurregel samen in één notitie. Wanneer een adres verandert, is die notitie het verschil tussen een reparatie en een herhaling. Niets op dit pad vereiste het opnieuw installeren van een pakket, wat het onthouden waard is voordat de volgende herstart de schuld krijgt.