OpenVPN-håndtrykk på Synology feiler? Sjekk LAN-videresendingen

Den bærbare maskinen melder at TLS-håndtrykket mislyktes, så fristelsen er å bygge sertifikatene på nytt. Spør først om noe kjedeligere: hvilken Ethernet-port lytter Synology egentlig på? En NAS med to LAN-porter har to adresser, og DSMs VPN Server-pakke binder OpenVPN-lytteren sin til en av dem. Når ruteren videresender 1194 til den andre adressen, når ingen pakke noen gang tjenesten, og klienten har ingenting å forhandle med.

Feilteksten villeder fordi den beskriver det siste klienten prøvde, ikke det første som gikk galt. To minutter med å sammenligne pakkesiden med ruterregelen avgjør saken.

Finn adressen lytteren er bundet til

DSM kaller portene sine LAN 1 og LAN 2, og hver har sin egen adresse og subnett. Åpne VPN Server, les grensesnittet som er nevnt på OpenVPN-fanen, åpne deretter Kontrollpanel og noter IPv4-adressen DSM har på samme grensesnitt. Det er disse to verdiene, ikke vertsnavnet til NAS-en, som videresendingen må navngi.

En ekstra tilkoblet kabel skaper ikke en ekstra lytter. Begge koblingene kan vises som tilkoblet mens bare én adresse tar imot trafikken, og når begge grensesnittene ligger i samme subnett, skiller de to adressene seg med ett siffer som ingen leser på nytt før en regel lagres.

Se på selve sockelen over SSH, for det er det eneste stedet som viser hva daemonen faktisk bandt seg til, i stedet for hva innstillingssiden har tenkt seg.

sudo netstat -anp | grep 1194

Rediger den eksisterende videresendingen i stedet for å legge til en ny

To regler for én ekstern port lar ruteren velge fritt, og hvilken den velger kan endre seg etter en fastvareoppdatering eller en omstart. Åpne regelen som allerede finnes, endre den interne adressen, lagre, åpne den deretter igjen og les verdien. Det hjelper å navngi regelen etter tjenesten, for en liste med fem identiske videresendinger er måten den feilaktige overlever på.

external 1194/udp  ->  192.0.2.20:1194/udp

Hold den interne porten lik lytt-porten, og hold protokollen konsistent. UDP 1194 er standardlytteren, mens en TCP-profil trenger sin egen lytter på pakkesiden og en tilsvarende videresending på ruteren. Å videresende TCP til en tjeneste som bare lytter på UDP gir stillhet, ikke en feil.

Hvis NAS-adressen kommer fra DHCP, reserver den før regelen lagres. Når leien utløper, tildeles adressen på nytt, videresendingen peker fortsatt på den gamle verdien, og håndtrykket begynner å feile en dag ingen har rørt NAS-en. En statisk konfigurasjon på NAS-siden løser samme problem, forutsatt at adressen ligger utenfor ruterens DHCP-område.

Bevis om pakkene i det hele tatt kommer frem

Start først en opptak på NAS-en, koble deretter til fra klienten, og les kildeadressen i utdataene. Et opptak som startes etter feilen, viser ingenting og beviser ingenting.

sudo tcpdump -i any -n udp port 1194

Stillhet betyr at trafikken døde før tjenesten: en feil intern adresse, en lukket port i DSMs brannmur eller et grensesnitt som er administrativt nede. Pakker i utdataene betyr at videresendingen virker, og den resterende feilen ligger over nettverkslaget, som er et mye mindre søkeområde.

Opptaket navngir også grensesnittet pakken kom inn på, og nettopp den detaljen skiller en regel rettet mot feil port fra en regel rettet mot en port som ikke er oppe. Følg ruterens egen teller under samme forsøk hvis den viser en. En teller som ikke beveger seg mens opptaket forblir tomt, peker på ruteren, mens en teller som beveger seg med et tomt opptak, peker på veien mellom de to enhetene.

Når pakkene kommer frem, slutt å skylde på videresendingen

Profilen er den neste mistenkte, og den vanlige grunnen er alder. En eksportert .ovpn-fil inneholder autoriteten og materialet fra eksportøyeblikket, så en pakke hvis sertifikat senere ble byttet ut, vil avvise en klient som fortsatt bærer den gamle kopien.

Transport er den andre uoverensstemmelsen som er verdt å sjekke eksplisitt, fordi profilen og pakken redigeres på forskjellige steder. Å endre en profil fra UDP til TCP uten å bytte pakken lar klienten vente på en lytter som ikke finnes, og klienten rapporterer den samme generiske håndtrykkteksten som den rapporterer for alt annet. Les proto-linjen i filen, se deretter på protokollen som er valgt på serversiden, og konkluder først da med at de stemmer overens. Å lese DSMs brannmurregler er den tredje kontrollen: en regel som tillater porten fra det lokale subnettet men ikke fra internett, er lett å legge igjen etter testing, og den gir en forbindelse som virker fra kjøkkenet og feiler alle andre steder.

Test veien en ekstern bruker faktisk tar

En klient i samme LAN kan nå NAS-en uten å noen gang røre videresendingen, så det beviser ingenting om ekstern tilgang. Bruk en telefon med Wi-Fi slått av, eller spør noen utenfor nettverket, og følg ruterens teller under det forsøket. Hvis det eksterne forsøket feiler mens det lokale lykkes, er videresendingen eller brannmuren fortsatt med i bildet.

Noter den fungerende tilstanden mens den fungerer: ekstern port, intern adresse, protokoll, pakkegrensesnitt, samt profilnavn og eksportdato. Når håndtrykket feiler igjen, er forskjellen mellom den noten og gjeldende konfigurasjon feilen, og ingen må gjenoppdage hvilken av de to portene tjenesten bruker.