OpenVPN-handshake op Synology mislukt? Controleer de LAN-doorsturing

Uw laptop meldt dat de TLS-handshake is mislukt, dus de verleiding is om de certificaten opnieuw te bouwen. Stel eerst een saaiere vraag: op welke Ethernet-poort luistert de Synology eigenlijk? Een NAS met twee LAN-poorten heeft twee adressen, en het VPN Server-pakket van DSM bindt zijn OpenVPN-listener aan één ervan. Wanneer de router 1194 naar het andere adres doorstuurt, bereikt geen enkel pakket ooit de dienst, en de client heeft niets om over te onderhandelen.

De fouttekst misleidt omdat hij het laatste beschrijft dat de client probeerde, niet het eerste dat misging. Twee minuten de pakketpagina met de routerregel vergelijken beslechten het.

Vind het adres waaraan de listener is gebonden

DSM noemt zijn poorten LAN 1 en LAN 2, en elk draagt een apart adres en subnet. Open VPN Server, lees de interface die op het tabblad OpenVPN wordt genoemd, open dan het Configuratiescherm en noteer het IPv4-adres dat DSM op diezelfde interface heeft. Die twee waarden, niet de hostnaam van de NAS, moet de doorsturing benoemen.

Een tweede aangesloten kabel maakt geen tweede listener. Beide verbindingen kunnen als verbonden verschijnen terwijl slechts één adres het verkeer aanneemt, en wanneer beide interfaces in hetzelfde subnet zitten, verschillen de twee adressen met één cijfer dat niemand opnieuw leest voordat een regel wordt opgeslagen.

Kijk via SSH naar de socket zelf, want dat is de enige plek die laat zien waaraan de daemon zich werkelijk heeft gebonden, in plaats van wat de instellingenpagina bedoelt.

sudo netstat -anp | grep 1194

Bewerk de bestaande doorsturing in plaats van een nieuwe toe te voegen

Twee regels voor één externe poort laten de router vrij kiezen, en welke hij kiest kan veranderen na een firmware-update of een herstart. Open de regel die al bestaat, wijzig het interne adres, sla op, open hem daarna opnieuw en lees de waarde terug. De regel naar de dienst vernoemen helpt, want een lijst van vijf identieke doorsturingen is de manier waarop de verkeerde overleeft.

external 1194/udp  ->  192.0.2.20:1194/udp

Houd de interne poort gelijk aan de luisterpoort, en houd het protocol consistent. UDP 1194 is de standaardlistener, terwijl een TCP-profiel zijn eigen listener aan de pakketzijde nodig heeft en een bijpassende doorsturing op de router. TCP doorsturen naar een dienst die alleen op UDP luistert, levert stilte op, geen fout.

Als het NAS-adres van DHCP komt, reserveer het dan voordat de regel wordt opgeslagen. Het verlopen van de lease wijst het adres opnieuw toe, de doorsturing blijft naar de oude waarde wijzen, en de handshake begint te falen op een dag waarop niemand de NAS heeft aangeraakt. Een statische configuratie aan de NAS-kant lost hetzelfde probleem op, mits het adres buiten het DHCP-bereik van de router ligt.

Bewijs of de pakketten überhaupt aankomen

Start eerst een opname op de NAS, verbind dan vanaf de client, en lees het bronadres in de uitvoer. Een opname die na de storing is gestart, toont niets en bewijst niets.

sudo tcpdump -i any -n udp port 1194

Stilte betekent dat het verkeer stierf voordat het de dienst bereikte: een verkeerd intern adres, een gesloten poort op de DSM-firewall, of een interface die administratief uit staat. Pakketten in de uitvoer betekenen dat de doorsturing werkt, en de resterende fout ligt boven de netwerklaag, wat een veel kleiner zoekgebied is.

De opname noemt ook de interface waarop het pakket aankwam, en juist dat ene detail scheidt een regel die op de verkeerde poort is gericht van een regel die op een poort is gericht die niet actief is. Let tijdens dezelfde poging op de eigen teller van de router als die er een toont. Een teller die niet beweegt terwijl de opname leeg blijft, wijst naar de router, terwijl een teller die beweegt bij een lege opname naar het pad tussen de twee apparaten wijst.

Als de pakketten aankomen, stop met de doorsturing de schuld geven

Het profiel is de volgende verdachte, en de gebruikelijke reden is leeftijd. Een geëxporteerd .ovpn-bestand bevat de autoriteit en het materiaal van het moment van export, dus een pakket waarvan het certificaat later is vervangen, weigert een client die nog de oude kopie draagt.

Transport is de andere mismatch die de moeite waard is om expliciet te controleren, omdat het profiel en het pakket op verschillende plekken worden bewerkt. Een profiel van UDP naar TCP veranderen zonder het pakket om te schakelen laat de client wachten op een listener die niet bestaat, en de client meldt dezelfde generieke handshaketekst die hij voor al het andere meldt. Lees de proto-regel in het bestand, kijk dan naar het protocol dat op de serverpagina is gekozen, en concludeer pas dan dat ze overeenkomen. De firewallregels van DSM lezen is de derde controle: een regel die de poort vanuit het lokale subnet toestaat maar niet vanaf internet, blijft na het testen makkelijk achter, en levert een verbinding die vanuit de keuken werkt en overal elders faalt.

Test het pad dat een externe gebruiker werkelijk aflegt

Een client binnen hetzelfde LAN kan de NAS bereiken zonder ooit de doorsturing aan te raken, dus dat bewijst niets over externe toegang. Gebruik een telefoon met Wi-Fi uit, of vraag iemand buiten het netwerk, en let tijdens die poging op de routerteller. Als de externe poging faalt terwijl de lokale slaagt, zijn de doorsturing of de firewall nog in beeld.

Noteer de werkende toestand terwijl die werkt: externe poort, intern adres, protocol, pakketinterface, en de profielnaam en exportdatum. Wanneer de handshake weer faalt, is het verschil tussen die notitie en de huidige configuratie de fout, en niemand hoeft opnieuw te ontdekken welke van de twee poorten de dienst gebruikt.