TAP bez mostu: virtuální segment s routovaným vzestupným spojem

TAP předává Ethernet rámce operačnímu systému, což je více schopností, než většina návrhů vzdáleného přístupu potřebuje, a méně než most. Jádro mu může přidělit adresu, routovat přes něj a chránit ho firewallem, aniž by ho připojilo k jakémukoli fyzickému segmentu. Toto uspořádání stojí za to pochopit nejdřív: izolovaný virtuální Ethernet segment, jehož server vystupuje jako router směrem ke skutečné LAN. Uvnitř tunelu dává chování druhé vrstvy a vně obyčejné IP předávání, což jsou dva různé sliby. Zbytek je stavba, trasa, zpětná cesta a návrat.

Postavte izolovaný segment

V Linuxu rozhraní přijímá tři příkazy: vytvořte ho, zvedněte ho, dejte mu adresu uvnitř segmentu, který zamýšlíte. Vyberte prefix, který nekoliduje s kancelářskou LAN, a zapište si ho, protože kolize je neviditelná, dokud neodpoví hostitel, který by neměl existovat.

ip tuntap add dev tap0 mode tap
ip link set tap0 up
ip addr add 10.77.0.1/24 dev tap0

Nic zde nevyžaduje most a nic nebrání tomu ho později přidat. Dokumentace jádra k TUN/TAP popisuje samotné rozhraní; členství v mostu a politika předávání jsou samostatná rozhodnutí, která děláte potom.

Routujte přes hranici

Zapněte předávání, povolte dva prefixy v řetězci předávání a přidejte trasu ke kancelářskému prefixu s routerem LAN jako dalším skokem. Strana VPN pak posílá provoz mířící do kanceláře na server jako na svou bránu a server tyto pakety předává jako on sám, ne jako most. Rozhraní TAP s vypnutým předáváním je segment, který odpovídá lokálně a nic za sebou nedosáhne, což je obvyklý napůl hotový stav. Potom zkontrolujte čítače rozhraní na obou stranách, protože rostoucí čítač příjmu při plochém čítači odesílání na straně LAN znamená propad v řetězci předávání, ne špatnou trasu.

Napište trasu a pravidlo firewallu jako jednu změnu, protože každé samo o sobě vytváří stav, který ze strany klienta vypadá jako selhání routování.

Rozhodněte zpětnou cestu

Buď se router LAN naučí trasu zpět k prefixu VPN, nebo server překládá zdrojové adresy na cestě ven. Překlad dělá zpětnou cestu triviální a ničí identitu zdroje, takže protokoly cíle budou u každého klienta za ním ukazovat adresu serveru. Routovaný prefix zachovává identitu a vyžaduje změnu na zařízení, které možná nespravujete.

Vyberte záměrně, ne podle toho, co je rychlejší napsat. Jeden routovaný prefix je obvykle čistší než překlad a překlad je obvykle lepší než učit nespravovaný router novému prefixu kvůli jedné laboratoři.

Rozsah vysílání držte záměrný

Uvnitř virtuálního segmentu se DHCP, objevování a oznamování sousedů chovají jako na přepínači, protože je to jedno spojení. Přes routovanou hranici to nedělají, takže kancelářský DHCP a objevování služeb potřebují výslovný návrh, ne předpoklad, že je TAP znamená. Typ rozhraní není přenašečem služeb, které žijí jinde.

To je poctivý důvod, proč vůbec zvolit TAP: něco na virtuálním segmentu potřebuje chování lokální pro spojení. Pokud nic nepotřebuje, zařízení TUN s routovaným prefixem je menší a je méně co vysvětlovat, když se rozbije.

Ověřte a pak napište návrat

Z klienta VPN pingněte router LAN, pingněte hostitele a otevřete jednu službu, na které záleží, přes TCP. Pak zkontrolujte čítače a řetězec předávání, protože propad podle politiky z dálky vypadá přesně jako chybějící trasa. Návrat je opakem stavby a patří do záznamu změn ještě před začátkem: odeberte trasu, odeberte adresu, smažte rozhraní.

Pokud je požadavkem skutečně jeden Ethernet segment přes dva areály, most je poctivá odpověď a jiný návrh s jiným poloměrem dopadu. Pokud je požadavkem dosažitelnost, izolovaný segment s routovaným vzestupným spojem práci zvládne s méně vysvětlováním později.