Valóban a VPN-en megy át a forgalom? Így ellenőrizheti

Két hiba egyformán néz ki a tálca ikonjáról: a forgalom, amely belép az alagútba, és a forgalom, amely csendben megkerüli azt. Az ügyfél mindkét esetben Connected feliratot mutat, mert a Connected csak azt jelenti, hogy létezik az alagút interfésze, és az ügyfél telepítette a kívánt útvonalakat. Az már külön kérdés, hogy egy alkalmazás egy csomagja használta-e ezeket az útvonalakat, erre a verem más pontján kapunk választ. Négy mérés eldönti a legtöbbet — az útvonalkeresés, az első ugrás, a fizikai adapteren végzett rögzítés és egy kívülről jövő megfigyelés —, a szerver saját munkamenet-nézete pedig a többit lefedi.

Kezdje azzal az útvonallal, amelyet a csomag követni fog

Az útválasztási tábla a döntés, ezért kérdezze meg egyetlen célról, ahelyett hogy az egészet elolvasná és találgatna. Linuxon a ip route get megnevezi azt az interfészt és forrás-címet, amelyet a kernel választott:

ip route get 203.0.113.10
ip route get 10.20.5.7

Windowson a Find-NetRoute -RemoteIPAddress 203.0.113.10 ugyanebből az okból hasznosabb, mint a route print -4: a nyertes útvonalat jelenti, nem az összes létezőt. Olvassa el mégis egyszer a táblát a 0.0.0.0 sora miatt. Egy ottani /1 pár azt jelenti, hogy egy teljes alagútas ügyfél átírta az alapértelmezett útvonalat: az OpenVPN redirect-gateway def1 beállítása a 0.0.0.0/1 és a 128.0.0.0/1 útvonalat az alagúton keresztül telepíti, ami a leghosszabb előtag-egyezésnél legyőzi a meglévő 0.0.0.0/0 útvonalat anélkül, hogy törölné a fizikai alapértelmezett útvonalat. Ezért létezhet két alapértelmezett útvonal egymás mellett, miközben minden továbbra is az alagútba megy.

Két részlet teszi hazuggá a táblát. Először is az egyező előtagot nézze, ne az alapértelmezett útvonalak számát, mert az interfész metrikája vagy egy /1 pár dönti el a nyertest. Másodszor, egy már létező kapcsolat megtartja azt az utat, amellyel létrejött; az alagút felemelkedése után egy nyitott munkamenet tovább használhatja a régi útvonalat a visszaállításig, és ezért tűnik úgy, hogy az újracsatlakozás megjavítja az útválasztási hibát. Egy futó ügyfél — ps ax | grep openvpn — csak azt bizonyítja, hogy a folyamat elindult.

Kövessen végig egy belső és egy nyilvános nevet

Az útvonalkeresés szándékot mutat; az útvonal a kézbesítést. Kapcsolódva kövessen végig egy nevet, amelynek belsőnek kell lennie, és egyet, amelynek nem, majd hasonlítsa össze az első ugrást:

traceroute intranet.corp.example
traceroute 1.1.1.1

Ugyanaz az első ugrás mindkettőnél azt jelenti, hogy a belső név soha nem került be az alagútba, és a hiba fölötte van, általában egy nyilvános címre feloldódó név vagy egy soha nem telepített útvonal. Ha a belső forgalom a 10.8.0.1-en keresztül lép ki, míg a nyilvános a 192.168.1.1-en, akkor a megosztott alagút pontosan azt teszi, amire beállították. Az a nyom, amely eléri a VPN-átjárót, majd csak időtúllépéseket ad vissza, általában visszatérési útvonal vagy kiszolgáló-tűzfal probléma, nem hiányzó továbbítási útvonal.

A szűrt ICMP hazuggá teszi ezt az ellenőrzést: csillagok mindkét nyomon úgy néznek ki, mint egy halott alagút, és általában tűzfal áll mögötte. Teszteljen TCP-portot, ahol tud — traceroute -T -p 443 Linuxon —, és ne feledje, hogy a nyom nem mondja meg, melyik feloldó válaszolt: egy név helyben is feloldódhat, és mégis elérhető az alagúton át.

A fizikai adapteren rögzítsen, ne az alagúton

A fizikai kapcsolat az egyetlen hely, amely megmutatja, mit lát valóban a hálózat. Az alagút fennállásakor az irodába menő munkamenetnek a VPN-kiszolgálónak címzett titkosított terhelésként kell megjelennie, nem a 10.20.5.7 felé menő kapcsolatként:

sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5

Az első szűrő a helyben kimenő névfeloldást kapja el, ami a leggyakoribb és leghalkabb szivárgás — az oldal még betöltődik, a feloldó csak látta a lekérdezést. A második a belső címre menő egyszerű forgalmat kapja el, amelynek csak az alagúton belül szabadna léteznie. Windowson a pktmon ugyanezt teszi illesztőprogram nélkül: pktmon filter add -p 53, majd pktmon start --capture --pkt-size 128, majd pktmon stop és pktmon format pktmon.etl -o capture.txt. Ezek a kapcsolók Windows-verziónként kissé eltérnek, ezért ellenőrizze a pktmon filter add /? beállítást, mielőtt megbízik a szintaxisban.

