OpenVPN-kättely epäonnistuu Synologylla? Tarkista LAN-uudelleenohjaus

Kannettavasi ilmoittaa, että TLS-kättely epäonnistui, joten kiusaus on rakentaa varmenteet uudelleen. Kysy ensin tylsempi kysymys: millä Ethernet-portilla Synology oikeastaan kuuntelee? Kahden LAN-portin NASissa on kaksi osoitetta, ja DSM:n VPN Server -paketti sitoo OpenVPN-kuuntelijansa yhteen niistä. Kun reititin ohjaa 1194:n toiseen osoitteeseen, yksikään paketti ei koskaan saavuta palvelua, eikä asiakkaalla ole mitään neuvoteltavaa.

Virheteksti johtaa harhaan, koska se kuvaa viimeisen asian, jota asiakas yritti, ei ensimmäistä, joka meni pieleen. Kaksi minuuttia paketin sivun ja reitittimen säännön vertailua ratkaisee asian.

Etsi osoite, johon kuuntelija on sidottu

DSM nimeää porttinsa LAN 1:ksi ja LAN 2:ksi, ja kummallakin on erillinen osoite ja aliverkko. Avaa VPN Server, lue OpenVPN-välilehdellä mainittu liitäntä, avaa sitten Ohjauspaneeli ja kirjoita muistiin IPv4-osoite, joka DSM:llä on samalla liitännällä. Juuri nämä kaksi arvoa, ei NASin isäntänimi, uudelleenohjauksen on nimettävä.

Toinen kytketty kaapeli ei luo toista kuuntelijaa. Molemmat linkit voivat näkyä yhdistettyinä, vaikka vain yksi osoite ottaa liikennettä vastaan, ja kun molemmat liitännät ovat samassa aliverkossa, kaksi osoitetta eroavat yhdellä numerolla, jota kukaan ei lue uudelleen ennen säännön tallentamista.

Katso itse pistoketta SSH:n kautta, sillä se on ainoa paikka, joka näyttää mihin taustapalvelu todella sitoutui, eikä sitä mitä asetussivu aikoo.

sudo netstat -anp | grep 1194

Muokkaa olemassa olevaa uudelleenohjausta sen sijaan, että lisäisit toisen

Kaksi sääntöä yhdelle ulkoiselle portille jättävät reitittimen vapaasti valitsemaan, ja se minkä se valitsee voi muuttua laiteohjelmistopäivityksen tai uudelleenkäynnistyksen jälkeen. Avaa sääntö, joka on jo olemassa, muuta sen sisäistä osoitetta, tallenna, avaa se sitten uudelleen ja lue arvo. Säännön nimeäminen palvelun mukaan auttaa, sillä lista viidestä samanlaisesta uudelleenohjauksesta on tapa, jolla väärä jää henkiin.

external 1194/udp  ->  192.0.2.20:1194/udp

Pidä sisäinen portti samana kuin kuunteluportti ja pidä protokolla johdonmukaisena. UDP 1194 on oletuskuuntelija, kun taas TCP-profiili tarvitsee oman kuuntelijansa paketin puolella ja vastaavan uudelleenohjauksen reitittimellä. TCP:n ohjaaminen palveluun, joka kuuntelee vain UDP:tä, tuottaa hiljaisuutta, ei virhettä.

Jos NASin osoite tulee DHCP:stä, varaa se ennen kuin sääntö tallennetaan. Vuokran päättyminen antaa osoitteen uudelleen, uudelleenohjaus osoittaa edelleen vanhaan arvoon, ja kättely alkaa epäonnistua päivänä, jolloin kukaan ei koskenut NASiin. Staattinen kokoonpano NASin puolella ratkaisee saman ongelman, edellyttäen että osoite on reitittimen DHCP-alueen ulkopuolella.

Todista, saapuvatko paketit ylipäätään

Käynnistä ensin kaappaus NASissa, yhdistä sitten asiakkaasta ja lue lähdeosoite tulosteesta. Vian jälkeen aloitettu kaappaus ei näytä mitään eikä todista mitään.

sudo tcpdump -i any -n udp port 1194

Hiljaisuus tarkoittaa, että liikenne kuoli ennen palvelua: väärä sisäinen osoite, suljettu portti DSM:n palomuurissa tai liitäntä, joka on hallinnollisesti alas. Paketit tulosteessa tarkoittavat, että uudelleenohjaus toimii, ja jäljelle jäävä vika on verkkokerroksen yläpuolella, mikä on paljon pienempi etsintäalue.

Kaappaus nimeää myös liitännän, jolle paketti saapui, ja juuri tämä yksi yksityiskohta erottaa väärään porttiin kohdistetun säännön säännöstä, joka kohdistuu porttiin, joka ei ole ylhäällä. Seuraa reitittimen omaa laskuria saman yrityksen aikana, jos se näyttää sellaisen. Laskuri, joka ei liiku kaappauksen pysyessä tyhjänä, viittaa reitittimeen, kun taas laskuri, joka liikkuu tyhjällä kaappauksella, viittaa kahden laitteen väliseen reittiin.

Kun paketit saapuvat, lopeta uudelleenohjauksen syyttäminen

Profiili on seuraava epäilty, ja tavallinen syy on ikä. Viety .ovpn-tiedosto sisältää valtuuden ja materiaalin vientihetkeltä, joten paketti, jonka varmenne myöhemmin vaihdettiin, hylkää asiakkaan, joka kantaa vielä vanhaa kopiota.

Siirto on toinen eroavuus, joka kannattaa tarkistaa nimenomaisesti, koska profiilia ja pakettia muokataan eri paikoissa. Profiilin vaihtaminen UDP:stä TCP:hen ilman paketin vaihtamista jättää asiakkaan odottamaan kuuntelijaa, jota ei ole, ja asiakas ilmoittaa saman yleisen kättelytekstin, jonka se ilmoittaa kaikesta muusta. Lue tiedoston proto-rivi, katso sitten palvelimen sivulla valittua protokollaa ja vasta sitten päättele, että ne täsmäävät. DSM:n palomuurisääntöjen lukeminen on kolmas tarkistus: sääntö, joka sallii portin paikallisesta aliverkosta mutta ei internetistä, jää helposti testaamisen jälkeen, ja se tuottaa yhteyden, joka toimii keittiöstä ja epäonnistuu kaikkialla muualla.

Testaa reitti, jonka etäkäyttäjä todella kulkee

Saman LANin sisällä oleva asiakas voi saavuttaa NASin koskematta koskaan uudelleenohjaukseen, joten se ei todista mitään etäkäytöstä. Käytä puhelinta, jonka Wi-Fi on pois päältä, tai kysy joltakulta verkon ulkopuolelta, ja seuraa reitittimen laskuria kyseisen yrityksen aikana. Jos etäyritys epäonnistuu paikallisen onnistuessa, uudelleenohjaus tai palomuuri on yhä kuvassa.

Kirjaa toimiva tila ylös, kun se toimii: ulkoinen portti, sisäinen osoite, protokolla, paketin liitäntä sekä profiilin nimi ja vientipäivä. Kun kättely epäonnistuu taas, ero tuon muistiinpanon ja nykyisen kokoonpanon välillä on vika, eikä kenenkään tarvitse löytää uudelleen, kumpaa kahdesta portista palvelu käyttää.