VPN-útvonal ellenőrzése macOS-en: route get bármilyen változtatás nélkül

Egy felhasználó az irodai hálózaton éri el az intranetet, nem az alagúton keresztül, miközben a Beállítások továbbra is csatlakozottként mutatják a VPN-t. Az útvonaltábla szerkesztése abban a pillanatban kockáztatja, hogy elvágja azt a távoli munkamenetet, amelyet a diagnosztizáláshoz használ. Kérdezze meg inkább a kerneltől, melyik utat választaná a hibázó hoszthoz. A macOS route segédprogramjának van get művelete, amely pontosan erre válaszol, egy célállomásra, anélkül hogy bármit változtatna.

A hibázó hostot kérdezze, ne az alapértelmezettet

Az alapértelmezett útvonal képernyőképe modern Macen nagyon keveset mond, mert egy konkrétabb célállomás vagy korlátozott szabályzat felülírhatja azt, amit az alapértelmezett útvonal mondani látszik. Az alagút lehet fent, az alapértelmezett útvonal tűnhet helyesnek, és a szükséges egyetlen host mégis máshová lehet irányítva. Kérdezze le a hibázó címet, és hagyja, hogy a kernel megnevezze a választott utat.

A forma a route -n get, amelyet a cím követ: route -n get 203.0.113.10, ahol a dokumentációs cím a célját képviseli. Használja az engedélyezett célállomást és a megfelelő címcsaládot, mert egy IPv4-válasz semmit sem mond egy csak IPv6-os erőforrásról. A route segédprogram dokumentációja leírja a get műveletet és a kiírt mezőket.

Az interfészt és az átjárót bizonyítékként olvassa

Futtassa a lekérdezést a VPN csatlakoztatása előtt, majd utána ismét, és hasonlítsa össze az interfész és az átjáró sorait. A két válasz közötti különbség az, amit az alagút valójában megváltoztatott, és sokkal hasznosabb, mint a teljes tábla kiírása. Ha az interfész mindkét futásban azonos, az útvonal soha nem volt a probléma, és abbahagyhatja az útválasztás vizsgálatát.

Jegyezze fel a célállomást, az interfészt, az átjárót és a lekérdezés idejét, mielőtt következtetést von le. A kimenet bizonyíték, nem diagnózis: ugyanaz az interfész lehet helyes az egyik hostnak és helytelen a másiknak, ha osztott alagút van a játékban.

A helyes útvonal nem működő kérés

Az útvonal megmondja, melyik interfészt használná a kernel, és semmi többet. A DNS, a host tűzfala és az alkalmazás engedélyezése mind e döntés felett állnak, és a kérés az útválasztás sikeressége után is meghiúsulhat. Őrizze meg a pontos tünetet, mielőtt továbblép, mert a "nem tud csatlakozni" és a "csatlakozik, de hibát ad vissza" különböző vizsgálatok különböző következő lépésekkel. A feloldó nézete és az interfész nézete kiegészíti a célállomás-lekérdezést, ahelyett hogy helyettesítené.

Az útválasztási tábla listájának még mindig van helye: így vesz észre egy váratlan alapértelmezett útvonalat. Egy megmaradó közönséges alapértelmezett útvonal nem bizonyítja, hogy a VPN használaton kívül van, mert a konkrétabb bejegyzések felülkerekednek rajta.

Tartsa külön a végpontot és az erőforrást

Két keresés van a játékban, és különböző kérdésekre válaszolnak. A végpont elérése külső utazás a fizikai hálózaton keresztül. Az alkalmazás elérése az alagúton belül történik, egy címen, amely csak a privát oldalon létezik. A kettő összekeverése hozza létre a klasszikus hamis hurkot, amelyben a végpont úgy tűnik, mintha azon az alagúton haladna át, amelyet lezár. Kérdezze le a két címet külön-külön, címkézze fel mindegyik eredményt, és a zavar eltűnik.

A prefixek átfedése a másik eset, amelyet érdemes ismerni. Amikor a helyi és a távoli tartományok átfednek, a leghosszabb prefix egyezése dönt, így egy átfedő helyi alhálózat árnyékolhatja a várt távoli címet. A privát célállomás ekkor azonosnak látszik egy helyivel, és a javítás a címtervbe tartozik, nem az útvonaltáblába. A get lekérdezés megmutatja, melyik interfész nyert, és ez az a tény, amelyre szüksége van, mielőtt bármit megváltoztat.

Előbb olvasson, később változtasson

Tartsa a route add és a route delete parancsot az első körön kívül. Egy távolról felügyelt Macen egy gondatlan táblaszerkesztés éppen a géphez visszavezető utat veheti el, és nem marad senki, aki befejezné a diagnózist. Döntse el, melyik a helyes útvonal, írja le, hogyan lehet visszavonni a változtatást, és csak azután futtassa. Az ellenőrzésnek nincs ilyen farka.

Ugyanez az óvatosság vonatkozik a gyorsítótárak törlésére és a hálózati szolgáltatások újraindítására első lépésként, mert mindkettő tönkreteszi a bizonyítékot, amelyet éppen olvasni készült. A csak olvasó ellenőrzések olcsók, megismételhetők és bármilyen sorrendben biztonságosak. Tegye őket alapértelmezett lépéssé, és csak akkor nyúljon változtatáshoz, amikor a bizonyíték arra mutat.