Další skok ve směrování VPN: proč musí být brána dostupná lokálně

Trasa do sítě VPN nese dvě adresy, které se snadno pletou: prefix cíle, kterého se paket snaží dosáhnout, a další skok, který ho posune o krok blíž. Na hostiteli v LAN musí být tím dalším skokem router, na který na stejné lince skutečně dosáhnete. Vzdálená adresa VPN není dalším skokem, ať už se jakkoli přesně shoduje s cílem, který máte na mysli.

Tato příručka pokrývá obvyklý případ: notebook na 192.168.20.0/24, bránu VPN s adresou LAN 192.168.20.5 a vzdálenou síť 10.70.0.0/24 za touto branou. Všechny níže uvedené příkazy předpokládají, že jste na notebooku, pokud není uvedeno jinak.

Dvě adresy, jedna trasa

Zamýšlený záznam je 10.70.0.0/24 via 192.168.20.5. Prefix říká, kam paket jde; adresa via říká, kdo ho tam nese. Jádro odmítne nainstalovat trasu, jejíž bránu nedokáže dosáhnout přes rozhraní, které uvedete, a toto odmítnutí je celý smysl: další skok, který k dostupnosti potřebuje tunel, nemůže být dalším skokem, který tunel staví.

První kontrola tedy není «běží brána», ale «je brána na této lince». Vlastní podsíť notebooku, jeho záznam ARP nebo souseda a rozhraní v trase se musí shodovat. Adresa, která existuje jen uvnitř 10.70.0.0/24, může být cílem druhé trasy, nikdy však via té první.

K čemu další skok zavazuje bránu

Instalace trasy na notebooku rozhoduje jen o prvním předání. Brána pak potřebuje vlastní cestu: zapnuté předávání, tunelovou trasu pro 10.70.0.0/24 a jakoukoli přístupovou politiku, která určuje, kdo ji smí používat. Na Linuxu je to net.ipv4.ip_forward=1 plus tunelová trasa; firewall před ní potřebuje pravidlo, které povolí předávaný tok.

Zpětný směr je část, na kterou lidé zapomínají. Vzdálená strana musí mít trasu zpět do 192.168.20.0/24, nebo musí návrh přeložit zdroj notebooku na něco, co vzdálená strana zná. Fungující ping z brány dokazuje, že brána dosáhne na vzdálenou síť; nic neříká o tom, zda pakety notebooku přežijí cestu zpět.

Ověřte vyhledání z hostitele, který odesílá

Zeptejte se jádra, který další skok by zvolilo, a přečtěte rozhraní v odpovědi:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

Pokud vyhledání hlásí bránu a rozhraní LAN, první úsek je nakonfigurován podle záměru. Pokud hlásí tunelové zařízení, něco dřívějšího v tabulce je konkrétnější a vyhrává. Pokud se trasa vůbec nenainstaluje, jádro vám říká, že brána není dostupná, a ta zpráva je užitečnější než jakýkoli odchyt paketů.

Potom test zopakujte ze správného místa. Požadavek vytvořený na bráně používá vlastní zdrojovou adresu brány, což může skrýt chybějící zpětnou trasu nebo politiku, která povoluje jen určité zdroje. Manuál ip-route odděluje cíl, bránu a přepis onlink, a přepis stojí za pochopení dřív, než ho použijete.

Nepoužívejte onlink k předstírání dostupnosti

onlink říká jádru, aby přeskočilo kontrolu dostupnosti brány a přesto tam poslalo. Nevytváří cestu, nepřekládá ARP pro adresu, která tam není, a nepřiměje vzdálený router odpovídat na vašem segmentu Ethernet. Je legitimní pro brány, které odpovídají, ale nesedí v připojené podsíti, a je pastí, když se použije k utišení chyby, kterou jste nevysvětlili.

Pokud se trasa nainstaluje jen s onlink, další otázkou je, proč brána není tam, kde si myslíte. Špatná VLAN, druhá adresa na špatném rozhraní nebo překlep v posledním oktetu to všechno způsobí a každá z nich také rozbije zpětnou cestu, jakmile provoz začne téct.

Tunely bod-bod nejsou Ethernet

Tunelové zařízení nedělá ARP a často nemá smysluplnou podsíť sousedů. Jeho trasy často vypadají jako 10.70.0.0/24 dev tun0, bez jakéhokoli via, protože protějšek je jediný druhý koncový bod. Kopírování via ve stylu LAN do této tabulky vytvoří trasu, kterou jádro může odmítnout nebo, hůř, takovou, která ukazuje na adresu, na niž protějšek nikdy neodpoví.

Držte oba modely v příručce oddělené: trasa LAN má dostupnou bránu, tunelová trasa má rozhraní a protějšek. WireGuard, OpenVPN a IPsec ukazují mírně odlišné tvary, proto si zapište tvar, který jste skutečně použili, místo abyste zobecňovali z jednoho hostitele.

Přidejte, potvrďte, vraťte zpět

Celá změna jsou tři příkazy a jedna kontrola a měla by být zapsána v tomto pořadí:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

Potvrďte cestu, potvrďte jeden cíl, a pak mějte po ruce řádek pro smazání pro případ, že změna učiní hostitele nedostupným způsobem, který jste nepředvídali. Pokud má trasa přežít restart, uložte ji do síťové konfigurace hostitele, ne do profilu shellu, a restart otestujte, než se na ni spolehnete. Trasa, která existuje jen v shellu, který ji přidal, je trasa, kterou budete ladit dvakrát.