Synology NAS met twee LAN-poorte: waarom die VPN-handdruk misluk

Die skootrekenaar rapporteer ’n TLS-handdrukfout, wat na ’n sertifikaatprobleem klink en gewoonlik nie een is nie. Op ’n NAS met twee Ethernet-poorte is die algemeenste oorsaak ’n router-deurverwysing wat na die adres wys waarop die pakket nie luister nie, en die kliënt se boodskap is in beide gevalle identies. Die pakket antwoord nie op die tweede poort bloot omdat albei kabels ingeprop is nie. Voordat iemand ’n sertifikaat heruitreik, bewys dat ’n pakkie die NAS hoegenaamd bereik.

Wat die kliënt rapporteer en wat werklik gebeur het

’n Handdrukfout van ’n OpenVPN-kliënt is ’n versamelterm. Dit dek ’n sertifikaatwanpassing, ’n vervoerwanpassing, ’n luisteraar op ’n ander poort en ’n deurverwysing wat niks afgelewer het nie. Daarom is die boodskap nutteloos as beginpunt en net nuttig as bevestiging. Behandel dit as ’n verklaring dat die sessie nie tot stand gekom het nie, en as niks meer spesifiek nie.

Die poort en die gebinde adres is die twee feite wat besluit of ’n pakkie ooit arriveer.

Skryf albei neer voordat jy enigiets verander, want ’n oortuigende oplossing op die verkeerde laag is hoe ’n probleem van vyftien minute ’n middag word. Let op die koppelvlak, die adres daarop, die poort en die vervoer. Daardie vier waardes is die hele inkomende pad, en die volgende afdeling verduidelik waar elkeen woon.

Vind die adres waarop die pakket luister

DSM nommer die Ethernet-poorte en elkeen dra sy eie adres. Die VPN Server-bladsy noem die koppelvlak wat die OpenVPN-diens gebruik, en die netwerkpaneel wys die adres wat op daardie koppelvlak ingestel is. Lees dit in daardie volgorde, van die diens uit na buite, sodat jy beskryf wat luister eerder as wat jy aanneem dit behoort te gebruik.

Die diens bind een adres. Dat albei poorte gekoppel en aktief is, maak nie dat die diens op die tweede een antwoord nie. ’n Statiese adres op een koppelvlak langs ’n DHCP-adres op die ander gee jou twee soortgelyke waardes wat met ’n oogopslag maklik omgeruil kan word, veral wanneer hulle net in die laaste oket verskil. Kopieer die adres uit die paneel eerder as om dit uit die geheue te tik. Bevestig dan op die NAS wat werklik aan die poort gebind is.

sudo ss -lunp | grep 1194

As daardie uitset ’n adres noem wat jy nie verwag het nie, is die deurverwysing na die verkeerde koppelvlak gerig en is alles anders hier bloot boekhouding. Maak die reël reg voordat jy verder lees, anders eindig jy deur ’n sertifikaat te ontfout oor ’n pakkie wat nooit die router verlaat het nie.

Maak die deurverwysing reg en kyk dan na die teller

Wysig die bestaande deurverwysingsreël eerder as om ’n tweede een vir dieselfde eksterne poort by te voeg. Twee reëls kan in ’n router se tabel saamleef terwyl net een ooit wen, wat ’n ontfoutingsessie in ’n argument verander oor watter een egter reg is. Rig die interne adres op die waarde wat jy van die NAS gelees het, en laat die interne poort ooreenstem met wat die diens ook al luister.

As DSM daardie adres oor DHCP kry, skep eers ’n reservering. ’n Huurverandering breek stilweg ’n deurverwysing wat gister gewerk het.

sudo tcpdump -i any -n udp port 1194

Begin vasvang voordat die kliënt probeer verbind, en lees die bronadres in wat ook al opdaag. Heeltemal niks beteken iets het dit op pad weggegooi: die deurverwysing, die DSM-vuurmuur of die koppelvlak waarop dit gerig was, en sertifikate kan nie die oorsaak wees terwyl dit geld nie. Iets wat van die kliënt se openbare adres aankom sonder enige antwoord beteken die NAS het die versoek ontvang en gekies om nie te antwoord nie. Dit is verskillende bevindings, en net die tweede een stuur jou terug na die pakket se eie instellings.

Kyk eers dan na sertifikate en vervoer

Sodra pakkies arriveer, heruitvoer die profiel ná enige sertifikaatverandering, want die ou lêer dra steeds die sertifikaatowerheid waarmee dit geskep is. ’n Profiel wat met die hand geredigeer is om ’n ander vervoer te gebruik, laat die kliënt wag op ’n luisteraar wat nie bestaan nie, en dit rapporteer dieselfde generiese fout as alles anders. Vergelyk die vervoer binne die profiel met die vervoer wat die pakket ingestel is om te bedien. Twee profiele vir twee vervoer is ’n geldige ontwerp, en een profiel wat vir albei geredigeer is, is nie.

Toets as laaste stap van buite jou eie netwerk, want ’n verbinding van binne die LAN kan slaag oor ’n pad wat nooit die deurverwysing raak nie.

Hou die uitgevoerde profiel, die koppelvlakadres en die deurverwysingsreël saam in een nota. Wanneer ’n adres verander, is daardie nota die verskil tussen ’n oplossing en ’n herhaling. Niks op hierdie pad het vereis dat ’n pakket herinstalleer word nie, wat werd is om te onthou voordat die volgende herbegin die skuld kry.