Synology OpenVPN-handdruk misluk? Kyk na die LAN-deurstuur

Jou skootrekenaar sê dat die TLS-handdruk misluk het, en die versoeking is om sertifikate te herbou. Vra vooraf 'n flouer vraag: op watter Ethernet-poort luister die Synology eintlik? 'n NAS met twee LAN-poorte het twee adresse, en DSM se VPN Server-pak bind sy OpenVPN-ontvanger aan een van hulle. Wanneer die router 1194 na die ander adres deurstuur, bereik geen pakkie ooit die diens nie, en die kliënt het niks om mee te onderhandel nie.

Die foutteks mislei omdat dit die laaste ding beskryf wat die kliënt probeer het, nie die eerste ding wat verkeerd gegaan het nie. Twee minute om die pakketblad met die router-reël te vergelyk, beslis dit.

Vind die adres waaraan die ontvanger gebind is

DSM noem sy poorte LAN 1 en LAN 2, en elkeen het 'n aparte adres en subnet. Maak VPN Server oop, lees die koppelvlak wat op die OpenVPN-oortjie genoem word, maak dan Beheerpaneel oop en let op die IPv4-adres wat DSM op daardie selfde koppelvlak het. Daardie twee waardes, nie die NAS se gasheernaam nie, is wat die deurstuur moet noem.

Nog 'n kabel wat ingeprop word, skep nie 'n tweede ontvanger nie. Albei skakels kan as verbind wys terwyl net een adres die verkeer aanvaar, en wanneer albei koppelvlakke op dieselfde subnet sit, verskil die twee adresse met 'n syfer wat niemand weer lees voordat 'n reël gestoor word nie.

Kyk oor SSH na die sokself, want dit is die enigste plek wat wys waaraan die daemon werklik gebind het, eerder as wat die instellingsblad bedoel.

sudo netstat -anp | grep 1194

Wysig die bestaande deurstuur eerder as om nog een by te voeg

Twee reëls vir een eksterne poort laat die router vry om te kies, en watter een hy kies, kan ná 'n firmware-opdatering of 'n herbegin verander. Maak die reël oop wat reeds bestaan, verander sy interne adres, stoor, maak dit dan weer oop en lees die waarde terug. Om die reël na die diens te noem, help, want 'n lys van vyf identiese deursture is hoe die verkeerde een oorleef.

external 1194/udp  ->  192.0.2.20:1194/udp

Hou die interne poort gelyk aan die luisterende poort, en hou die protokol konsekwent. UDP 1194 is die verstek-ontvanger, terwyl 'n TCP-profiel sy eie ontvanger aan die pakketkant nodig het en 'n ooreenstemmende deurstuur op die router. Om TCP deur te stuur na 'n diens wat net op UDP luister, lewer stilte, nie 'n fout nie.

As die NAS-adres van DHCP kom, reserveer dit voordat die reël gestoor word. Huurverval ken die adres weer toe, die deurstuur bly na die ou waarde wys, en die handdruk begin op 'n dag misluk wanneer niemand aan die NAS geraak het nie. 'n Statiese opset aan die NAS-kant los dieselfde probleem op, mits die adres buite die router se DHCP-reeks sit.

Bewys of pakkies hoegenaamd aankom

Begin eers 'n opname op die NAS, verbind dan vanaf die kliënt, en lees die bronadres in die uitset. 'n Opname wat ná die fout begin is, wys niks en bewys niks.

sudo tcpdump -i any -n udp port 1194

Stilte beteken die verkeer het voor die diens doodgegaan: 'n verkeerde interne adres, 'n geslote poort op die DSM-firewall, of 'n koppelvlak wat administratief af is. Pakkies in die uitset beteken die deurstuur werk, en die oorblywende fout lê bo die netwerklaag, wat 'n baie kleiner soekarea is.

Die opname noem ook die koppelvlak waarop die pakkie aangekom het, en daardie enkele besonderheid skei 'n reël wat op die verkeerde poort gemik is van 'n reël wat op 'n poort gemik is wat nie op is nie. Dop die router se eie teller tydens dieselfde poging as dit een blootstel. 'n Teller wat nie beweeg terwyl die opname leeg bly nie, wys na die router, terwyl 'n teller wat beweeg met 'n leë opname na die pad tussen die twee toestelle wys.

Wanneer pakkies aankom, hou op om die deurstuur te blameer

Die profiel is die volgende verdagte, en die gewone rede is ouderdom. 'n Uitgevoerde .ovpn-lêer bevat die gesag en materiaal van die oomblik van uitvoer, so 'n pakket wie se sertifikaat later vervang is, sal 'n kliënt verwerp wat nog die ou kopie dra.

Vervoer is die ander wanverhouding wat mens eksplisiet moet nagaan, want die profiel en die pakket word op verskillende plekke gewysig. Om 'n profiel van UDP na TCP te verander sonder om die pakket om te skakel, laat die kliënt wag op 'n ontvanger wat nie bestaan nie, en die kliënt rapporteer dieselfde generiese handdruk-teks wat hy vir alles anders rapporteer. Lees die proto-reël in die lêer, kyk dan na die protokol wat op die bedienerblad gekies is, en besluit eers dan dat hulle ooreenstem. Om die DSM-firewallreëls te lees, is die derde kontrole: 'n reël wat die poort van die plaaslike subnet maar nie van die internet af toelaat nie, is maklik om ná toetsing te vergeet, en dit lewer 'n verbinding wat uit die kombuis werk en van oral anders misluk.

Toets die pad wat 'n afgeleë gebruiker werklik volg

'n Kliënt binne dieselfde LAN kan die NAS bereik sonder om ooit aan die deurstuur te raak, so dit bewys niks oor afgeleë toegang nie. Gebruik 'n foon met Wi-Fi afgeskakel, of vra iemand buite die netwerk, en dophou die router-teller tydens daardie poging. As die afgeleë poging misluk terwyl die plaaslike een slaag, is die deurstuur of die firewall nog in die prentjie.

Teken die werkende toestand op terwyl dit werk: eksterne poort, interne adres, protokol, pakketkoppelvlak, en die profielnaam en uitvoerdatum. Wanneer die handdruk weer misluk, is die verskil tussen daardie nota en die huidige opset die fout, en niemand hoef weer te ontdek watter van die twee poorte die diens gebruik nie.