OpenVPN op poort 53: drie gesprekke wat mense verwar
Endpunt-opsoek, die versleutelde vervoer en DNS ná die tonnel is drie afsonderlike gesprekke. Bepaal watter stadium gefaal het voordat jy ’n poort of ’n oplosser verander.
Verslae wat sê dat die VPN op poort 53 geblokkeer is, meng drie waarnemings wat om verskillende redes misluk. Die opsoek van die endpuntnaam gebeur voordat enige tonnel bestaan, die versleutelde vervoer is ’n afsonderlike gesprek, en die DNS-navrae wat daarna gedoen word, is ’n derde. Elkeen het sy eie mislukkingspatroon, en net een van hulle gaan oor DNS.
Sorteer die pakkette volgens doel voordat jy enigiets verander, want die regstelling volg die stadium.
Drie gesprekke, een poortnommer
Die eerste gesprek is ’n naamopsoek vir die endpunt: jou masjien vra sy gekonfigureerde oplosser waar vpn.example.com lê, en daardie antwoord kom oor gewone DNS voordat die kliënt ’n enkele tonnelpakket stuur. Die tweede is die OpenVPN-vervoer self, wat aan die adres koppel wat die opsoek opgelewer het, op watter protokol en poort die profiel ook al noem. Die derde gebeur nadat die tonnel op is, wanneer toepassings om name vra en die gestuurde oplosserinstellings besluit wie antwoord.
Daardie drie kan onafhanklik slaag of misluk. ’n Kliënt kan sy endpunt volmaak oplos en tog nie die luisteraar bereik nie, en hy kan ’n tonnel opstel terwyl elke interne naamopsoek misluk omdat die DNS-instellings nooit opgedaag het nie.
| Conversation | When it happens | What has to be true |
|---|---|---|
| Endpoint lookup | Before the client contacts a hostname | An underlying resolver path can answer for the endpoint name |
| OpenVPN transport | During tunnel establishment | The gateway listens on its configured transport, address and port, and nothing filters it |
| Application DNS | During or after the protected session | A resolver the client can reach, plus routing that carries its queries |
Lees die tabel as ’n kontrolelys, nie as ’n beskrywing nie. As die endpuntnaam nie oplos nie, kan niks later werk nie, en die tonnel begin nooit.
Die poortnommer noem nie die toepassing nie
Poort 53 dra DNS volgens konvensie, en ’n OpenVPN-operateur kan ook ’n luisteraar daar publiseer, en dit is juis waarom die nommer ’n swak identifiseerder is. ’n OpenVPN-sessie op UDP 53 is steeds ’n OpenVPN-sessie, en ’n DNS-navraag na ’n bediener op poort 53 sê niks oor of ’n tonnel toegelaat word nie. Die profiel se proto- en remote-lyne bepaal die buitenste endpunt; die poortnommer bepaal niks op sigself nie.
Dit werk twee kante toe wanneer jy diagnoseer: ’n generiese UDP-toets na poort 53 bewys dat ’n poort antwoord, nie dat die VPN-diens antwoord nie. Toets met die werklike kliënt en die werklike profiel, want net dit oefen die handdruk wat die diens verwag.
Bewys die luisteraar voordat jy die netwerk blameer
Bevestig op die bediener wat gebind is met ss -lunp | grep 53 en vergelyk dit met die profiel se protokol en poort. Voer die kliënt vanuit die kliënt se netwerk met hoër breedsprakigheid uit, sodat die log wys watter adres en vervoer hy probeer het. As die bediener luister en die kliënt se pakkette nie aankom nie, weier die pad of die beleid hulle, en dit is ’n gesprek vir die netwerkeienaar eerder as ’n rede om poorte te verander.
’n Ander poort help net wanneer die diens werklik daar luister en die ontplooiing dit toelaat. Om ’n luisteraar te skuif om die filter van ’n bestuurde netwerk te ontduik, is ’n beleidsbesluit, nie ’n probleemoplossingsstap nie. Vra die netwerkeienaar wat toegelaat word voordat jy die diens verander, want ’n tydelike oplossing wat beleid oortree, word later tog gesluit. Teken daardie antwoord langs die profiel aan sodat die volgende persoon nie die versoek herhaal nie.
Kontroleer DNS ná die tonnel, afsonderlik
Sodra die tonnel op is, ondersoek die oplosser se toestand op die VPN-koppelvlak en vra een interne naam en een openbare naam op. As interne name misluk terwyl die tonnel verkeer dra, is die gestuurde DNS-instellings nie toegepas nie, wat ’n kwessie van kliëntintegrasie is eerder as een van vervoer. As openbare name misluk en interne name werk, doen die split-tonnel-beleid wat dit gekonfigureer is om te doen.
Hou DNS-veranderinge by die eienaar van die oplosser. Om ’n bestuurde oplosserkonfigurasie te oorskryf om een toets te laat slaag, kan private name vir alles anders op die masjien breek. As die tonnel ’n oplosser stuur en die kliënt ignoreer dit, herstel die kliëntintegrasie eerder as om ’n statiese inskrywing elders by te voeg. Statiese inskrywings verberg die fout totdat iemand van netwerk verander. Skryf neer watter oplosser verwag word om elke naamruimte te antwoord.