A fizikai interfészen rögzítsen, hogy megtalálja a szivárgásokat; az alagúton végzett rögzítés azokat a csomagokat tartalmazza, amelyekről már hiszi, hogy ott vannak, egy kiszolgálón pedig olvashatatlan külső csomagokat, amelyek forrása az átjáró. Bármely interfész bájtszámlálója csomagokat ír le, nem programokat; a forgalom folyamathoz rendeléséhez olyan monitor kell, amely a socketeket folyamatokhoz képezi le.

Kérdezzen meg egy külső szolgáltatást, majd kérdezze meg újra alkalmazásonként

Az egyetlen ellenőrzés, amely bizonyítja a kilépést, egy kívülről jövő válasz: olyan szolgáltatás, amely visszaadja a látott forráscímet. Futtassa shellből, ahol kiválaszthatja az interfészt, és futtassa kétszer:

sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ip

A különböző válaszok bizonyítékot adnak mindkét útvonalra, és módot egy adott alkalmazás tesztelésére: kösse hozzá, vagy futtassa egyetlen útvonalú hálózati névtérben, és nézze meg, melyik címet jegyzi fel a távoli vég. Az azonos válaszok az érdekes hiba: vagy a hozzákötés nem lépett életbe, vagy valami a gazdagép és a távoli vég között átírja a forráscímet, mielőtt megérkezne. Windowson a curl --interface az adapter címét kéri, nem a nevét.

A VPN-címet jelentő böngésző a böngészőt bizonyítja. Egy levelezőprogram, egy csomagkezelő, egy biztonsági mentési ügynök vagy egy második böngészőprofil külön-külön más útvonalat vehet, különösen amikor egy proxy-beállítás vagy egy megosztott alagút útvonala lefedi valamelyiket. A címváltozás önmagában nem bizonyíték a szivárgásra: egy terheléselosztó másképp válaszolhat a látott kimenet függvényében, ezért a feljegyzett forráscímet hasonlítsa össze, nem az oldalt.

A társ megerősítéséhez használja a szerver nézetét

A szerver más kérdésre válaszol: csatlakozva van-e egy társ, mennyit továbbított, és újraindult-e a munkamenet. Az a társ, amely aktív a szerveren, miközben az ügyfél számlálói alig mozdulnak, azt jelenti, hogy az alkalmazás forgalma nem kerül be az alagútba, bármit is mondott az ügyfél táblája. Az a társ, amely sok adatot mozgat olyan felhasználónak, aki szerint semmi sem működik, más vizsgálat.

Két csapda lapul itt. A maszkírozott alagút minden folyamot úgy mutat, mintha az átjárótól jönne, így a naplók és az ügyfelenkénti elszámolás egyetlen címre omlik össze. Az ügyfelet pedig helyi gazdagépként kezelik, ezért arra a kérdésre, hogy másol-e valaki fájlokat a VPN-en át, a kiszolgálón lévő fájlmegosztási forgalom vagy a kiszolgálón végzett gazdagép-audit válaszol — az alagút figyelése végpontokat és mennyiséget ad, fájlneveket nem.

Különböztesse meg a tervezési döntést a szivárgástól

Nem minden szivárgás, ami az alagúton kívül van. A kapcsolat-lokális és a szórási forgalom a tervezés szerint helyi marad, a multicast révén megtalált nyomtató tovább hirdet a LAN-on, a DHCP-nek pedig helyben kell kilépnie. Egy adott interfészhez kötött alkalmazás szándékosan megkerüli az útválasztási táblát, ezen csak tűzfalszabály, névtér vagy házirend-útvonal változtat.

IPv6 saját sort érdemel az ellenőrzőlistán. A csak IPv4-et vivő alagút második használható utat hagy egy kettős veremű gazdagépen, és a kettős veremű cél ezt fogja előnyben részesíteni — a DNS-t is beleértve, ha a feloldó IPv6-on át elérhető. Tiltsa le az IPv6-ot az adapteren, vagy erősítse meg, hogy az alagút viszi, mielőtt az IPv4-eredményt teljesnek tekinti.

Amikor az ellenőrzések nem egyeznek, az eltérés általában megnevezi a hibát:

Egy működő sorrend: mentse el az útválasztási táblát csatlakozás előtt és után, kövessen végig egy belső és egy nyilvános nevet, rögzítsen DNS-t a fizikai adapteren, adja vissza a kilépési címet a shellből az adott alkalmazásra, majd olvassa ki a szervert a mennyiségért. Ha az első négy egyezik, az alagút azt viszi, amit gondol, és a fennmaradó probléma fölötte van. Ha kettő eltér, az eltérő pár a hiba, nem az ikon.