Mi a VPN-alagút, és hol ér véget a védelem
Az alagút második borítékba tesz bizonyos csomagokat a már meglévő kapcsolat felett. Kövessen végig egy kérést, és lássa, melyik címet rögzíti valójában egy oldal.
A kliens szerint kapcsolódva, a lakat zárva, és egy oldal mégis rögzíti a lakása címét. Semmi nem hibázott. Az alagút nem helyettesíti a Wi-Fi vagy a mobil kapcsolatát; második borítékba tesz bizonyos csomagokat, és ezt a borítékot a már meglévő hálózaton küldi át. A trükk megértése főleg egyetlen kérés követéséről és annak észrevételéről szól, hol nyílik ki a boríték, mert szinte minden zavaró tünet, a kiszivárgó otthoni címtől a megakadt nagy letöltésig, ebből a határból ered.
Két boríték, egy fizikai kapcsolat
A laptop megtartja szokásos kapcsolatát a routerrel, a router pedig megtartja szokásos kapcsolatát a szolgáltatóval. Ezen az úton semmi nem változik, amikor feljön egy alagút. Az változik, hogy a kiválasztott csomagokat átadják egy virtuális interfésznek, becsomagolják egy új, a VPN-partnernek címzett csomagba, és szokásos forgalomként továbbítják a fizikai kapcsolaton.
A fogadó vég egy eszköz, amely kinyitja a borítékot, és az eredeti csomagot a célja felé továbbítja. A két vég között a megfigyelő a külső fejlécet látja, és semmit a belsőről, kivéve ha a protokoll titkosítja, amit a legtöbb fogyasztói protokoll megtesz, és amit az általános technika nem követel meg.
Ezért a virtuális interfész egyszerre valós és félrevezető. Kernelobjektumként létezik címmel és legnagyobb átviteli egységgel, és az operációs rendszer úgy irányít rá forgalmat, mint bármely más interfészre. Nem kábel, és a létezése csak azt bizonyítja, hogy egy összetevő telepítve van. Hogy a böngészője használja-e, azt az útvonalak döntik el, nem az, hogy az interfész fel van-e hozva.
Kövessen végig egy kérést az úton
Válasszon célpontot, és kérdezze meg a kernelt, melyik interfészt fogja használni. Ez az egyetlen parancs eldönti a viták többségét arról, hogy az alagút tesz-e egyáltalán valamit:
ip route get 203.0.113.7
ip -brief addr show
ip -4 addr show dev wg0Ha az útvonal kimenete az alagút interfészét nevezi meg, a csomag be lesz csomagolva. Ha a fizikai interfészt nevezi meg, nem lesz, és a kliens újraindítása ezen nem változtat. A második parancs egymás mellett mutatja a két interfészt, és így veszi észre az olyan alagutat, amely cím nélkül vagy rossz családból származó címmel jött fel.
Ezután nézze meg az első ugrást a boríték belsejéből, és hasonlítsa össze a kívülről látható első ugrással:
traceroute -n -m 3 203.0.113.7
sudo tcpdump -ni wg0 -c 5Az alagúton belül az első ugrás a partner belső címe, nem a routere. Az alagút interfészén végzett rögzítés a belső csomagokat mutatja, vagyis azt a forgalmat, amelyet az alkalmazás úgy hisz, hogy küld. A fizikai interfészen egyidejűleg végzett rögzítés a külső csomagokat mutatja, és a kettő együtt a legvilágosabb bemutatása annak, mit tesz valójában egy alagút.
Három cím, és csak egyet lát az oldal
Az emberek folyton összekeverik ezeket, és a zavar hamis szivárgási jelentéseket szül. Különböző fejlécek különböző mezői, különböző élettartammal.
| Address | Where it appears | Who can see it |
|---|---|---|
| Endpoint address | Outer header, the peer you connect to | Your access network and the path to it |
| Inner tunnel address | Inside the envelope, on the virtual interface | The peer, and anything the peer routes to |
| Exit address | Source of the packet that reaches the website | The website and its upstream |
A virtuális adapter melletti szám a második sor. Ez nem az a cím, amelyet egy oldal rögzít, és nyilvános IP-ként emlegetni egyszerűen hibás. Az oldal által látott címet a kijárat adja, és egy magánhálózati alagútnál lehet, hogy egyáltalán nincs nyilvános kijárat, mert a cél a szervezeten belül él, nem az interneten.
A telephelyek közötti alagút ugyanaz a mechanizmus más végpontokkal. Két router csomagol forgalmat hálózatok között, és egyetlen eszközön sincs kliens telepítve. A boríték elvileg azonos, a közigazgatási határ nem.
Hol nyílik ki a boríték, és mi éli túl
Az alagút a partnerénél ér véget. Ha az alkalmazás saját titkosítása tovább ér, túléli ezt a határt, ami a HTTPS normál esete: a böngésző munkamenete az oldalon ér véget, így a kijárat olyan titkosított szöveget továbbít, amelyet nem tud elolvasni.
Más alapértelmezésben nem éli túl. A titkosítatlan kérés a kijáratnál pontosan úgy olvasható, ahogy a kávézó Wi-Fi-jén olvasható volt, és az alagút nem ad olyan védelmet, amely az alkalmazásnak soha nem volt. Ugyanígy a kijárat tűzfal-szabályai és továbbítási irányelve döntik el, mi történik ezután; egy sikeres kézfogás a partnerkapcsolatról szóló tény, nem az utazás többi részéről.
A többletterhelés a másik látható következmény. Minden csomag további fejlécet hordoz, és a külső szállítás hozzáadhatja a sajátját, így a csomagonként használható hasznos teher csökken. Fix legnagyobb átviteli egységű útvonalon pontosan ezért tud egy alagút átengedni egy pinget, és megakasztani egy nagy feltöltést.
Ellenőrizze az útvonalat, amelyet az alkalmazás valóban megtett
Az utolsó lépés a konkrét alkalmazás megerősítése, nem a gép általában. Oldja fel a célt, nézze meg az adott cím útvonalát, majd figyelje a kapcsolatot, amíg nyitva van:
getent hosts example.com
ip route get "$(getent hosts example.com | awk '{print $1; exit}')"
ss -tnp state established '( dport = :443 )'Ha az útvonal az alagutat nevezi meg, de a socketlista a fizikai interfész forráscímével mutat kapcsolatot, az alkalmazás valami konkrétumhoz van kötve, vagy egy második alagút verseng az alapértelmezett útvonalért. Ez útválasztási kérdés, és ebből a három kimenetből megválaszolható, nem a kliens állapotképernyőjéről.
Az RFC 4301 biztonsági architektúra leírja ennek a csomagolásnak az IP-rétegű változatát az IPsec számára, és ugyanaz a réteglogika érvényes a WireGuardra és az OpenVPN protokollra. Amint meg tudja mutatni a belső csomagot és a külső csomagot külön objektumként, az alagút viselkedésének nagy része megszűnik rejtélyesnek lenni, és olvasható útválasztási táblázattá válik.