Ať jeden klient OpenVPN provozuje SSH k druhému bez otevření fondu adres
Nechte client-to-client vypnuté, přenechte jádru předávání jednoho toku a zbytek fondu nechte zavřený. Dvě pravidla na serveru a jedno na cíli.
Jeden klient potřebuje dosáhnout na SSH službu jiného klienta a zbytek fondu má zůstat izolovaný jako dosud. Lákavým přepínačem je client-to-client, který zapne vzájemný přístup pro všechny najednou a rozhodnutí předá OpenVPN místo jádru. Užší odpověď tento přepínač nechá vypnutý a nechá serverový routing a firewall nést přesně jeden tok.
Mechanismus je důležitější než text pravidla, protože oba přístupy umísťují paket na různá místa. Když víte, který jste zvolili, vysvětlí to jak pravidlo, které jako by nic nedělalo, tak protějšek, který se bez něj připojí.
Kam client-to-client posouvá paket
Když je client-to-client zapnuté, server přeposílá paket protějšku interně, místo aby ho poslal zpět ven tunelovým zařízením, takže paket nikdy nedosáhne na forwardovací cestu jádra. To je pohodlné a také to znamená, že váš firewall nikdy neuvidí tok, který má hlídat. Nechte volbu vypnutou a server paket odešle zpět stejným rozhraním, což ho postaví před netfilter. Stejné rozhraní dovnitř, stejné ven, a řetěz FORWARD má slovo.
Výměna je jasná: získáte rozhodovací bod a převezmete routing a forwarding, které za vás dělala zkratka. Ta práce je pro jediný tok malá a roste s každou výjimkou, kterou přidáte. Spočítejte výjimky teď, protože sada pravidel je místo, kde zásady vůči protějškům skutečně žijí.
Cesta, kterou paket protějšku skutečně prochází
Předpokládejte službu Linux Community OpenVPN 2.6, userspace TUN zpracování místo DCO, subnet topologii, tun0 a fond 10.44.0.0/24 s klientem A na 10.44.0.21 a klientem B na 10.44.0.37. U subnet topologie adresa a maska, které A dostal, už fond pokrývají, takže A pošle paket do tunelového zařízení bez potřeby další tlačené routy. Ověřte efektivní routu na A, místo abyste nějakou předpokládali.
Na serveru paket dorazí adresovaný B, což není lokální adresa, takže se předává. Forwarding IPv4 musí být zapnutý, aby k tomu vůbec došlo, a vyhledání routy musí paket poslat zpět přes tun0. Firewall tedy vidí předávaný tok se stejným rozhraním na obou stranách, a to je detail, který většina sad pravidel přehlédne. Překlad zdroje zde není potřeba a zachování adresy A je to, co B umožní uplatnit jeho vlastní pravidlo podle zdroje.
Dvě pravidla na serveru, v tomto pořadí
Celé povolení nesou tři pravidla: forwarding, výjimka pro dvojici a výchozí zahazování pro tunelovou dvojici. Pravidlo přijetí jmenuje dvojici a službu, takže povolení přežije rostoucí fond. Umístěte ho před jakékoli plošné zamítnutí provozu tunel-tunel, protože první shoda vyhrává:
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o tun0 -s 10.44.0.21 -d 10.44.0.37 -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -j DROPTyto příkazy jsou ilustrativní a patří do mechanismu, kterým váš hostitel pravidla uchovává; vložení za běhu zmizí při příštím startu. Stavové pravidlo je to, co nechá odpovědi B a TCP handshake vrátit se bez druhého, zrcadlového přijetí.
Poté zkontrolujte počítadla, ne výpis pravidel, protože pravidlo, které nikdy neodpovídá, vypadá stejně jako to, které funguje. Pokud počítadla zůstanou na nule, paket nejde cestou, kterou si myslíte.
Co musí B ještě povolit
B provozuje SSH službu, takže B rozhoduje o tom, zda na tunelové adrese něco poslouchá a zda jeho vlastní firewall zdroj přijme. Síťové povolení na serveru není povolením pro žádný účet na B a ověření klíče hostitele i autentizace uživatele stále platí jako odjinud.
Nejprve otestujte pozitivní případ: nové SSH spojení z A na tunelovou adresu B, přijaté s očekávaným klíčem hostitele. Poté otestujte jiný protějšek nebo jiný port a ověřte, že je odmítnut, protože povolení, které potichu dovolí všechno, je k nerozeznání od toho, které funguje, dokud na tom nezáleží. Obě poloviny tohoto testu jsou nutné a druhou lidé přeskakují.
Zapište si přidělené adresy, efektivní routy na obou klientech a přesná pravidla na serveru a na B. Úspěšný ping na bránu nebo otevřený port na serveru nic z toho nedokazuje, protože obojí může platit, zatímco předávání mezi protějšky je stále zablokované. Zapište ta čísla, dokud je tunel nahoře, protože adresa, kterou klient dostane po opětovném připojení, může být jiná.