Dva VPN skoky na jednom Pi: která trasa nese který protějšek

Dvě adresy tunelu na jedné malé desce vypadají jako chyba a reflex je jednu smazat. Ten reflex rozbíjí to, co měl uklidit. Hostitel se dvěma skoky drží jednu adresu na každé připojení a každou adresu vybírá jiná trasa. Otázka, kterou stojí za to si položit, je, která trasa vybírá který nositel pro které cílové místo, ne kolik adres existuje.

Tři cílová místa, která potřebují různé nositele

Řetěz dvou skoků jsou tři třídy cílových míst poskládané na sobě a každou nese jiné připojení. Vnější protějšek musí být dosažen přes fyzické spojení. Vnitřní protějšek musí být dosažen přes vnější tunel. Cílové místo pokryté aplikace musí být dosaženo přes vnitřní tunel, jehož vlastní transport nese ten vnější.

Vyplňte řádky skutečnými adresami čtenáře, než se dotknete trasy, protože tabulka je užitečná jen tehdy, když je konkrétní. Fungující řetěz splňuje všechny čtyři řádky současně a polofunkční obvykle splňuje jeden z nich se špatným nositelem. Právě čtení špatného řádku jako závady mění problém směrování v celé odpoledne úprav.

Adresy mají role, ne počet

Linux dovoluje několik adres na jednom rozhraní a několik tunelů na jednom hostiteli, takže počet nic neříká o správnosti. Záleží na tom, která adresa patří kterému připojení a zda trasa pro daný protějšek vybírá připojení, které jste mysleli. Tři pohledy na to odpovídají ze tří směrů a stojí za to je číst pokaždé ve stejném pořadí.

Inventář adres ukazuje, co existuje a které připojení to vlastní. Tabulka tras odpovídá na otázku nositele pro běžný provoz k cílovým místům. Pohled pravidel na ni odpovídá znovu pro provoz vybraný zdrojem nebo značkou, což je obvyklé uspořádání, když dva klienti sdílejí jednoho hostitele.

ip -4 addr show
ip -4 route show table all
ip rule show

Smazání adresy proto, že seznam vypadá dlouhý, může odstranit část cesty, a smazání trasy proto, že vypadá nadbytečná, dělá totéž tišeji. Ani jedno nehlásí chybu; protějšek prostě přestane odpovídat na cestě, kterou jste zamýšleli, zatímco zůstává dosažitelný jinudy. Aplikace, která hlásí výstupní adresu vnitřního protějšku, nedokazuje, že provoz prošel vnějším tunelem, protože přímý přístup dává stejné pozorování. Právě tato mezera mezi pozorováním a důkazem je důvod, proč se nositel kontroluje na vrstvě směrování.

Pořadí aktivace poráží pevné čekání

Pokud vnitřní klient závisí na adrese nebo trase, kterou dodává vnější klient, musí aktivace počkat na tento zdroj, ne na zpoždění. Čekání funguje do dne, kdy je vnější tunel pomalý, a pak občas selže způsobem, který nikdo nedokáže zopakovat. Řazení podle závislostí odstraňuje hádání a nestojí nic než jednou popsat závislost. Ani názvy rozhraní nejsou mechanismem řazení.

Jádro přiděluje názvy jako tun0 a tun1 v pořadí vytvoření a toto pořadí se může mezi restarty nebo opětovnými připojeními změnit. Svažte konfiguraci s identitou, kterou poskytuje nástroj, nebo s názvem, který vědomě přiřadíte. Název, který zvolíte, je smlouva; název, který zvolí jádro, je náhoda.

Držte transport každého klienta mimo aplikační trasu toho druhého a buďte přesní v tom, co možnosti směrování OpenVPN 2.6 skutečně slibují. Dokumentovaný mechanismus výchozího přesměrování udržuje klienta schopného dosáhnout svého vzdáleného protějšku přes bránu, která už existovala, což přerušuje jednu konkrétní rekurzivní smyčku. Neproměňuje jednoho klienta v nositele druhého, takže zbytek řetězu zůstává váš návrh. Kde řetěz potřebuje pravidlo, ne trasu, napište výslovné pravidlo zdroje nebo značky a otestujte je provozem, kterému má odpovídat.

Co se stane, když vnější skok zemře

Než se řetěz počítá za dokončený, rozhodněte, co se stane, když vnější skok zmizí. Transport vnitřního klienta s ním umírá a další krok je otázka pravidel, ne techniky: selhat, zkusit znovu, nebo se připojit přímo přes fyzické spojení. Právě třetí výsledek stojí za přemýšlení. Tiše mění návrh se dvěma skoky na návrh s jedním skokem v okamžiku, kdy uživatel věří, že pokrytí je stále nedotčené.

Pokud jsou dva skoky povinné, vnitřní klient nesmí být schopen vytvořit přímou cestu, když vnější zmizí, a způsob, jak to zjistit, je přerušit vnější skok a sledovat, co dělá vnitřní. Schválená záloha je legitimní odpověď, ale musí být napsaná, otestovaná a sdělená. Záloha, kterou nikdo nedokumentoval, je při revizi incidentu nerozeznatelná od úniku.

DNS a druhá rodina adres patří ke stejnému rozhodnutí. Lokálně generovaný dotaz se řídí vlastními pravidly hostitele, ne pravidly předávaného klienta, takže resolver, který funguje pro předávaný provoz, nemusí být ten, který hostitel sám používá.

Přijměte každou vrstvu v pořadí, v jakém jste ji stavěli

Testujte v pořadí, v jakém byl řetěz postaven: nejprve samotný vnější tunel, pak transport vnitřního klienta přes vnější tunel, pak aplikaci přes vnitřní tunel. Každé přijetí musí být nové spojení, ne stránka, která už byla otevřená. Potom každou vrstvu zvlášť přerušte a obnovte a sledujte, co dělá ta následující.

Výsledek zálohy je zde nejcennější pozorování a to, které stránka s veřejnou IP nikdy neukáže. Uložte cesty protějšků, adresy, které používají, a tento výsledek vedle konfigurace, protože šťastná cesta není ta část, na kterou se později ptáme.