OpenVPN-handtrykk på Synology feilar? Sjekk LAN-vidaresendinga

Den berbare maskina melder at TLS-handtrykket mislukkast, så freistinga er å byggje sertifikata på nytt. Spør først om noko kjedelegare: kva Ethernet-port lyttar Synology eigentleg på? Ein NAS med to LAN-portar har to adresser, og DSMs VPN Server-pakke bind OpenVPN-lyttaren sin til ein av dei. Når rutaren vidaresender 1194 til den andre adressa, når ingen pakke nokon gong tenesta, og klienten har ingenting å forhandle med.

Feilteksten villeder fordi han skildrar det siste klienten prøvde, ikkje det første som gjekk gale. To minutt med å samanlikne pakkesida med ruterregelen avgjer saka.

Finn adressa lyttaren er bunden til

DSM kallar portane sine LAN 1 og LAN 2, og kvar har si eiga adresse og subnett. Opne VPN Server, les grensesnittet som er nemnt på OpenVPN-fana, opne deretter Kontrollpanel og noter IPv4-adressa DSM har på same grensesnitt. Det er desse to verdiane, ikkje vertsnamnet til NAS-en, som vidaresendinga må namngje.

Ein ekstra tilkopla kabel skaper ikkje ein ekstra lyttar. Begge koplingane kan visast som tilkopla medan berre éi adresse tek imot trafikken, og når begge grensesnitta ligg i same subnett, skil dei to adressene seg med eitt siffer som ingen les på nytt før ei regel blir lagra.

Sjå på sjølve sockelen over SSH, for det er den einaste staden som viser kva daemonen faktisk batt seg til, i staden for kva innstillingssida har tenkt seg.

sudo netstat -anp | grep 1194

Rediger den eksisterande vidaresendinga i staden for å leggje til ei ny

To reglar for éin ekstern port lèt rutaren velje fritt, og kva han vel kan endre seg etter ein fastvareoppdatering eller ein omstart. Opne regelen som allereie finst, endre den interne adressa, lagre, opne han deretter igjen og les verdien. Det hjelper å namngje regelen etter tenesta, for ei liste med fem identiske vidaresendingar er måten den feilaktige overlever på.

external 1194/udp  ->  192.0.2.20:1194/udp

Hald den interne porten lik lytt-porten, og hald protokollen konsistent. UDP 1194 er standardlyttaren, medan ein TCP-profil treng sin eigen lyttar på pakkesida og ei tilsvarande vidaresending på rutaren. Å vidaresende TCP til ei teneste som berre lyttar på UDP gir stillheit, ikkje ein feil.

Viss NAS-adressa kjem frå DHCP, reserver henne før regelen blir lagra. Når leiga går ut, blir adressa tildelt på nytt, vidaresendinga peikar framleis på den gamle verdien, og handtrykket byrjar å feile ein dag ingen har rørt NAS-en. Ein statisk konfigurasjon på NAS-sida løyser same problem, føresett at adressa ligg utanfor DHCP-området til rutaren.

Prov at pakkane i det heile kjem fram

Start først eit opptak på NAS-en, kople deretter til frå klienten, og les kjeldeadressa i utdataa. Eit opptak som blir starta etter feilen, viser ingenting og provar ingenting.

sudo tcpdump -i any -n udp port 1194

Stillheit betyr at trafikken døydde før tenesta: ei feil intern adresse, ein lukka port i DSMs brannmur eller eit grensesnitt som er administrativt nede. Pakkar i utdataa betyr at vidaresendinga verkar, og den resterande feilen ligg over nettverkslaget, som er eit mykje mindre søkjeområde.

Opptaket namngjev også grensesnittet pakken kom inn på, og nettopp den detaljen skil ei regel retta mot feil port frå ei regel retta mot ein port som ikkje er oppe. Følg rutaren sin eigen teljar under same forsøk viss han viser ein. Ein teljar som ikkje rører seg medan opptaket blir verande tomt, peikar på rutaren, medan ein teljar som rører seg med eit tomt opptak, peikar på vegen mellom dei to einingane.

Når pakkane kjem fram, slutt å skulde på vidaresendinga

Profilen er den neste mistenkte, og den vanlege grunnen er alder. Ei eksportert .ovpn-fil inneheld autoriteten og materialet frå eksportaugneblinken, så ein pakke der sertifikatet seinare vart bytt ut, vil avvise ein klient som framleis ber den gamle kopien.

Transport er den andre uoverensstemminga som er verdt å sjekke eksplisitt, fordi profilen og pakken blir redigerte på ulike stader. Å endre ein profil frå UDP til TCP utan å bytte pakken lèt klienten vente på ein lyttar som ikkje finst, og klienten rapporterer den same generiske handtrykkteksten som han rapporterer for alt anna. Les proto-linja i fila, sjå deretter på protokollen som er vald på serversida, og konkluder først då med at dei stemmer overeins. Å lese brannmurreglane til DSM er den tredje kontrollen: ein regel som tillèt porten frå det lokale subnettet men ikkje frå internett, er lett å leggje igjen etter testing, og han gir ei tilkopling som verkar frå kjøkenet og feilar alle andre stader.

Test vegen ein ekstern brukar faktisk tek

Ein klient i same LAN kan nå NAS-en utan å nokon gong røre vidaresendinga, så det provar ingenting om ekstern tilgang. Bruk ein telefon med Wi-Fi slått av, eller spør nokon utanfor nettverket, og følg teljaren til rutaren under det forsøket. Viss det eksterne forsøket feilar medan det lokale lukkast, er vidaresendinga eller brannmuren framleis med i biletet.

Noter den fungerande tilstanden medan han fungerer: ekstern port, intern adresse, protokoll, pakkegrensesnitt, samt profilnamn og eksportdato. Når handtrykket feilar igjen, er skilnaden mellom den noten og gjeldande konfigurasjon feilen, og ingen må gjenoppdage kva av dei to portane tenesta brukar.