SoftEther SecureNAT: DHCP a NAT jsou dvě rozhodnutí

SecureNAT je jedno zaškrtávací pole, které zapíná dvě služby, a právě v tom je zdroj většiny zmatků kolem něj. Virtuální server DHCP předá klientovi adresu, masku, bránu a často také resolver. Virtuální NAT předává pakety za tuto bránu pomocí vlastního síťového zásobníku hostitelského serveru. V konfiguraci stojí vedle sebe a selhávají nezávisle: klient může mít dokonalý pronájem a žádnou funkční cestu, nebo funkční cestu s nastavením, které ukazuje na špatný resolver. Ověřujte je jako dvě rozhodnutí a diagnostika se zkrátí.

Dvě služby za jedním zaškrtávacím polem

Strana virtuálního DHCP odpovídá na otázku konfigurace: jaké nastavení tento klient dostane uvnitř tohoto virtuálního hubu. Strana virtuálního NAT odpovídá na otázku předávání: když klient pošle paket na adresu mimo hub, přeloží ho server a předá dál. První je lokální pro hub a nepotřebuje žádnou síť výš. Druhé závisí zcela na hostiteli.

Virtuální hostitelské rozhraní patří k prvnímu rozhodnutí, ne ke druhému. Jeho adresa, často něco jako 192.168.30.1 ve výchozím stavu, je brána, kterou služba DHCP nabízí. Není to veřejná naslouchací adresa serveru a záměna obou vede k pravidlům firewallu a nastavením klienta mířícím na stroj, který v dané síti neexistuje.

Rozhodnutí 1: kdo dodává adresu

Je-li virtuální DHCP zapnutý, klienti by měli dostat pronájem z fondu, který jste nastavili, s virtuálním hostitelským rozhraním jako bránou a s resolverem, který jste dodali. Prohlížejte pronájem, ne stavový text klienta, protože „připojeno“ popisuje tunel, nikoli přidělení adresy:

vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route

Dva režimy selhání stojí za to znát, než začnete ladit cokoli dalšího. Klient se zbylou statickou adresou z dřívějšího návrhu si ji ponechá a pronájem ignoruje, což vypadá, jako by DHCP odmítal odpovědět. A druhý zdroj DHCP v přemostěném segmentu bude soutěžit o stejné klienty, což dává občasné adresy a frontu podpory, která problém nedokáže reprodukovat.

Překrývající se fondy patří sem také. Pokud se fond virtuálního DHCP překrývá s LAN podsítí hostitele nebo s fondem jiného hubu, klient dostane adresu, která se směruje nejednoznačně, a každý další test je neprůkazný.

Rozhodnutí 2: kdo předává za virtuální bránu

Při zapnutém virtuálním NAT server překládá odchozí provoz z hubu a posílá ho přes směrovací tabulku hostitele. To znamená, že řetěz předávání je: klient k virtuální bráně, virtuální NAT k zásobníku hostitele, zásobník hostitele k jeho výchozí trase. Každý článek může selhat, aniž by se dotkl ostatních, a projevy selhání se liší.

Druhé rozhodnutí testujte něčím, co musí hub opustit, ne něčím lokálním. Ping na virtuální bránu dokazuje první článek a nic víc:

vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10

Pokud překlad jmen funguje, ale spojení na veřejnou adresu selhávají, jste v řetězu předávání, ne v DHCP. Pokud selhává obojí, zkontrolujte nejprve resolver, protože resolver podstrčený jako nedostupná interní adresa nechá funkční cestu vypadat úplně rozbitou.

Předávání SecureNAT implementuje proces serveru, nikoli jádrová cesta předávání, kterou byste použili s mostem. To je pohodlné a pomalejší než přemostění a také to znamená, že vlastní pravidla firewallu a směrovací rozhodnutí hostitele stále platí pro přeložený provoz. Virtuální NAT neobchází politiku hostitele; používá ji.

Vlastní cesta hostitele je třetí věc

Vše výše předpokládá, že hostitelský server dosáhne na cíl. Hostitel bez funkční trasy výš, s omezující odchozí politikou nebo s rodinou adres, kterou nemá, selže ve druhém rozhodnutí, ať je konfigurace hubu jakkoli správná. Zkontrolujte hostitele samostatně, mimo tunel, než jeho selhání přičtete SoftEtheru.

SecureNAT také není oprávnění dosáhnout na každou síť připojenou k serveru. Překládá a předává provoz, který k němu dorazí; rozhodovat, na co hostitel smí dosáhnout, zůstává prací firewallu a směrování hostitele, a návrh, který spoléhá na tunel při udělování přístupu, je jedno špatné pravidlo od udělení příliš mnoha.

Rodiny adres si zaslouží vlastní kontrolu. Fungující příklad DHCP pro IPv4 nedokládá, že každá schopnost IPv6 je ve vašem sestavení přítomná, takže si přečtěte příručku pro verzi, kterou skutečně provozujete, než slíbíte chování duálního zásobníku. Sekce o SecureNAT v příručce pokrývá funkce virtuálního NAT a DHCP pro aktuální vydání.

Ověřte každé rozhodnutí vlastním testem

První rozhodnutí přijměte kontrolou pronájmu: adresa ve fondu, brána rovna virtuálnímu hostitelskému rozhraní, resolver ten, který jste nastavili. Druhé přijměte odchozím požadavkem z klienta a pohledem na tabulku NAT na serveru, protože rostoucí počet relací je jediný přímý důkaz, že překlad skutečně probíhá, a ne že je jen zapnutý.

Potom rozdělení zapište do návrhové poznámky: která komponenta dodává adresu, která komponenta předává a kterým hostitelským rozhraním provoz vychází. Když restart změní chování, ta poznámka vám řekne, kterou ze tří věcí prozkoumat, místo abyste restartovali všechno a doufali, že se příznak posune.

Do záznamu patří ještě jedno rozhodnutí, i když ho dnes nečiníte: SecureNAT a lokální most jsou různé návrhy pro stejný hub a hub, který potřebuje obojí, je hub, který potřebuje jiný plán. Rozhodněte se vědomě, napište proč, a příští člověk to nebude muset zpětně rekonstruovat z běžící konfigurace.