Kasutaja jõuab intranetti kontorivõrgus, mitte tunnelit pidi, samal ajal kui Seaded näitavad endiselt, et VPN on ühendatud. Marsruuditabeli muutmine sel hetkel võib katkestada kaugseansi, mida te diagnoosimiseks kasutate. Küsige selle asemel tuumalt, millise tee see nurjuva hosti jaoks valiks. macOS-i tööriistal route on get-toiming, mis vastab täpselt sellele, ühe sihtkoha jaoks, ilma midagi muutmata.

Küsige nurjuva hosti, mitte vaikimisi marsruudi kohta

Vaikimisi marsruudi ekraanipilt ütleb kaasaegses Macis väga vähe, sest täpsem sihtkoht või piiratud põhimõte võib üle kaaluda selle, mida vaikimisi marsruut näib ütlevat. Tunnel võib olla üleval, vaikimisi marsruut võib tunduda õige, ja ainus host, mida vajate, võib siiski olla suunatud mujale. Küsige nurjuva aadressi kohta ja laske tuumal nimetada valitud tee.

Vorm on route -n get, millele järgneb aadress: route -n get 203.0.113.10, kus dokumentatsiooni aadress esindab teie sihtmärki. Kasutage volitatud sihtkohta ja sobivat aadressiperekonda, sest IPv4 vastus ei ütle midagi ainult IPv6 ressursi kohta. Tööriista route dokumentatsioon kirjeldab get-toimingut ja välju, mida see väljastab.

Lugege liidest ja lüüsi tõendina

Käivitage päring enne VPN-i ühendamist ja seejärel uuesti pärast, ning võrrelge liidese ja lüüsi ridu. Nende kahe vastuse vahe on see, mida tunnel tegelikult muutis, ja see on palju kasulikum kui kogu tabeli väljavõte. Kui liides on mõlemas käivituses identne, ei olnud marsruut kunagi probleem ja võite marsruutimise vaatamise lõpetada.

Kirjutage üles sihtkoht, liides, lüüs ja päringu aeg enne järelduse tegemist. Väljund on tõend, mitte diagnoos: sama liides võib olla ühe hosti jaoks õige ja teise jaoks vale, kui mängus on poolitatud tunnel.

Õige marsruut ei ole toimiv päring

Marsruut ütleb, millist liidest tuum kasutaks, mitte rohkem. DNS, hosti tulemüür ja rakenduse volitus seisavad kõik selle otsuse kohal, ja päring võib nurjuda ka pärast seda, kui marsruutimine õnnestus. Säilitage täpne sümptom enne edasiliikumist, sest "ei saa ühendust" ja "ühendub, kuid tagastab vea" on erinevad uurimised erinevate järgmiste sammudega. Resolveri vaade ja liidese vaade täiendavad sihtkoha päringut, mitte ei asenda seda.

Marsruutimistabeli loendil on endiselt koht: nii märkate ootamatut vaikimisi marsruuti. Allesjäänud tavaline vaikimisi marsruut ei tõesta, et VPN on kasutamata, sest täpsemad kirjed võidavad selle üle.

Hoidke lõpp-punkt ja ressurss lahus

Kaasatud on kaks otsingut ja need vastavad erinevatele küsimustele. Lõpp-punkti jõudmine on väline teekond läbi füüsilise võrgu. Rakenduseni jõudmine toimub tunneli sees, aadressil, mis eksisteerib ainult privaatsel poolel. Nende kahe segamine tekitab klassikalise vale aasa, kus lõpp-punkt näib marsruutuvat läbi tunneli, mille see lõpetab. Küsige mõlema aadressi kohta eraldi, märgistage iga tulemus ja segadus kaob.

Prefiksi kattumine on teine juhtum, mida tasub teada. Kui kohalikud ja kauged vahemikud kattuvad, otsustab pikima prefiksi vaste, seega võib kattuv kohalik alamvõrk varjutada kaugt aadressi, mida te ootasite. Privaatne sihtkoht näeb siis välja identne kohalikuga ja parandus kuulub aadressiplaani, mitte marsruuditabelisse. Päring get näitab, milline liides võitis, ja see on fakt, mida enne millegi muutmist vajate.

Esmalt lugege, hiljem muutke

Hoidke route add ja route delete esimesest ringist väljas. Macis, mida haldad kaugelt, võib üks hooletu tabeli muudatus võtta just tee tagasi masinani ja jätta kedagi, kes diagnoosi lõpuni viiks. Otsustage, milline on õige marsruut, kirjutage üles, kuidas muudatust tagasi võtta, ja alles siis käivitage see. Ülevaatusel ei ole sellist saba.

Sama ettevaatlikkus kehtib vahemälu tühjendamise ja võrguteenuste taaskäivitamise kohta esimese sammuna, sest mõlemad hävitavad tõendi, mida te just lugema hakkasite. Ainult lugemiseks mõeldud kontrollid on odavad, korratavad ja ohutud igas järjekorras. Tehke need vaikimisi sammuks ja haarake muudatuse järele alles siis, kui tõend sellele osutab.

Seotud artiklid