OpenVPN 53. portuan: jendeak nahasten dituen hiru elkarrizketa
Muturreko izenaren bilaketa, transport kriptatua eta tunelaren osteko DNS hiru elkarrizketa dira. Zehaztu zein fasek huts egin duen portua edo ebazlea aldatu aurretik.
VPNa 53. portuan blokeatuta dagoela dioten txostenek arrazoi desberdinengatik huts egiten duten hiru behaketa nahasten dituzte. Muturreko izenaren ebazpena tunelik existitu aurretik gertatzen da, transport kriptatua elkarrizketa bereizia da, eta ondoren egiten diren DNS kontsultak hirugarrena dira. Bakoitzak bere hutsegite sinadura du, eta horietako bakarra da DNSari buruzkoa.
Sailkatu paketeak helburuaren arabera ezer aldatu aurretik, konponbidea faseari jarraitzen baitio.
Hiru elkarrizketa, portu-zenbaki bat
Lehen elkarrizketa muturreko izenaren bilaketa da: zure makinak konfiguratutako ebazleari galdetzen dio non dagoen vpn.example.com, eta erantzun hori DNS arruntaren bidez iristen da, bezeroak tunel pakete bakarra bidali aurretik. Bigarrena OpenVPNren transporta bera da, bilaketak emandako helbidera konektatzen dena, profilean adierazitako protokolo eta portuaren bidez. Hirugarrena tunela martxan dagoenean gertatzen da, aplikazioek izenak eskatzen dituztenean eta bultzatutako ebazlearen ezarpenek erabakitzen dutenean nor den erantzungo duena.
Hiru horiek modu independentean arrakastatu edo huts egin dezakete. Bezero batek bere muturra primeran ebatzi eta hala ere hartzailearengana irits ez daiteke, eta tunela ezar dezake barneko izen bilaketa guztiek huts egiten duten bitartean, DNS ezarpenak inoiz iritsi ez direlako.
| 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 |
Irakurri taula kontrol-zerrenda gisa, ez deskribapen gisa. Muturreko izena ebazten ez bada, ezin du ezerk geroago funtzionatu, eta tunelak ez du inoiz hasiko.
Portu-zenbakiak ez dio aplikazioari izena ematen
53. portuak DNS darama ohituraz, eta OpenVPN eragile batek hartzaile bat ere argitara dezake han, eta horregatik da zenbakia identifikatzaile txarra. UDP 53ko OpenVPN saio bat OpenVPN saio bat da oraindik, eta 53. portuko zerbitzari bati egindako DNS kontsultak ez du ezer esaten tunela baimenduta dagoen ala ez. Profileko proto eta remote lerroek kanpoko muturra definitzen dute; portu-zenbakiak ez du ezer definitzen berez.
Hori bi norabideetan ebakitzen da diagnostikatzean: 53. porturako UDP proba orokor batek portu batek erantzuten duela frogatzen du, ez VPN zerbitzuak erantzuten duela. Probatu benetako bezeroarekin eta benetako profilearekin, horrek bakarrik lantzen baitu zerbitzuak espero duen esku-ematea.
Frogatu hartzailea sareari errua bota aurretik
Zerbitzarian, egiaztatu ss -lunp | grep 53 erabiliz zer dagoen lotuta eta alderatu profileko protokolo eta portuarekin. Bezeroaren saretik, exekutatu bezeroa zehaztasun handiagoz, erregistroak erakuts dezan zein helbide eta transport saiatu zuen. Zerbitzariak entzuten badu eta bezeroaren paketeak iristen ez badira, bideak edo politikak ukatzen ditu, eta hori sarearen jabearentzako elkarrizketa da, ez portuak aldatzeko arrazoia.
Beste portu batek orduan bakarrik laguntzen du, zerbitzuak benetan han entzuten duenean eta hedapenak hori baimentzen duenean. Kudeatutako sare baten iragazkia saihesteko hartzailea mugitzea politika-erabakia da, ez arazoak konpontzeko urratsa. Galdetu sarearen jabeari zer den baimenduta zerbitzua aldatu aurretik, politikak urratzen dituen aldi baterako irtenbidea geroago itxiko baita. Idatzi erantzun hori profilaren ondoan, hurrengo pertsonak eskaera ez errepikatzeko.
Egiaztatu DNS tunelaren ondoren, bereizita
Tunela martxan dagoenean, aztertu ebazlearen egoera VPN interfazean eta galdetu barneko izen bat eta izen publiko bat. Barneko izenek huts egiten badute tunelak trafikoa daraman bitartean, bultzatutako DNS ezarpenak ez dira aplikatu, eta hori bezeroaren integrazioaren kontua da, ez transportarena. Izen publikoek huts egiten badute eta barnekoek funtzionatzen badute, tunel zatituaren politikak konfiguratu zen bezala egiten du.
Utzi DNS aldaketak ebazlearen jabearen esku. Kudeatutako ebazle konfigurazio bat gainidazteak proba bat pasa dadin makina osoko gainerako guztientzako izen pribatuak hauts ditzake. Tunelak ebazle bat bultzatzen badu eta bezeroak alde batera uzten badu, konpondu bezeroaren integrazioa, beste nonbait sarrera estatikoa gehitu beharrean. Sarrera estatikoek hutsa ezkutatzen dute norbaitek sarea aldatzen duen arte. Idatzi zein ebazlek erantzun behar duen izen-espazio bakoitzean.