SoftEther SecureNAT: DHCP și NAT sunt două decizii

SecureNAT este o singură casetă de bifare care pornește două servicii, și de aici vine cea mai mare parte a confuziei legate de el. Un server DHCP virtual îi oferă clientului o adresă, o mască, o poartă de ieșire și adesea un resolver. Un NAT virtual trimite pachetele dincolo de acea poartă folosind stiva de rețea proprie a gazdei serverului. Cele două stau una lângă alta în configurație și eșuează independent: un client poate avea o concesiune perfectă și nicio cale funcțională, sau o cale funcțională cu setări care indică resolverul greșit. Verificați-le ca două decizii, iar diagnosticul devine scurt.

Două servicii în spatele unei casete de bifare

Partea DHCP virtuală răspunde la o întrebare de configurare: ce setări primește acest client în interiorul acestui concentrator virtual. Partea NAT virtuală răspunde la o întrebare de trimitere mai departe: când un client trimite un pachet către o adresă din afara concentratorului, serverul îl traduce și îl trimite mai departe. Prima este locală concentratorului și nu are nevoie de nicio rețea în amonte. A doua depinde în întregime de gazdă.

Interfața virtuală a gazdei aparține primei decizii, nu celei de-a doua. Adresa ei, adesea ceva de genul 192.168.30.1 în mod implicit, este poarta pe care o oferă serviciul DHCP. Nu este adresa publică de ascultare a serverului, iar confundarea celor două produce reguli de firewall și setări de client îndreptate către o mașină care nu există în acea rețea.

Decizia 1: cine furnizează adresa

Dacă DHCP virtual este activat, clienții ar trebui să primească o concesiune în pool-ul configurat, cu interfața virtuală a gazdei ca poartă și cu resolverul pe care l-ați furnizat. Inspectați concesiunea și nu textul de stare al clientului, pentru că „conectat” descrie tunelul, nu alocarea adresei:

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

Două moduri de eșec merită cunoscute înainte de a depana orice altceva. Un client cu o adresă statică rămasă dintr-un proiect anterior o va păstra și va ignora concesiunea, ceea ce arată ca și cum DHCP ar refuza să răspundă. Iar o a doua sursă DHCP pe un segment punte va concura pentru aceiași clienți, ceea ce produce adrese intermitente și o coadă de suport care nu poate reproduce problema.

Pool-urile suprapuse își au și ele locul aici. Dacă pool-ul DHCP virtual se suprapune cu subrețeaua LAN a gazdei sau cu pool-ul altui concentrator, clientul primește o adresă care este rutată ambiguu, iar fiecare test ulterior este neconcludent.

Decizia 2: cine trimite mai departe dincolo de poarta virtuală

Cu NAT virtual activat, traficul de ieșire din concentrator este tradus de server și trimis prin tabela de rutare a gazdei. Asta înseamnă că lanțul de trimitere este: client către poarta virtuală, NAT virtual către stiva gazdei, stiva gazdei către ruta sa implicită. Fiecare verigă poate eșua fără să le atingă pe celelalte, iar semnăturile eșecului diferă.

Testați a doua decizie cu ceva care trebuie să părăsească concentratorul, nu cu ceva local acestuia. Ping către poarta virtuală dovedește doar prima verigă și nimic mai mult:

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

Dacă rezolvarea numelor funcționează dar conexiunile către o adresă publică eșuează, sunteți în lanțul de trimitere, nu în DHCP. Dacă ambele eșuează, verificați mai întâi resolverul, pentru că un resolver împins ca adresă internă inaccesibilă va face o cale funcțională să pară complet ruptă.

Trimiterea SecureNAT este implementată de procesul serverului, nu de calea de trimitere din nucleu pe care ați folosi-o cu o punte. Este comod și mai lent decât puntea, și înseamnă de asemenea că regulile de firewall și deciziile de rutare ale gazdei se aplică în continuare traficului tradus. NAT virtual nu ocolește politica gazdei; o folosește.

Calea proprie a gazdei este un al treilea lucru

Tot ce precede presupune că gazda serverului poate ajunge la destinație. O gazdă fără o rută în amonte funcțională, cu o politică de ieșire restrictivă sau cu o familie de adrese pe care nu o are va eșua la a doua decizie, oricât de corectă ar fi configurația concentratorului. Verificați gazda separat, în afara tunelului, înainte de a atribui eșecul ei lui SoftEther.

SecureNAT nu este nici o autorizare de a ajunge la fiecare rețea conectată la server. Traduce și trimite mai departe traficul care ajunge la el; a decide la ce poate ajunge gazda rămâne treaba firewall-ului și a rutării gazdei, iar un proiect care se bazează pe tunel pentru a acorda acces este la o regulă proastă de a acorda prea mult.

Familiile de adrese merită o verificare proprie. Un exemplu DHCP IPv4 funcțional nu stabilește că fiecare capabilitate IPv6 este prezentă în build-ul dumneavoastră, așa că citiți manualul pentru versiunea pe care o rulați efectiv înainte de a promite comportament dual-stack. Secțiunea SecureNAT din manual acoperă funcțiile NAT și DHCP virtuale pentru versiunea curentă.

Verificați fiecare decizie cu propriul ei test

Acceptați prima decizie cu o verificare a concesiunii: adresă în pool, poartă egală cu interfața virtuală a gazdei, resolver cel pe care l-ați configurat. Acceptați a doua cu o cerere de ieșire din client plus o privire la tabela NAT de pe server, pentru că un număr crescător de sesiuni este singura dovadă directă că traducerea are loc, nu doar că este activată.

Apoi notați separarea în nota de proiectare: ce componentă furnizează adresa, ce componentă trimite mai departe și prin ce interfață a gazdei iese traficul. Când o repornire schimbă comportamentul, acea notă vă spune pe care dintre cele trei să îl inspectați în loc să reporniți totul și să sperați că simptomul se mută.

Încă o decizie aparține înregistrării, chiar dacă nu o luați astăzi: SecureNAT și o punte locală sunt proiecte diferite pentru același concentrator, iar un concentrator care are nevoie de ambele este un concentrator care are nevoie de alt plan. Alegeți deliberat, scrieți de ce, iar următoarea persoană nu va trebui să facă inginerie inversă pornind de la o configurație în funcțiune.