SecureNAT yra vienas žymimasis langelis, įjungiantis dvi paslaugas, ir būtent iš to kyla didžioji dalis painiavos apie jį. Virtualus DHCP serveris klientui suteikia adresą, kaukę, šliuzą ir dažnai resolverį. Virtualus NAT persiunčia paketus už to šliuzo, naudodamas paties serverio pagrindinio kompiuterio tinklo steką. Jie stovi greta konfigūracijoje ir genda nepriklausomai: klientas gali turėti nepriekaištingą nuomą ir neturėti veikiančio kelio, arba turėti veikiantį kelią su nustatymais, rodančiais į neteisingą resolverį. Tikrinkite juos kaip du sprendimus, ir diagnozė taps trumpa.

Dvi paslaugos už vieno žymimojo langelio

Virtualioji DHCP pusė atsako į konfigūracijos klausimą: kokius nustatymus šis klientas gauna šiame virtualiame koncentratoriuje. Virtualioji NAT pusė atsako į persiuntimo klausimą: kai klientas siunčia paketą į už koncentratoriaus esantį adresą, ar serveris jį išverčia ir persiunčia. Pirmasis yra vietinis koncentratoriui ir nereikalauja aukštesnio tinklo. Antrasis visiškai priklauso nuo pagrindinio kompiuterio.

Virtualioji pagrindinio kompiuterio sąsaja priklauso pirmajam sprendimui, o ne antrajam. Jos adresas, dažnai pagal nutylėjimą kažkas panašaus į 192.168.30.1, yra šliuzas, kurį siūlo DHCP paslauga. Tai nėra viešasis serverio klausymosi adresas, o sumaišius abu atsiranda ugniasienės taisyklės ir kliento nustatymai, nukreipti į mašiną, kurios tame tinkle nėra.

Sprendimas 1: kas suteikia adresą

Jei virtualus DHCP įjungtas, klientai turėtų gauti nuomą jūsų sukonfigūruotame telkinyje, su virtualiąja pagrindinio kompiuterio sąsaja kaip šliuzu ir jūsų pateiktu resolveriu. Tikrinkite nuomą, o ne kliento būsenos tekstą, nes „prijungta“ apibūdina tunelį, o ne adreso priskyrimą:

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

Du gedimo režimai verti dėmesio prieš pradedant derinti ką nors kita. Klientas su likusiu statiniu adresu iš ankstesnio projekto jį išsaugos ir nepaisys nuomos, o tai atrodo taip, lyg DHCP atsisakytų atsakyti. O antrasis DHCP šaltinis tiltu sujungtame segmente konkuruos dėl tų pačių klientų, todėl adresai kaitos, o palaikymo eilė negalės atkurti problemos.

Persidengiantys telkiniai taip pat čia priklauso. Jei virtualaus DHCP telkinys persidengia su pagrindinio kompiuterio LAN potinkliu ar kito koncentratoriaus telkiniu, klientas gauna adresą, kuris maršrutizuojamas dviprasmiškai, ir kiekvienas vėlesnis bandymas būna neaiškus.

Sprendimas 2: kas persiunčia už virtualiojo šliuzo

Kai virtualus NAT įjungtas, serveris išverčia iš koncentratoriaus išeinantį srautą ir siunčia jį per pagrindinio kompiuterio maršrutizavimo lentelę. Tai reiškia, kad persiuntimo grandinė yra: klientas į virtualųjį šliuzą, virtualus NAT į pagrindinio kompiuterio steką, pagrindinio kompiuterio stekas į savo numatytąjį maršrutą. Kiekviena grandis gali sugesti neliesdama kitų, o gedimo požymiai skiriasi.

Antrąjį sprendimą tikrinkite tuo, kas turi palikti koncentratorių, o ne tuo, kas jam vietinis. Virtualiojo šliuzo ping patvirtina tik pirmąją grandį ir nieko daugiau:

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

Jei vardų skyrimas veikia, bet ryšiai su viešuoju adresu nutrūksta, esate persiuntimo grandinėje, o ne DHCP. Jei nepavyksta abu, pirmiausia patikrinkite resolverį, nes resolveris, pateiktas kaip nepasiekiamas vidinis adresas, privers veikiantį kelią atrodyti visiškai sudužusį.

SecureNAT persiuntimą įgyvendina serverio procesas, o ne branduolio persiuntimo kelias, kurį naudotumėte su tiltu. Tai patogu ir lėčiau nei tiltas, be to, tai reiškia, kad paties pagrindinio kompiuterio ugniasienės taisyklės ir maršrutizavimo sprendimai vis dar taikomi išverstam srautui. Virtualus NAT neapeina pagrindinio kompiuterio politikos; jis ją naudoja.

Paties pagrindinio kompiuterio kelias yra trečias dalykas

Visa tai, kas aukščiau, daro prielaidą, kad serverio pagrindinis kompiuteris gali pasiekti paskirties vietą. Pagrindinis kompiuteris be veikiančio aukštesnio maršruto, su ribojančia išėjimo politika arba be tos adresų šeimos, kurios neturi, suges antrajame sprendime, kad ir kokia teisinga būtų koncentratoriaus konfigūracija. Patikrinkite pagrindinį kompiuterį atskirai, už tunelio, prieš priskirdami jo gedimą SoftEther.

SecureNAT taip pat nėra leidimas pasiekti kiekvieną prie serverio prijungtą tinklą. Jis verčia ir persiunčia srautą, kuris jį pasiekia; spręsti, ką pagrindinis kompiuteris gali pasiekti, vis dar yra jo ugniasienės ir maršrutizavimo darbas, o projektas, kuris pasikliauja tuneliu suteikdamas prieigą, yra viena bloga taisyklė nuo suteikimo per daug.

Adresų šeimos nusipelno atskiro patikrinimo. Veikiantis IPv4 DHCP pavyzdys neįrodo, kad jūsų rinkinyje yra kiekviena IPv6 galimybė, todėl perskaitykite tos versijos, kurią iš tikrųjų vykdote, vadovą, prieš žadėdami dvigubo steko elgseną. Vadovo SecureNAT skyrius apima virtualias NAT ir DHCP funkcijas dabartiniam leidimui.

Patikrinkite kiekvieną sprendimą jo paties testu

Priimkite pirmąjį sprendimą nuomos patikrinimu: adresas telkinyje, šliuzas lygus virtualiajai pagrindinio kompiuterio sąsajai, resolveris tas, kurį sukonfigūravote. Priimkite antrąjį išėjimo užklausa iš kliento ir žvilgsniu į NAT lentelę serveryje, nes augantis sesijų skaičius yra vienintelis tiesioginis įrodymas, kad vertimas vyksta, o ne tik kad jis įjungtas.

Tada užrašykite atskyrimą projektinėje pastaboje: kuris komponentas suteikia adresą, kuris komponentas persiunčia ir per kurią pagrindinio kompiuterio sąsają srautas išeina. Kai perkrovimas pakeis elgseną, ta pastaba pasakys, kurią iš trijų tikrinti, užuot perkrovus viską ir tikintis, kad simptomas pasislinks.

Dar vienas sprendimas priklauso įrašui, net jei šiandien jo nepriimate: SecureNAT ir vietinis tiltas yra skirtingi projektai tam pačiam koncentratoriui, o koncentratorius, kuriam reikia abiejų, yra koncentratorius, kuriam reikia kito plano. Rinkitės sąmoningai, užrašykite kodėl, ir kitam žmogui nereikės to atkurti iš veikiančios konfigūracijos.

Susiję straipsniai