How to fix this relationship in order to not break the LSP?
LSP violation is only a problem if you have client code that implements logic operating on polymorphic variables of the Person type (i.e. the concrete type could be any derivative of Person). If you instead have, say, a Company class that only ever works with the Employee type, and has really nothing to do with Person, then in the context of Company it doesn't matter that Employee breaks LSP or inherits from Person, because Company is not relying at all on the abstract behavior of Person. In this case, Employee inherits some implementation details from Person, but doesn't subtype it (as defined by LSP).
But if you have logic that polymorphically uses Person, then you care about LSP violations because they'll either break your code, or will force you to do type-checking, complicate your implementation, and introduce coupling that will tangle your code in various ways.
If Person specifies that ages 0 and above are allowed, then client code can rely on that fact - that's what types are for. The calling code can legitimately make this assumption, and can be written in a way that will cause it to break otherwise. So, since the Employee violates that guarantee, it is not a behavioral subtype of Person - even though an Employee is a Person when classified in a different way. There's generally more than one way to classify things in the world, depending on what you choose as your classification criteria. For subtyping, it is the abstract behavior (behavioral specification) that is the relevant classification criterion. Inheritance is often described as an "is-a" relationship, however "is-a" is too simplistic. A person is an employee. An employee is a person. Now what?
Aside: What's a bit confusing is that the same language mechanism (inheritance) can be used to implement two different kinds of relationships that are of interest to programmers: subtyping and implementation inheritance.
If you have code that does involve the Person type, then consider what that code actually does: if the calling code doesn't really need to set the age, then you can remove that method in the base type (this is under the assumption that there are other methods there that are not shown).
Or, you could reconceptualize the whole thing; you could pass the birth date to the constructor, and only have a getter for the age, that calculates the age based on the current date (that's a hidden dependency on a time-providing component, but it would eliminate this particular LSP violation). The details of the constructor are generally not a part of the abstract behavior, because clients that use polymorphic objects typically don't know the concrete type, as they are not the ones that create these objects.
Technically, you could also change the base type specification to say that setAge could throw an exception for any number; that would make Employee compatible, but it would also make setAge almost useless.
Finally, as others have pointed out, not everything has to be represented by inheritance. Composition is often a more flexible alternative to inheritance. Depending on your application, an Employee could be a distinct concept in your system, with a reference to a Person. Or maybe, depending on what your application is for, you don't need a separate Person class in your system at all. Or some other alternative.
Remember, the goal is not to identify concepts and classify them to create some inheritance hierarchy that reflects a preliminary understanding of these relationships that your mind happened to conjure at the time. The goal is to create a piece of software that serves the needs of its users, while making use of strategies that will make your job easier in terms of reasoning about what's happening in the code, and in terms of making changes and maintaining the code. LSP is one such strategy.