OpenVPN s plným tunelem: přidejte internetový výstup na straně serveru
Zatlačení výchozí trasy je jen polovina služby plného tunelu. Server také potřebuje předávání, omezené pravidlo předávání a cestu zpět pro pool.
Klient se ověří, obdrží adresu z poolu a dosáhne služeb na hostiteli VPN, ale každá veřejná destinace skončí vypršením času. Tak vypadá tunel bez výstupu a tak to zůstane, dokud nebudou splněny čtyři oddělené podmínky. Klient musí přijmout výchozí trasu, server musí předávat, firewall musí povolit tranzit a odpovědi potřebují cestu zpět do poolu. Všechny čtyři poruchy sdílejí jeden symptom, proto měňte jednu položku na pokus a výsledek si poznamenejte.
Zatlačte výchozí trasu a ověřte, co klient nainstaloval
Řádek na straně serveru je krátký a ovlivňuje jen klienty, kteří přijímají zatlačené volby. Forma def1 instaluje dvě polo-výchozí trasy místo smazání stávající výchozí, což udrží současné spojení živé a zároveň zachytí každou destinaci.
push "redirect-gateway def1"
Po opětovném připojení si přečtěte směrovací tabulku klienta, místo abyste věřili profilu. V Linuxu se dva záznamy /1 objeví vedle původní výchozí trasy a Windows zobrazuje stejný pár jako 0.0.0.0/1 a 128.0.0.0/1. Klient, který zatlačené volby ignoruje, nebo ten, který je nastaven je odmítat, si ponechá starou výchozí trasu a nikdy nepošle internetový provoz do tunelu. Vyřešte tuto otázku, než na serveru cokoli změníte, protože žádné pravidlo na straně serveru to nenahradí.
Předávání je nastavení serveru, ne nastavení VPN
Přečtěte si příznak předávání, než se dotknete směrování. Nula tam znamená, že jádro přijme klientův paket a odmítne jej předat dál, což vypadá přesně jako blokování firewallem z opačné strany. Hodnotu nastavte přes konfigurační adresář systému, aby přežila restart.
sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system
Dále ověřte, že samotný hostitel má funkční trasu k internetovému výstupu. Požadavek z shellu serveru dokazuje, že upstream cesta je použitelná, a neříká vůbec nic o předávání klientova paketu, takže to berte jako dva samostatné testy. Pokud se server k destinaci nedostane, nepomůže žádné množství konfigurace předávání.
Povolte právě ten tranzit, který zamýšlíte, a nic jiného
Předávané pakety procházejí cestou forward; provoz adresovaný samotnému hostiteli VPN prochází cestou input. To jsou různá rozhodnutí a otevření cesty input neumožňuje tranzit strojem. Jejich záměna je nejčastějším důvodem, proč firewall vypadá, že povoluje všechno, a klienti přesto dostávají timeout.
Minimální politika přijímá nová spojení z poolu k výstupnímu rozhraní a přijímá odpovědi patřící navázaným tokům. Umístěte ji k tomu vlastníkovi sady pravidel, který vaše distribuce používá, místo abyste při každém startu přidávali duplicitní pravidlo; duplicity se hromadí a počítadla přestanou něco znamenat.
sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
Přepnutí každého řetězce na přijímání nechá test projít a odstraní důvod, proč firewall existuje. Držte rozsah na poolu a výstupním rozhraní a nesouvisející předávání nechte být.
Dejte odpovědím kam jít
Adresy poolu jsou soukromé, takže veřejný server na ně nemůže doručit odpověď přímo. Buď hostitel VPN překládá zdrojovou adresu na cestě ven, nebo zařízení výše drží trasu zpět do poolu.
sudo iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o eth0 -j MASQUERADE
Přidejte právě jednu překladovou vrstvu. Druhý NAT výše skryje první a oba záznamy udělá téměř nepoužitelnými, když se později něco rozbije. Pokud router výše už směruje pool zpět, přidání překladu na hostiteli je nadbytečné a cesta zpět pak závisí na konfiguraci toho routeru, ne na vaší.
Cloudové instance přidávají ještě jednu bránu, protože některé platformy zahazují pakety, jejichž zdrojová adresa není adresou instance, pokud se tato kontrola neuvolní. Toto nastavení sedí mimo hosta a snadno se zapomene, když lokální testovací stroj funguje.
Dokažte to z klienta, ne ze shellu serveru
Začněte číselným požadavkem IPv4, pak vyhledáním jména, pak aplikací. ping dokazuje předávání a překlad;o překladu jmen nedokazuje nic, protože volby DNS začnou platit až tehdy, když je nainstaluje klientská integrace.
curl -4 -m 5 http://198.51.100.10/
dig +short example.com
Průběžně zaznamenávejte změny i krok vrácení, aby šla výstupní politika vrátit jedinou akcí, když test selže. Tento recept pokrývá jen IPv4; inventarizujte IPv6 zvlášť, než budete tvrdit, že nasazení nese veškerý provoz.