Proč trasa VPN nezobrazuje bránu ve výstupu ip route
Řádek s rozhraním a bez brány je přímá trasa, ne rozbitá. Přečtěte cíl, dev a scope a pak to ověřte pomocí ip route get.
Směrovací tabulky se často čtou jako rozbité, kdykoli sloupec brány zůstane prázdný, i když je řádek obvykle sám o sobě úplný. Pole via se objeví jen tehdy, když jádro předá paket adrese dalšího skoku; trasa připojená k rozhraní dosahuje svých cílů místo toho přes rozlišení na linkové vrstvě nebo přes protějšek bod-bod. Čtení sloupců zleva doprava vám řekne, v jakém případě se nacházíte, a toto čtení by mělo proběhnout dřív, než někdo upraví výchozí trasu. Většina tiketů o chybějící bráně končí právě u tohoto rozlišení.
Čtěte řádek trasy sloupec po sloupci
Každý záznam začíná cílem a délkou jeho prefixu a pak přidává modifikátory v pevném slovníku: via, dev, proto, scope, src a metric. Řádek jako 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 je hustý, ale plně určený. Nic v něm nechybí a žádná adresa směrovače se v něm nenaznačuje.
Zajímavá je nepřítomnost via. Bez dalšího skoku jádro vyřeší cíl přímo na uvedeném rozhraní, což u tunelu znamená předat rámec tunelovému zařízení a nechat zapouzdření, ať se o něj postará odtud. proto kernel zaznamenává, že záznam byl nainstalován automaticky při přiřazení adresy, ne že ho napsal správce. scope link říká, že cíl je na tomto spoji dosažitelný bez průchodu směrovačem, a src pojmenovává adresu, kterou jádro upřednostní jako zdroj pro odpovídající provoz.
Teď přečtěte výchozí trasu stejně: default via 192.0.2.254 dev eth0 proto static metric 100. Zde je via přítomno, protože paket další skok skutečně potřebuje, a tento skok musí být sám dosažitelný na eth0. Ty dva řádky nejsou variantami jeden druhého; odpovídají na různé otázky o tom, kam provoz jde.
Dva tvary tras, které se navzájem pletou
Trasa podsítě tunelu a výchozí trasa vypadají na snímku obrazovky podobně a chovají se zcela odlišně. Použijte tabulku níže jako pomůcku pro čtení polí a poté ověřte skutečná čísla na stroji, který ladíte, místo abyste věřili ukázce z návodu.
| Piece of the line | What it settles | What it says nothing about |
|---|---|---|
| The destination and mask | Which packets are eligible to match | Where those packets leave the host |
via plus its address | Which next hop receives them, and therefore that a router is involved | Whether that router is reachable or sane |
dev | Which interface carries the encapsulated or raw packet | Whether the interface is up or has a carrier |
proto and scope | Who installed the entry and how far the destination is considered to be | Whether a firewall later drops the traffic |
Co vám tabulka nemůže říct, je záměr. Přímá trasa do privátního rozsahu přes tunel je záměrný návrh rozděleného tunelování; stejný tvar na hostiteli, který má posílat vše přes VPN, je příznakem. Záměr žije v konfiguraci, která záznam vytvořila, takže se podívejte na nástroj, který ho nainstaloval, než usoudíte, že jádro něco pokazilo.
Stejně tak chybějící brána není svolení si nějakou vymyslet. Pokud trasa skutečně potřebuje další skok, tento skok musí být dosažitelný na rozhraní, které ho nese, a u tunelu bod-bod není adresa protějšku stejný objekt jako lokální adresa. Považovat lokální adresu tunelu za ethernetový směrovač je častý způsob, jak vytvořit trasu, která vypadá správně a nic nepředává.
Zeptejte se jádra, který řádek skutečně použije
Čtení tabulky není totéž jako provedení vyhledání, protože jádro před odpovědí konzultuje pravidla zásad, několik tabulek a položky v mezipaměti. Sloveso, které provádí skutečné vyhledání, je ip route get, a vypisuje trasu, kterou by paket s těmito vlastnostmi šel.
ip route get 203.0.113.37 from 198.51.100.2 iif tun0Dosaďte cíl, na kterém vám skutečně záleží, a pak přidejte from nebo iif, když je provoz vybrán podle zdroje nebo předáván, protože běžné lokální vyhledání může zvolit jinou cestu než předávaný klient. Odpověď uvádí rozhraní, zvolenou zdrojovou adresu a případný další skok, což jsou tytéž informace, se kterými by byl paket v tu chvíli směrován.
Pokud vás odpověď překvapí, vypište pravidla před jakoukoli úpravou: ip -4 rule show je uvádí v pořadí priority a klient VPN, který instaluje vlastní tabulku nebo pravidlo pro označené pakety, se v hlavní tabulce vůbec neobjeví. Vypsání všech tabulek tuto mezeru uzavírá.
ip -4 route show table all | grep -E 'tun|default'Zkontrolujte podkladovou vrstvu, než nahradíte výchozí trasu
Vlastní pakety tunelu se musí dostat ke vzdálenému koncovému bodu, a to přes fyzické rozhraní pomocí trasy, která existovala před spuštěním VPN. Nahrazení celé výchozí trasy bez připnutí tohoto koncového bodu pošle zapouzdřené pakety do tunelu, který mají postavit, a spojení se zhroutí. Nejprve ověřte cestu ke koncovému bodu vyhledáním pouze jeho adresy.
Při změně držte tři věci odděleně: trasu ke koncovému bodu, která musí zůstat na fyzickém rozhraní, privátní rozsahy, které mají vstoupit do tunelu, a výchozí trasu, která rozhoduje o všem ostatním. Rozdělte je v tomto pořadí, aplikujte po jedné a po každém kroku znovu spusťte vyhledání. Neúspěšný ping potom sám o sobě dokazuje jen velmi málo, protože oprávnění, směrování odpovědí, DNS i samotná služba stojí všechny po proudu správné trasy.
Zapište si čtyři hodnoty, které vám řádek dal před úpravou: cíl, další skok nebo jeho nepřítomnost, zařízení a zvolený zdroj. Pokud některou z nich pozdější změna posune, víte, které rozhodnutí se skutečně změnilo, a můžete obnovit jeden záznam místo hádání o celé tabulce.