OpenVPN sur pordo 53: tri interparoloj, kiujn homoj konfuzas
La serĉo de la finpunkto, la ĉifrita transporto kaj DNS post la tunelo estas tri apartaj interparoloj. Identigu, kiu stadio malsukcesis, antaŭ ol ŝanĝi pordon aŭ solvilon.
Raportoj, kiuj diras, ke la VPN estas blokita sur pordo 53, miksas tri observojn, kiuj malsukcesas pro malsamaj kaŭzoj. La solvo de la finpunkta nomo okazas antaŭ ol ekzistas iu ajn tunelo, la ĉifrita transporto estas aparta interparolo, kaj la DNS-demandoj faritaj poste estas tria. Ĉiu havas sian propran malsukcesan subskribon, kaj nur unu el ili temas pri DNS entute.
Ordigi la pakojn laŭ celo antaŭ ol ŝanĝi ion ajn, ĉar la riparo sekvas la stadion.
Tri interparoloj, unu porda numero
La unua interparolo estas noma serĉo por la finpunkto: via maŝino demandas al sia agordita solvilo, kie troviĝas vpn.example.com, kaj tiu respondo alvenas per ordinara DNS antaŭ ol la kliento sendas eĉ unu tunelan pakon. La dua estas la transporto de OpenVPN mem, kiu konektiĝas al la adreso, kiun produktis la serĉo, per tiu protokolo kaj pordo, kiujn la profilo nomas. La tria okazas post ol la tunelo ekfunkcias, kiam aplikaĵoj petas nomojn kaj la puŝitaj solvilaj agordoj decidas, kiu respondos.
Tiuj tri povas sukcesi aŭ malsukcesi sendepende. Kliento povas perfekte solvi sian finpunkton kaj tamen ne atingi la aŭskultanton, kaj ĝi povas starigi tunelon dum ĉiu interna noma serĉo malsukcesas ĉar la DNS-agordoj neniam alvenis.
| 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 |
Legu la tabelon kiel kontrolkielon, ne kiel priskribon. Se la finpunkta nomo ne solviĝas, nenio poste povas funkcii, kaj la tunelo neniam komenciĝas.
La porda numero ne nomas la aplikaĵon
Pordo 53 portas DNS laŭ konvencio, kaj OpenVPN-funkciiganto ankaŭ povas publikigi aŭskultanton tie, kaj ĝuste tial la numero estas malbona identigilo. OpenVPN-sesio sur UDP 53 restas OpenVPN-sesio, kaj DNS-demando al servilo sur pordo 53 diras nenion pri tio, ĉu tunelo estas permesata. La linioj proto kaj remote de la profilo difinas la eksteran finpunkton; la porda numero difinas nenion per si mem.
Tio tranĉas ambaŭdirekte dum diagnozado: ĝenerala UDP-sondo al pordo 53 pruvas, ke pordo respondas, ne ke la VPN-servo respondas. Testu per la reala kliento kaj la reala profilo, ĉar nur tio ekzercas la manpremon, kiun la servo atendas.
Pruvu la aŭskultanton antaŭ ol kulpigi la reton
Sur la servilo, konfirmu, kio estas ligita per ss -lunp | grep 53 kaj komparu ĝin kun la protokolo kaj pordo de la profilo. El la reto de la kliento, rulu la klienton kun pli alta detalo, por ke la protokolo montru, kiun adreson kaj transporton ĝi provis. Se la servilo aŭskultas kaj la pakoj de la kliento ne alvenas, la vojo aŭ la politiko rifuzas ilin, kaj tio estas interparolo por la retposedanto prefere ol kaŭzo ŝanĝi pordojn.
Alia pordo helpas nur kiam la servo vere aŭskultas tie kaj la deplojo permesas ĝin. Movi aŭskultanton por eviti la filtradon de administrata reto estas politika decido, ne paŝo de problemtraktado. Demandu la retposedanton, kio estas permesita, antaŭ ol ŝanĝi la servon, ĉar provizora solvo, kiu malobservas politikon, estos fermita poste ĉiuokaze. Notu tiun respondon apud la profilo, por ke la sekva persono ne ripetu la peton.
Kontrolu DNS post la tunelo, aparte
Post kiam la tunelo ekfunkcias, inspektu la staton de la solvilo sur la VPN-kuplilo kaj demandu unu internan kaj unu publikan nomon. Se internaj nomoj malsukcesas dum la tunelo portas trafikon, la puŝitaj DNS-agordoj ne estis aplikitaj, kio estas demando de klienta integriĝo kaj ne de transporto. Se publikaj nomoj malsukcesas kaj internaj funkcias, la disiga tunela politiko faras tion, por kio ĝi estis agordita.
Lasu DNS-ŝanĝojn ĉe la posedanto de la solvilo. Anstataŭigi administritan solvilan agordon por ke unu testo pasu povas rompi privatajn nomojn por ĉio alia sur la maŝino. Se la tunelo puŝas solvilon kaj la kliento ignoras ĝin, ripari la klientan integriĝon anstataŭ aldoni statikan eron aliloke. Statikaj eroj kaŝas la malsukceson ĝis iu ŝanĝas reton. Notu, kiu solvilo devas respondi al ĉiu nomspaco.