Rozdělené trasy L2TP na Macu: proč adresa hostitele nefunguje
setadditionalroutes chce dvojice sítě a masky, nahrazuje celý seznam a potřebuje doslovný název služby. Než obviníte bránu, zkontrolujte tabulku.
VPN se připojí, panel nabídek to ukazuje, a interní hostitel přesto neodpovídá. V takové situaci existují tři možné příčiny a která platí, závisí na tom, jak byl tunel nakonfigurován. Buď příkaz trasy použil adresu hostitele tam, kde byla potřeba adresa sítě, nebo samotný profil instaluje výchozí trasu, která rozhodnutí pohltí, nebo je klient tunel PPP, který potřebuje hook, a ne klíč profilu. Zkontrolujte je v tomto pořadí, protože první se nejlevněji vylučuje.
Cíl je adresa sítě, maska popisuje prefix
networksetup -setadditionalroutes přijímá trojice cíle, masky podsítě a brány. Volání, které posílá jednu interní podsíť tunelem, vypadá takto:
sudo networksetup -setadditionalroutes "VPN (L2TP)" 192.168.1.0 255.255.255.0 10.2.0.0
Všimněte si, co je cíl: adresa sítě, ne adresa serveru, ke kterému se snažíte dostat. V případě, který dal vzniknout tomuto článku, stejný příkaz s 192.168.1.20 na onom místě neudělal nic užitečného a nahrazení 192.168.1.0 fungovalo okamžitě. Stejná maska, stejná brána, jedno jiné číslo. To je celá porucha v malém.
Důvod je aritmetika, ne politika. Adresa hostitele spárovaná s maskou /24 nepopisuje 192.168.1.0/24; popisuje něco, co směrovací tabulka nedokáže užitečně udržet, takže se záznam odmítne nebo ignoruje a tunel nakonec přenáší méně, než jste zamýšleli.
Když chcete přesně jednoho hostitele, použijte adresu hostitele s maskou 255.255.255.255. Chyba je ve smíšených dvojicích, ne v použití adresy hostitele jako takové. /32 postavená z jedné adresy je legitimní trasa; /24 postavená z jedné adresy je chyba.
Volání nahrazuje seznam a název je doslovný
Dva projevy lidi na první pokus překvapí. Příkaz nastavuje úplný seznam dalších tras, místo aby přidával, takže volání, které přidá jeden prefix, tiše odstraní ostatní, které tam byly předtím. Sestavte celou množinu jediným voláním.
Název služby také není označení, které jste vymysleli. Přečtěte ho z nástroje a zkopírujte přesně, včetně přípony typu:
networksetup -listallnetworkservices
Název, který se liší jediným znakem, nevyprodukuje chybu, kterou by stálo za to číst, ani trasu. Kopírování a vkládání je zde správná technika, ne přepisování z paměti.
Když si profil nárokuje výchozí trasu
Rozdělené trasy prohrávají s výchozí trasou pro každý cíl, který výslovně nepokrývají, a profil L2TP nakonfigurovaný pro plný tunel instaluje právě to. Pokud profil říká, že vše jde tunelem, seznam dalších tras se mění jen velmi málo. Váš záznam není špatný; je prostě irelevantní pro cíle, které nikdy nejmenuje. Ovládání toho obvykle sedí v nastavení profilu pro odesílání veškerého provozu, ne v žádném příkazu trasy.
Rozhodněte se, který model skutečně chcete, než budete upravovat další záznamy. Plný tunel s výjimkami je jiná konfigurace než rozdělený tunel s konkrétními prefixy a míchání obojího dává tabulku, kterou nikdo nedokáže předpovědět.
Pokud organizace vyžaduje plný tunel, přestaňte ho zkoušet dělit lokálně a vezměte požadavek k tomu, kdo vlastní politiku. Lokálně přidaná trasa, která mu odporuje, bude stejně odstraněna příští aktualizací profilu.
Tunely PPP potřebují hook místo klíče
U tunelů založených na PPP je defaultroute klíč profilu, který vytváří výchozí trasu; zrušte ho a klient přestane nárokovat každý cíl. Trasy se pak přidávají poté, co se objeví rozhraní, obvykle z /etc/ppp/ip-up:
#!/bin/sh
/sbin/route add -net 192.168.1.0 -interface ppp0
Nechte skript vlastněný rootem a spustitelný a přidejte pojistku na název rozhraní, když je na stroji více než jeden profil tunelu. Hook, který běží pro každé spojení PPP a předpokládá jedno jméno zařízení, je malá chyba s dlouhým životem.
Ověřte rozdělení třemi požadavky
Zachyťte tabulku, dokud jste připojeni, a poznamenejte, které rozhraní tunel obsluhuje. Potom zkontrolujte konkrétní cíl, místo abyste věřili návratovému stavu příkazu, který ho vytvořil. Návratový kód hlásí, zda nástroj přijal argumenty, ne zda provoz jde cestou, kterou jste zamýšleli.
Skončete třemi požadavky, které rozdělení dokazují: jeden interní hostitel podle adresy, jedno interní jméno přes interní resolver a jeden veřejný web, který má stále používat místní připojení. Pokud veřejný web nyní také putuje tunelem, rozdělení nikdy nenastalo, ať se seznam tras zdá říkat cokoli.
Připojte se ještě jednou a zopakujte interní požadavek, protože trasy přidané ručně mohou přežít rozhraní, které je učinilo platnými a po pádu tunelu tiše promění provoz v černou díru.