Spouštění portů versus přesměrování portů pro domácí VPN server
Spouštění otevře mapování až po odchozím provozu; přesměrování mapuje port trvale. Domácí VPN server potřebuje to druhé, omezené na skutečný naslouchač.
Přesměrování portů a spouštění portů jsou ve stejné nabídce na většině domácích routerů, a proto se berou jako dva způsoby, jak udělat jednu práci. Přesměrování je statické pravidlo: příchozí spojení na port WAN se přeloží na pevnou vnitřní adresu a port, ať se děje cokoli jiného. Spouštění je podmíněné: router sleduje odchozí provoz a otevře příchozí mapování teprve poté, co odejde odpovídající spojení. VPN server čeká, až se nejdřív připojí někdo jiný, takže právě tuhle podmínku nemůže nikdy splnit.
Dvě pravidla s různými životními cykly
IPv4 NAT si drží stav. Když vnitřní host odešle paket ven, router vytvoří mapování, aby odpovědi našly cestu zpět; příchozí paket, který neodpovídá žádnému mapování, se zahodí, a to je chování, které drží neaktualizovaný počítač mimo internet. Přesměrování je trvalý záznam překladu přidaný ručně. Spouštění je dočasná díra střežená vzorem provozu.
Praktický rozdíl je čas. Přesměrování existuje od okamžiku uložení, dokud ho někdo nesmaže. Spuštěné mapování existuje po aktivaci spouštěče a zavírá se na časovači nečinnosti, měřeném v minutách na spotřebitelském hardwaru, nebo okamžitě při restartu.
Ani jedno není abstraktně bezpečnější. Přesměrování vystavuje jeden port nepřetržitě; spouštěč ho vystaví až po určitém odchozím provozu. Pro službu, která musí přijmout první paket od cizího člověka, odpovídá úloze jen jedno z těch dvou.
Proč spouštění server nezveřejní
VPN server je pasivní už z návrhu. Protějšek, ať už je to notebook v kavárně nebo telefon na mobilních datech, posílá první paket a router pro něj nemá mapování. Nic uvnitř nezačalo provoz na port spouštěče, takže pravidlo nikdy nezasáhne a spojení umře dřív, než začne handshake.
Tam, kde se spouštění zdá fungovat, generuje provoz na portu spouštěče něco jiného: klient v LAN, monitorovací sonda nebo vlastní odchozí kontroly serveru. Mapování se pak otevře pro jeden host a zavře, když provoz ustane, takže další vnější protějšek zase selže, zatímco první úspěch leží v logu a vypadá jako důkaz.
Spouštění je navíc obvykle jednohostové. Mnoho implementací dovolí, aby mapování drželo vždy jen jedno vnitřní zařízení, což je přesně špatně pro server, který má odpovídat několika protějškům. Funkce vznikla pro aplikace, které otevírají řídicí spojení ven a očekávají příchozí data na druhém portu, a pořád tomu tvaru odpovídá.
Co přesměrování skutečně mapuje
Přesměrování je jeden záznam překladu: port WAN a protokol na vnitřní adresu a port. Potřebuje naslouchač, který už běží na druhé straně, a potřebuje, aby vnitřní adresa zůstala na místě. DHCP lease, který se přesune na jiný stroj, tiše pošle každý tunel na špatný host, takže rezervaci vytvořte před pravidlem.
| Rule | Opens when | Closes when | Fits a VPN listener |
|---|---|---|---|
| Port forward | Saved, at boot | You delete it | Yes |
| Port trigger | Matching outbound traffic | Idle timeout or reboot | No |
Protokol je důležitější, než formulář naznačuje. OpenVPN přes UDP potřebuje UDP přesměrování, WireGuard potřebuje UDP a data IPsec přicházejí jako ESP, IP protokol 50, který nemá vůbec žádné porty. Formulář přesměrování, který přijímá jen TCP nebo UDP, to vyjádřit nemůže, takže IPsec potřebuje passthrough nebo statické mapování jedna ku jedné místo portového pravidla.
Vrstva nad vaším routerem
Přesměrování ovládá jen překlad, který vlastníte. Pokud adresa WAN není vaše, což je případ za NAT operátora, kde účastníci sdílejí 100.64.0.0/10, jak je popsáno v RFC 6598, příchozí spojení se k vašemu routeru nikdy nedostane, protože poskytovatel přeložil první. Žádné pravidlo na vašem zařízení tenhle pořadí nespraví.
Dvojitý NAT je stejný problém v malém. Váš router přesměruje na router ISP, který nemá odpovídající pravidlo a paket zahodí. Buď pravidlo přidejte na vnějším zařízení, nebo vnější zařízení přepněte do režimu mostu a nechte své zařízení držet veřejnou adresu.
Proto musí test přijít zvenčí. Test ze stejné LAN přes veřejnou adresu závisí na podpoře hairpin NAT a může projít nebo selhat z důvodů nesouvisejících s pravidlem; telefon na mobilních datech nebo přítel na jiné síti je čistší kontrola.
Ohraničte pravidlo, pak ověřte obě poloviny
Přesměrujte jeden port na jednu adresu. Rozsah přidaný proto, že první pokusy selhaly, je cesta, kterou se správcovská rozhraní dostanou na internet, a naslouchač VPN nepotřebuje publikovanou administrátorskou stránku routeru vedle sebe.
Zachovejte vše, co toho naslouchače už chránilo: identitu podle certifikátu nebo klíče, hostitelský firewall, aktuální verze balíčků. Přesměrování pustí paket dovnitř; autentizace rozhoduje, zda se paket stane tunelem, a to jsou dvě oddělené poruchy, když se něco pokazí.
Ověření má dvě poloviny. Handshake musí proběhnout z vnější sítě a pak musí soukromý prostředek za serverem odpovědět tunelem. Přesměrování pustí spojení tunelu a nic víc; směrování a autorizace pro 10.8.0.0/24 je jiné nastavení na jiné obrazovce.
Rozhodněte třemi otázkami
Tři otázky rozhodnou volbu rychleji než jakákoli srovnávací tabulka:
- Připojuje se něco zvenčí jako první paket? Pak použijte přesměrování nebo relay. Spouštění se nemůže otevřít bez odchozího provozu, který nikdy nevznikne.
- Musí díra přežít dobu nečinnosti? Pak použijte přesměrování, protože spuštěné mapování se zavírá podle vlastního plánu.
- Je adresa WAN vaše, abyste ji mohli zveřejnit? Pokud není, opravte vrstvu nad tím, než začnete editovat jakékoli pravidlo.
Pokud je odpověď na všechny tři otázky ne, což je případ notebooku, který si sám volá komerčnímu poskytovateli, není potřeba ani jedno pravidlo. Klient za NAT funguje, protože si stavové mapování vytváří sám, a to pokrývá většinu lidí, kteří o půlnoci čtou stránku o přesměrování portů.