The ascending node is wherever an orbit crosses the equatorial plane, going from south to north. The right ascension of that crossing, $\Omega$, is measured with respect to the distant stars, in an inertial frame. The longitude of that crossing is measured with respect to a stationary Earth, in a rotating frame. Relating one to the other requires knowledge of Greenwich hour angle, and if you need high precision, you need the International Astronomical Union precession and nutation (various wobbliness of the direction of Earth's rotational axis) theories, the measured and predicted Earth orientation parameters that go into the calculation, etc.
In the idealized case of a simple two-body ellipse, RAAN does not ever change; in real life, it does. In fact, we exploit the formula for how it changes to create certain specialized orbits, like the sun-synchronous ones which have every ascending node occur at the same local time of day.
LAN, on the other hand, only makes sense to talk about when the satellite has a repeating ground track, because otherwise every nodal crossing happens at a different longitude. This is usually useful primarily for geosynchronous spacecraft, because they complete an orbit every 86164 seconds, three minutes and 56 seconds shorter than a mean solar day. That period is chosen specifically to make their RAAN drift just enough to complete one rotation a year, in order to keep their LAN constant.
Defining LAN for a LEO is a strange choice, because a typical LEO completes more than a dozen orbits every day — which of those crossings, each at a different longitude, is the one you had in mind? The StarLink TLE you've got says mean motion is 15.428, which completes 108 orbits every 7 mean solar days. Even if that repeats (I don't think it does, because it's not a simple integer fraction of a sidereal day), which of those 108 locations is the one you want? The most recent one? The next one? The one closest to Elon Musk's house on Tuesdays?
TLEs are easy to get, but tricky to interpret, because the assumptions built into the definition are very complicated. To make sense of them, you need to use an algorithm called SGP4, which I recommend you get straight from the original source: the U.S. Space Force's https://space-track.org , as described here. There are also non-US-Government implementations, but using them incurs the risk that they might not exactly match the official version (since the code was last published in the 1980s, but according to the release notes from https://www.space-track.org/documentation#/sgp4 , they continue to speed it up and fix bugs). You should NOT attempt to code the equations yourself, because the math is really gnarly.
The official distribution comes with compiled libraries, a Python interface that wraps them (and equivalents in a large number of other languages), and an example "driver" program called Sgp4Prop.py . That requires you to specify start and stop time in a weird way, but if you follow the recipe, the driver will take in a TLE and a "6P card" and spit out five text files. One of these will be named "LatLonHeight.txt", which contains those numbers as well as others. Find the columns for latitude (2nd) and time (1st), find rows where latitude gets near zero, and interpolate from them to find a precise answer for when it becomes exactly zero.
If you want to do it all within Python and not bother computing or writing the other four files, you'll need to look mainly at line 304 of the driver,
self.Sgp4Prop.Sgp4PropDs50UTC(c_longlong(key), ds50UTC, byref(mse),
pos, vel, llh)
plus all the stuff before it that sets up the data structures (using ctypes) and after it that transforms the results into other units.
