Ĉu OpenVPN-manpremo malsukcesas ĉe Synology? Kontrolu la LAN-plusendadon

Via tekkomputilo raportas, ke la TLS-manpremo malsukcesis, do la tento estas rekonstrui la atestilojn. Antaŭe demandu pli enuan demandon: sur kiu Ethernet-haveno la Synology efektive aŭskultas? NAS kun du LAN-havenoj havas du adresojn, kaj la pakaĵo VPN Server de DSM ligas sian OpenVPN-aŭskultanton al unu el ili. Kiam la kurskurilo plusendas 1194 al la alia adreso, neniu paketo iam atingas la servon, kaj la kliento havas nenion por intertrakti.

La erarteksto trompas, ĉar ĝi priskribas la lastan aferon, kiun la kliento provis, ne la unuan, kiu misfunkciis. Du minutoj da komparo de la pakaĵa paĝo kun la kurskurila regulo solvas ĝin.

Trovu la adreson, al kiu la aŭskultanto estas ligita

DSM nomas siajn havenojn LAN 1 kaj LAN 2, kaj ĉiu portas apartan adreson kaj subreton. Malfermu VPN Server, legu la interfacon nomitan en la langeto OpenVPN, poste malfermu la Stirpanelon kaj notu la IPv4-adreson, kiun DSM havas sur tiu sama interfaco. Tiujn du valorojn, ne la gastigantnomon de la NAS, devas nomi la plusendado.

Dua enŝovita kablo ne kreas duan aŭskultanton. Ambaŭ ligiloj povas aperi konektitaj, dum nur unu adreso akceptas la trafikon, kaj kiam ambaŭ interfacoj situas en la sama subreto, la du adresoj diferencas per cifero, kiun neniu relegas antaŭ ol konservi regulon.

Rigardu la soketon mem per SSH, ĉar tio estas la sola loko, kiu montras, al kio la demono efektive ligiĝis, anstataŭ kion celas la agorda paĝo.

sudo netstat -anp | grep 1194

Redaktu la ekzistantan plusendadon anstataŭ aldoni alian

Du reguloj por unu ekstera haveno lasas la kurskurilon libere elekti, kaj kiun ĝi elektas povas ŝanĝiĝi post firmvara ĝisdatigo aŭ restartigo. Malfermu la regulon, kiu jam ekzistas, ŝanĝu ĝian internan adreson, konservu, poste remalfermu ĝin kaj relegu la valoron. Nomigi la regulon laŭ la servo helpas, ĉar listo de kvin identaj plusendadoj estas la maniero, kiel la malĝusta postvivas.

external 1194/udp  ->  192.0.2.20:1194/udp

Tenu la internan havenon egalan al la aŭskulta haveno, kaj tenu la protokolon konsekvenca. UDP 1194 estas la implicita aŭskultanto, dum TCP-profillo bezonas sian propran aŭskultanton ĉe la pakaĵa flanko kaj kongruan plusendadon ĉe la kurskurilo. Plusendi TCP al servo, kiu aŭskultas nur sur UDP, produktas silenton, ne eraron.

Se la NAS-adreso venas de DHCP, rezervu ĝin antaŭ ol la regulo konserviĝos. La fino de la luo realjuĝas la adreson, la plusendado daŭre montras al la malnova valoro, kaj la manpremo komencas malsukcesi en tago, kiam neniu tuŝis la NAS. Statika agordo ĉe la NAS-flanko solvas la saman problemon, kondiĉe ke la adreso situas ekster la DHCP-gamo de la kurskurilo.

Pruvu, ĉu la paketoj entute alvenas

Unue komencu kaptadon ĉe la NAS, poste konektiĝu de la kliento, kaj legu la fontadreson en la eligo. Kaptado komencita post la malsukceso montras nenion kaj pruvas nenion.

sudo tcpdump -i any -n udp port 1194

Silento signifas, ke la trafiko mortis antaŭ la servo: malĝusta interna adreso, fermita haveno ĉe la DSM-fajroŝirmilo, aŭ interfaco administre malŝaltita. Paketoj en la eligo signifas, ke la plusendado funkcias, kaj la cetera fuŝo kuŝas super la reta tavolo, kio estas multe pli malgranda serĉareo.

La kaptado ankaŭ nomas la interfacon, sur kiu la paketo alvenis, kaj tiu sola detalo apartigas regulon direktitan al la malĝusta haveno de regulo direktita al haveno, kiu ne estas supren. Observu la propran nombrilon de la kurskurilo dum la sama provo, se ĝi montras unu. Nombrilo, kiu ne moviĝas dum la kaptado restas malplena, indikas la kurskurilon, dum nombrilo, kiu moviĝas kun malplena kaptado, indikas la vojon inter la du aparatoj.

Kiam paketoj alvenas, ĉesu kulpigi la plusendadon

La profilo estas la sekva suspektato, kaj la kutima kialo estas aĝo. Elportita .ovpn dosiero enhavas la aŭtoritaton kaj materialon el la momento de la elporto, do pakaĵo, kies atestilo poste anstataŭiĝis, malakceptos klienton, kiu ankoraŭ portas la malnovan kopion.

Transporto estas la alia malkongruo inda je eksplicita kontrolo, ĉar la profilo kaj la pakaĵo redaktiĝas en malsamaj lokoj. Ŝanĝi profilon de UDP al TCP sen ŝalti la pakaĵon lasas la klienton atendi aŭskultanton, kiu ne ekzistas, kaj la kliento raportas la saman ĝeneralan manpreman tekston, kiun ĝi raportas por ĉio alia. Legu la linion proto en la dosiero, poste rigardu la protokolon elektitan sur la servila paĝo, kaj nur tiam konkludu, ke ili kongruas. Legi la DSM-fajroŝirmilajn regulojn estas la tria kontrolo: regulo, kiu permesas la havenon el la loka subreto sed ne el la interreto, facile restas post testado, kaj ĝi produktas konekton, kiu funkcias el la kuirejo kaj malsukcesas el ĉie alie.

Testu la vojon, kiun fora uzanto efektive iras

Kliento en la sama LAN povas atingi la NAS sen iam tuŝi la plusendadon, do ĝi pruvas nenion pri fora aliro. Uzu telefonon kun malŝaltita Wi-Fi, aŭ demandu iun ekster la reto, kaj observu la nombrilon de la kurskurilo dum tiu provo. Se la fora provo malsukcesas dum la loka sukcesas, la plusendado aŭ la fajroŝirmilo ankoraŭ estas en la bildo.

Notu la funkcian staton dum ĝi funkcias: ekstera haveno, interna adreso, protokolo, pakaĵa interfaco, kaj la profila nomo kaj elporta dato. Kiam la manpremo denove malsukcesos, la diferenco inter tiu noto kaj la nuna agordo estas la fuŝo, kaj neniu devas ree malkovri, kiun el la du havenoj la servo uzas.