Miks privaatne lõpp-punkt vastab endiselt avaliku aadressiga
Jälgige päringut sülearvutist väljapoole: milline resolver vastab, milline aadress tuleb tagasi ja mis tuleb siduda, enne kui privaatne lõpp-punkt on kättesaadav.
Sülearvuti ühendub, tunnel teatab, et on üleval, ja salvestuskonto keeldub endiselt igast päringust. Privaatne lõpp-punkt on olemas, marsruut selle alamvõrku on olemas, ja nimi kas vastab avaliku aadressiga või ei lahene üldse. Tunneliga pole midagi valesti: kliendile ei öeldud kunagi, milline server peaks selle nime eest vastama. Jälgige päringut väljapoole ja lünk muutub ilmseks.
Alustage kliendi resolverist
Küsige kliendilt, millist serverit see küsitleb, kui tunnel on üleval. Punkt-kohta-profiil annab selle aadressi, ja profiil, mis ei anna midagi, jätab opsüsteemile kohandaja vaikeväärtustele taganemise.
Avalikel resolveritel puudub privaatsest tsoonist igasugune vaade, seega vastavad nad internetist, mis on täpselt nende töö. Esimene kontroll on seega kasutatav resolveri aadress, mitte tunnel ja mitte lõpp-punkt.
Lugege, mis vastus tegelikult on
Lahendage teenuse nimi ja lugege tagasi tulev aadress. Avalik vastus tähendab, et päring jõudis serverisse, mis tsooni ei näe. Vastuse puudumine tähendab, et nimi on olemas ainult privaatselt ja miski, mida klient saab kätte, ei hoia seda.
Need kaks tulemust tekitavad sarnaseid rakendusevigu ja kuuluvad erinevatele omanikele. Üks on resolveri valiku probleem, teine on puuduv tsooni link.
Hosts-kirje tõestab tee ja valetab siis
Lõpp-punkti aadressi panemine kohalikku hosts-faili on kiireim viis tõestada, et tunnel ja teenuse tulemüür juba töötavad. Kui päring selle kirjega õnnestub, on katki ainult nimede lahendamine. See on ka ühe masina muudatus, mis katab täpselt ühe nime.
See ei aita teist kontot, teist lõpp-punkti ega kolleegi, ja see puruneb hoiatamata, kui lõpp-punkt luuakse uuel aadressil uuesti.
Veel hullem, see paneb sinu masina käituma teisiti kui kõigi teiste oma, ja nii elab resolveri rike üle nädalase uurimise. Kasuta seda tee kinnitamiseks, seejärel eemalda see ja paranda põhjus.
Siduge tsoon ja jagage resolver välja
Kaks tingimust peavad kehtima korraga. Privaatne tsoon peab olema ühendatud virtuaalvõrguga, kus lõpp-punkt asub, ja klient peab saatma oma päringud serverile, mis suudab seda tsooni lugeda. DNS Private Resolveri sissetulev lõpp-punkt pakub sellise aadressi võrgu sees ja vastab tunnelist saabuvatele päringutele. Pange see aadress VPN-profiili ja lisage privaatne sufiks, mida klient peab rakendama.
Juba olemasolev kohalik resolver võib sama tulemuseni jõuda tsoonile suunatud tingimusliku edastajaga.
Resolveri võrgureeglid loevad sama palju kui marsruutimine. Kui sissetulev reegel jätab VPN-kliendi vahemiku välja, aeguvad päringud, selle asemel et anda vale vastus. Just see aegumine saadab inimesed tagasi marsruutimistabeli juurde, kus miski pole valesti.
Kontrollige nime, porti ja identiteeti järjekorras
Töötage järjekorras: lahendage nimi, kinnitage, et vastus on privaatne, avage port, seejärel tehke autenditud päring. Igal etapil on oma omanik ja oma rikkeallkiri.
Privaatne vastus, millele järgneb aegumine, viitab marsruudile või tulemüürile. Avalik vastus viitab resolverile. Lõpetatud ühendus, mis tagastab identiteedivea, kuulub teenusele.
Sellesse nimekirja kuulub veel üks rike. Teenuse tulemüür, mis lubab kliendi aadressi, lakkab sobimast, kui bassein annab selle aadressi pärast taasühendamist teisele seansile. Lugege kutsuja aadressi, mille teenus salvestas, mitte seda, mille klient arvab endal olevat. Need kaks lahknevad sagedamini, kui inimesed ootavad. Azure DNS Private Resolveri juhend katab tsooni lingi ja edastamise korralduse.