SoftEther SecureNAT: DHCP a NAT sú dve rozhodnutia

SecureNAT je jedno zaškrtávacie pole, ktoré zapína dve služby, a práve v tom je zdroj väčšiny zmätku okolo neho. Virtuálny server DHCP odovzdá klientovi adresu, masku, bránu a často aj resolver. Virtuálny NAT posiela pakety za túto bránu pomocou vlastného sieťového zásobníka hostiteľského servera. V konfigurácii stoja vedľa seba a zlyhávajú nezávisle: klient môže mať dokonalý prenájom a žiadnu funkčnú cestu, alebo funkčnú cestu s nastaveniami, ktoré ukazujú na nesprávny resolver. Overujte ich ako dve rozhodnutia a diagnostika sa skráti.

Dve služby za jedným zaškrtávacím poľom

Strana virtuálneho DHCP odpovedá na otázku konfigurácie: aké nastavenia dostane tento klient vnútri tohto virtuálneho hubu. Strana virtuálneho NAT odpovedá na otázku odovzdávania: keď klient pošle paket na adresu mimo hubu, preloží ho server a odovzdá ďalej. Prvé je lokálne pre hub a nepotrebuje žiadnu sieť vyššie. Druhé závisí úplne od hostiteľa.

Virtuálne hostiteľské rozhranie patrí k prvému rozhodnutiu, nie k druhému. Jeho adresa, často niečo ako 192.168.30.1 v predvolenom stave, je brána, ktorú služba DHCP ponúka. Nie je to verejná počúvacia adresa servera a zámena oboch vedie k pravidlám firewallu a nastaveniam klienta miereným na stroj, ktorý v tejto sieti neexistuje.

Rozhodnutie 1: kto dodáva adresu

Ak je virtuálny DHCP zapnutý, klienti by mali dostať prenájom z fondu, ktorý ste nastavili, s virtuálnym hostiteľským rozhraním ako bránou a s resolverom, ktorý ste zadali. Prezerajte prenájom, nie stavový text klienta, pretože „pripojené“ opisuje tunel, nie pridelenie adresy:

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

Dva režimy zlyhania stoja za to poznať, než začnete ladiť čokoľvek ďalšie. Klient so zvyškovou statickou adresou z predchádzajúceho návrhu si ju ponechá a prenájom ignoruje, čo vyzerá, akoby DHCP odmietal odpovedať. A druhý zdroj DHCP v premosťovanom segmente bude súťažiť o tých istých klientov, čo dáva občasné adresy a front podpory, ktorý problém nedokáže reprodukovať.

Prekrývajúce sa fondy patria sem tiež. Ak sa fond virtuálneho DHCP prekrýva s LAN podsietou hostiteľa alebo s fondom iného hubu, klient dostane adresu, ktorá sa smeruje nejednoznačne, a každý ďalší test je nepreukazný.

Rozhodnutie 2: kto odovzdáva za virtuálnu bránu

Pri zapnutom virtuálnom NAT prekladá server odchádzajúcu prevádzku z hubu a posiela ju cez smerovaciu tabuľku hostiteľa. To znamená, že reťaz odovzdávania je: klient k virtuálnej bráne, virtuálny NAT k zásobníku hostiteľa, zásobník hostiteľa k jeho predvolenej trase. Každý článok môže zlyhať bez toho, aby sa dotkol ostatných, a prejavy zlyhania sa líšia.

Druhé rozhodnutie testujte niečím, čo musí hub opustiť, nie niečím lokálnym. Ping na virtuálnu bránu dokazuje prvý článok a nič viac:

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

Ak preklad mien funguje, ale spojenia na verejnú adresu zlyhávajú, ste v reťazi odovzdávania, nie v DHCP. Ak zlyháva oboje, skontrolujte najprv resolver, pretože resolver podstrčený ako nedostupná interná adresa nechá funkčnú cestu vyzerať úplne pokazenú.

Odovzdávanie SecureNAT implementuje proces servera, nie jadrová cesta odovzdávania, ktorú by ste použili s mostom. Je to pohodlné a pomalšie ako premosťovanie a tiež to znamená, že vlastné pravidlá firewallu a smerovacie rozhodnutia hostiteľa stále platia pre preloženú prevádzku. Virtuálny NAT neobchádza politiku hostiteľa; používa ju.

Vlastná cesta hostiteľa je tretia vec

Všetko vyššie predpokladá, že hostiteľský server dosiahne cieľ. Hostiteľ bez funkčnej trasy vyššie, s obmedzujúcou odchádzajúcou politikou alebo s rodinou adries, ktorú nemá, zlyhá v druhom rozhodnutí, nech je konfigurácia hubu akokoľvek správna. Skontrolujte hostiteľa samostatne, mimo tunela, než jeho zlyhanie pripíšete SoftEtheru.

SecureNAT tiež nie je oprávnenie dosiahnuť každú sieť pripojenú k serveru. Prekladá a odovzdáva prevádzku, ktorá k nemu dorazí; rozhodovať, na čo hostiteľ smie dosiahnuť, zostáva prácou firewallu a smerovania hostiteľa, a návrh, ktorý sa pri udeľovaní prístupu spolieha na tunel, je jedno zlé pravidlo od udelenia príliš mnohých.

Rodiny adries si zaslúžia vlastnú kontrolu. Fungujúci príklad DHCP pre IPv4 nedokazuje, že každá schopnosť IPv6 je vo vašom zostavení prítomná, preto si prečítajte príručku pre verziu, ktorú skutočne prevádzkujete, než sľúbite správanie duálneho zásobníka. Sekcia o SecureNAT v príručke pokrýva funkcie virtuálneho NAT a DHCP pre aktuálne vydanie.

Overte každé rozhodnutie jeho vlastným testom

Prvé rozhodnutie prijmite kontrolou prenájmu: adresa vo fonde, brána rovná virtuálnemu hostiteľskému rozhraniu, resolver ten, ktorý ste nastavili. Druhé prijmite odchádzajúcou požiadavkou z klienta a pohľadom na tabuľku NAT na serveri, pretože rastúci počet relácií je jediný priamy dôkaz, že preklad naozaj prebieha, a nie že je len zapnutý.

Potom rozdelenie zapíšte do návrhovej poznámky: ktorá komponenta dodáva adresu, ktorá komponenta odovzdáva a ktorým hostiteľským rozhraním prevádzka vychádza. Keď reštart zmení správanie, tá poznámka vám povie, ktorú z troch vecí preskúmať, namiesto reštartovania všetkého a nádeje, že sa príznak posunie.

Do záznamu patrí ešte jedno rozhodnutie, aj keď ho dnes nerobíte: SecureNAT a lokálny most sú rôzne návrhy pre ten istý hub a hub, ktorý potrebuje oboje, je hub, ktorý potrebuje iný plán. Rozhodnite sa vedome, napíšte prečo, a budúci človek to nebude musieť spätne rekonštruovať z bežiacej konfigurácie.