Methiant handshake OpenVPN ar Synology? Gwiriwch y cyfeirio LAN

Mae eich gliniadur yn dweud bod handshake TLS wedi methu, felly'r demtasiwn yw ailadeiladu'r tystysgrifau. Cyn hynny, gofynnwch gwestiwn mwy diflas: ar ba borth Ethernet mae'r Synology yn gwrando mewn gwirionedd? Mae gan NAS â dau borth LAN ddau gyfeiriad, ac mae pecyn VPN Server DSM yn rhwymo ei wrandäwr OpenVPN i un ohonynt. Pan fydd y llwybrydd yn cyfeirio 1194 at y cyfeiriad arall, nid yw unrhyw becyn byth yn cyrraedd y gwasanaeth, ac nid oes gan y cleient ddim i drafod ag ef.

Mae testun y gwall yn twyllo oherwydd ei fod yn disgrifio'r peth olaf y gwnaeth y cleient ei geisio, nid y peth cyntaf a aeth o'i le. Mae dwy funud o gymharu tudalen y pecyn â rheol y llwybrydd yn datrys y mater.

Dod o hyd i'r cyfeiriad y mae'r gwrandäwr wedi'i rwymo iddo

Mae DSM yn labelu ei borthladdoedd fel LAN 1 a LAN 2, ac mae gan bob un gyfeiriad a is-rwydwaith ar wahân. Agorwch VPN Server, darllenwch y rhyngwyneb a enwir ar y tab OpenVPN, yna agorwch y Panel Rheoli a nodwch y cyfeiriad IPv4 sydd gan DSM ar yr un rhyngwyneb. Y ddau werth hynny, nid enw gwesteiwr y NAS, yw'r hyn y mae'n rhaid i'r cyfeirio ei enwi.

Nid yw ail gebl wedi'i blygio i mewn yn creu ail wrandäwr. Gall y ddau gyswllt ymddangos fel pe baent wedi'u cysylltu tra mai dim ond un cyfeiriad sy'n derbyn y traffig, a phan fydd y ddau ryngwyneb yn yr un is-rwydwaith mae'r ddau gyfeiriad yn wahanol o un digid nad oes neb yn ei ailddarllen cyn cadw rheol.

Edrychwch ar y soced ei hun drwy SSH, oherwydd dyma'r unig le sy'n dangos wrth beth y rhwymodd y daemon mewn gwirionedd, yn hytrach na'r hyn y mae'r dudalen osodiadau yn ei fwriadu.

sudo netstat -anp | grep 1194

Golygwch y cyfeirio presennol yn hytrach nag ychwanegu un arall

Mae dwy reol ar gyfer un porth allanol yn gadael y llwybrydd yn rhydd i ddewis, a gall y un y bydd yn ei ddewis newid ar ôl diweddariad cadarnwedd neu ailosodiad. Agorwch y rheol sydd eisoes yn bodoli, newidiwch ei chyfeiriad mewnol, cadwch, yna ei hagor eto a darllen y gwerth yn ôl. Mae enwi'r rheol ar ôl y gwasanaeth yn helpu, oherwydd rhestr o bump o gyfeiriadau union yr un fath yw sut mae'r un anghywir yn goroesi.

external 1194/udp  ->  192.0.2.20:1194/udp

Cadwch y porth mewnol yn hafal i'r porth gwrando, a chadwch y protocol yn gyson. UDP 1194 yw'r gwrandäwr rhagosodedig, tra bod proffil TCP angen ei wrandäwr ei hun ar ochr y pecyn a chyfeiriad cyfatebol ar y llwybrydd. Mae cyfeirio TCP at wasanaeth sy'n gwrando ar UDP yn unig yn cynhyrchu distawrwydd, nid gwall.

Os yw cyfeiriad y NAS yn dod o DHCP, cadwch ef yn ôl cyn i'r rheol gael ei chadw. Mae dod i ben y brydles yn ailddyrannu'r cyfeiriad, mae'r cyfeirio yn parhau i fynd yn ôl at yr hen werth, ac mae'r handshake yn dechrau methu ar ddiwrnod na wnaeth neb gyffwrdd â'r NAS. Mae ffurfweddiad statig ar ochr y NAS yn datrys yr un broblem, ar yr amod bod y cyfeiriad y tu allan i ystod DHCP y llwybrydd.

