OpenVPN-hânshake op Synology misleit? Kontrolearje de LAN-trochstjoering

Jo laptop meldt dat de TLS-hânshake mislein is, dus de ferlieding is om de sertifikaten wer op te bouwen. Freegje earst in slopere fraach: op hokker Ethernet-poart harket de Synology eins? In NAS mei twa LAN-poarten hat twa adressen, en it VPN Server-pakket fan DSM bynt syn OpenVPN-harker oan ien fan beide. As de router 1194 nei it oare adres trochstjoert, berikt gjin pakket ea de tsjinst, en de klient hat neat om mei te ûnderhanneljen.

De flatertekst misliedt, want hy beskriuwt it lêste dat de klient besocht hat, net it earste dat misgie. Twa minuten it pakketblêd mei de routerregel fergelykje makket it klear.

Fyn it adres dêr't de harker oan bûn is

DSM neamt syn poarten LAN 1 en LAN 2, en elk hat in apart adres en subnet. Iepenje VPN Server, lês it ynterface dat op it OpenVPN-tabblêd neamd wurdt, iepenje dan It Bedieningspaneel en skriuw it IPv4-adres op dat DSM op itselde ynterface hat. Dy twa wearden, net de hostnamme fan 'e NAS, binne wat de trochstjoering neame moat.

In twadde oansletten kabel makket gjin twadde harker. Beide keppelings kinne as ferbûn sjen litte wylst mar ien adres it ferkear oannimt, en as beide ynterfaces yn itselde subnet sitte, ferskille de twa adressen mei ien sifer dat nimmen wer lêst foardat in regel bewarre wurdt.

Sjoch op it socket sels fia SSH, want dat is it iennichste plak dat sjen lit wêr't de daemon him eins oan bûn hat, net wat de ynstellingsside fan doel is.

sudo netstat -anp | grep 1194

Bewurkje de besteande trochstjoering ynstee fan in nije ta te foegjen

Twa regels foar ien eksterne poart litte de router frij om te kiezen, en hokker hy kiest kin feroarje nei in firmware-update of in reboot. Iepenje de regel dy't al bestiet, feroarje syn ynterne adres, bewarje, iepenje him dan wer en lês de wearde werom. De regel nei de tsjinst neame helpt, want in list fan fiif identike trochstjoeringen is hoe't de ferkearde oerlibbet.

external 1194/udp  ->  192.0.2.20:1194/udp

Hâld de ynterne poart gelyk oan de harkpoart, en hâld it protokol konsekwint. UDP 1194 is de standert harker, wylst in TCP-profyl syn eigen harker oan 'e pakketkant nedich hat en in byhearrende trochstjoering op 'e router. TCP trochstjoere nei in tsjinst dy't allinnich op UDP harket jout stilte, gjin flater.

As it adres fan 'e NAS fan DHCP komt, reservearje it dan foardat de regel bewarre wurdt. It ferrinnen fan 'e lease jout it adres opnij, de trochstjoering bliuwt nei de âlde wearde wizen, en de hânshake begjint te mislearjen op in dei dat nimmen de NAS oanrekke hat. In statyske konfiguraasje oan 'e NAS-kant lost itselde probleem op, mits it adres bûten it DHCP-berik fan 'e router leit.

Bewiis oft de pakketten oait oankomme

Begjin earst in opname op 'e NAS, ferbyn dan fan 'e klient, en lês it boarne-adres yn 'e útfier. In opname dy't nei de flater begûn is, lit neat sjen en bewiist neat.

sudo tcpdump -i any -n udp port 1194

Stilte betsjut dat it ferkear foar de tsjinst stoarn is: in ferkeard ynterne adres, in sletten poart op 'e DSM-firewall, of in ynterface dat bestjoerlik út stiet. Pakketten yn 'e útfier betsjutte dat de trochstjoering wurket, en de oerbleaune flater leit boppe de netwurklaach, wat in folle lytser sykgebiet is.

De opname neamt ek it ynterface dêr't it pakket op oankaam, en dat iene detail skiedt in regel rjochte op 'e ferkearde poart fan in regel rjochte op in poart dy't net omheech is. Hâld by deselde poging it eigen teller fan 'e router yn 'e gaten as dy ien toant. In teller dy't net beweecht wylst de opname leech bliuwt, wiist nei de router, wylst in teller dy't beweecht mei in lege opname nei it paad tusken de twa apparaten wiist.

As de pakketten oankomme, hâld op de trochstjoering de skuld te jaan

It profyl is de folgjende fertochte, en de gewoane reden is leeftyd. In eksportearre .ovpn-bestân befettet it bewâld en it materiaal fan it momint fan eksport, dus in pakket waans sertifikaat letter ferfongen is, sil in klient ôfwize dy't noch de âlde kopy draacht.

Ferfier is de oare mismach dy't it wurdich is om eksplisyt te kontrolearjen, want it profyl en it pakket wurde op ferskate plakken bewurke. In profyl fan UDP nei TCP feroarje sûnder it pakket om te skeakeljen lit de klient wachtsje op in harker dy't net bestiet, en de klient rapportearret deselde algemiene hânshaketekst dy't hy foar al it oare rapportearret. Lês de proto-rigel yn it bestân, sjoch dan nei it protokol dat op 'e serverside keazen is, en konkludearje pas dan dat se oerienkomme. De firewallregels fan DSM lêze is de tredde kontrôle: in regel dy't de poart fan it lokale subnet tastean lit mar net fan it ynternet, bliuwt nei it testen maklik efter, en hy jout in ferbining dy't fan 'e keuken ôf wurket en oeral oars misleit.

Test it paad dat in ôfstân brûker wier nimt

In klient yn itselde LAN kin de NAS berikke sûnder ea de trochstjoering oan te reitsjen, dus dat bewiist neat oer ôfstân tagong. Brûk in tillefoan mei Wi-Fi út, of freegje immen bûten it netwurk, en hâld by dy poging it teller fan 'e router yn 'e gaten. As de ôfstân poging misleit wylst de lokale slagget, binne de trochstjoering of de firewall noch yn byld.

Skriuw de wurkjende steat op wylst it wurket: eksterne poart, ynterne adres, protokol, pakketynterface, en de profylnamme en eksportdatum. As de hânshake wer misleit, is it ferskil tusken dy notysje en de hjoeddeistige konfiguraasje de flater, en nimmen hoecht wer te ûntdekken hokker fan 'e twa poarten de tsjinst brûkt.