Profwch a yw pecynnau yn cyrraedd o gwbl

Dechreuwch gipio ar y NAS yn gyntaf, yna cysylltwch o'r cleient, a darllenwch y cyfeiriad ffynhonnell yn yr allbwn. Nid yw cipio a ddechreuwyd ar ôl y methiant yn dangos dim ac yn profi dim.

sudo tcpdump -i any -n udp port 1194

Mae distawrwydd yn golygu bod y traffig wedi marw cyn y gwasanaeth: cyfeiriad mewnol anghywir, porth wedi'i chau ar fur tân DSM, neu ryngwyneb sydd wedi'i analluogi'n weinyddol. Mae pecynnau yn yr allbwn yn golygu bod y cyfeirio yn gweithio, ac mae'r nam sy'n weddill yn byw uwchlaw'r haen rwydwaith, sef ardal chwilio lawer llai.

Mae'r cipio hefyd yn enwi'r rhyngwyneb y cyrhaeddodd y pecyn arno, ac mae'r un manylyn hwnnw yn gwahanu rheol wedi'i hanelu at y porth anghywir oddi wrth reol wedi'i hanelu at borth nad yw wedi'i godi. Gwyliwch gownter y llwybrydd ei hun yn ystod yr un cynnig os yw'n ei ddangos. Mae gownter nad yw'n symud tra bod y cipio yn aros yn wag yn pwyntio at y llwybrydd, tra bod gownter sy'n symud gyda chipio gwag yn pwyntio at y llwybr rhwng y ddau ddyfais.

Pan fydd pecynnau yn cyrraedd, stopiwch feio'r cyfeirio

Y proffil yw'r amheuwr nesaf, a'r rheswm arferol yw oed. Mae ffeil .ovpn a allforiwyd yn cynnwys yr awdurdod a'r deunydd o'r eiliad allforio, felly bydd pecyn yr oedd ei dystysgrif wedi'i disodli yn ddiweddarach yn gwrthod cleient sy'n dal i gario'r hen gopi.

Cludiant yw'r anghysondeb arall sy'n werth ei wirio'n benodol, oherwydd mae'r proffil a'r pecyn yn cael eu golygu mewn gwahanol leoedd. Mae newid proffil o UDP i TCP heb newid y pecyn yn gadael y cleient yn aros am wrandäwr nad yw'n bodoli, ac mae'r cleient yn adrodd yr un testun handshake generig y mae'n ei adrodd ar gyfer popeth arall. Darllenwch y llinell proto yn y ffeil, yna edrychwch ar y protocol a ddewiswyd ar dudalen y gweinydd, ac yn unig wedyn casglwch eu bod yn cytuno. Mae darllen rheolau mur tân DSM yn drydydd gwiriad: mae rheol sy'n caniatáu'r porth o'r is-rwydwaith lleol ond nid o'r rhyngrwyd yn hawdd ei gadael ar ôl ar ôl profi, ac mae'n cynhyrchu cysylltiad sy'n gweithio o gegin y tŷ ac yn methu ym mhobman arall.

Profwch y llwybr y mae defnyddiwr o bell yn ei gymryd mewn gwirionedd

Gall cleient y tu mewn i'r un LAN gyrraedd y NAS heb gyffwrdd â'r cyfeirio o gwbl, felly nid yw'n profi dim am fynediad o bell. Defnyddiwch ffôn â'r Wi-Fi wedi'i ddiffodd, neu gofynnwch i rywun y tu allan i'r rhwydwaith, a gwyliwch gownter y llwybrydd yn ystod y cynnig hwnnw. Os bydd y cynnig o bell yn methu tra bod yr un lleol yn llwyddo, mae'r cyfeirio neu'r mur tân yn dal yn y darlun.

Cofnodwch y cyflwr sy'n gweithio tra bo'n gweithio: porth allanol, cyfeiriad mewnol, protocol, rhyngwyneb y pecyn, ac enw'r proffil a dyddiad allforio. Pan fydd yr handshake yn methu eto, y gwahaniaeth rhwng y nodyn hwnnw a'r ffurfweddiad presennol yw'r nam, ac nid oes rhaid i neb ailddarganfod pa un o'r dau borth y mae'r gwasanaeth yn ei ddefnyddio.