SoftEther SecureNAT: DHCP en NAT binne twa besluten

SecureNAT is ien kontrôlefakje dat twa tsjinsten oansette, en dêr komt it measte betizing oer. In firtuele DHCP-tsjinner jout de klant in adres, masker, gateway en faak in resolfer. In firtuele NAT stjoert pakketten foarby dy gateway mei de eigen netwurkstapel fan 'e tsjinnerhost. Se steane njonkeninoar yn 'e konfiguraasje en mislearje ûnôfhinklik: in klant kin in perfekte hier hawwe en gjin wurkjend paad, of in wurkjend paad mei ynstellings dy't nei de ferkearde resolfer wize. Kontrolearje se as twa besluten, en de diagnoaze wurdt koart.

Twa tsjinsten efter ien kontrôlefakje

De firtuele DHCP-kant beantwurdet in konfiguraasjefraach: hokker ynstellings kriget dizze klant binnen dizze firtuele hub. De firtuele NAT-kant beantwurdet in trochstjoerfraach: as in klant in pakket stjoert nei in adres bûten de hub, set de tsjinner it dan oer en stjoert er it troch. It earste is lokaal foar de hub en hat gjin netwurk boppe nedich. It twadde hinget folslein fan 'e host ôf.

De firtuele hostynterface heart by it earste beslút, net by it twadde. Syn adres, faak by default eat as 192.168.30.1, is de gateway dy't de DHCP-tsjinst oanbiedt. It is net it iepenbiere harkadres fan 'e tsjinner, en betizing fan 'e twa leveret firewallregels en klantynstellings op rjochte op in masine dy't net yn dat netwurk bestiet.

Beslút 1: wa't it adres leveret

As de firtuele DHCP oan stiet, moatte klanten in hier krije yn 'e pool dy't jo konfigurearre hawwe, mei de firtuele hostynterface as gateway en de resolfer dy't jo opjûn hawwe. Besjoch de hier yn stee fan 'e statustekst fan 'e klant, want «ferbûn» beskriuwt de tunnel en net de adrestawizing:

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

Twa mislearringsmodi binne it wurdich te kennen foar't jo eat oars debugge. In klant mei in oerbliuwend statysk adres út in earder ûntwerp hâldt it en negearret de hier, wat liket as wegert DHCP te antwurdzjen. En in twadde DHCP-boarne op in brêge segmint sil om deselde klanten konkurrearje, wat tuskenskoftige adressen en in stipewachtrige jout dy't it probleem net reprodusearje kin.

Oerlaapjende pools hearre hjir ek by. As de firtuele DHCP-pool oerlaapet mei it LAN-subnet fan 'e host of mei de pool fan in oare hub, kriget de klant in adres dat dûbelsinnich rûte wurdt, en elke lettere test is ûnbeslissend.

Beslút 2: wa't foarby de firtuele gateway stjoert

Mei de firtuele NAT oan wurdt útgeand ferkear fan 'e hub troch de tsjinner oerset en fia de rûtetabel fan 'e host stjoerd. Dat betsjut dat de keatling is: klant nei firtuele gateway, firtuele NAT nei hoststapel, hoststapel nei syn standertrûte. Elk skaak kin mislearje sûnder de oaren oan te reitsjen, en de mislearringssinjaalen ferskille.

Test it twadde beslút mei eat dat de hub ferlitte moat, net mei eat dat der lokaal oan is. Pingje nei de firtuele gateway bewissiget it earste skaak en net mear:

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

As nammeoplossing wurket mar ferbiningen nei in iepenbier adres mislearje, dan sit jo yn 'e trochstjoerkeatling en net yn DHCP. As beide mislearje, kontrolearje dan earst de resolfer, want in resolfer dy't as ûnberikber yntern adres útpraat wurdt, lit in wurkjend paad folslein brutsen lykje.

It trochstjoeren fan SecureNAT wurdt útfierd troch it tsjinnerproses, net troch it kernelpaad foar trochstjoeren dat jo mei in brêge brûke soene. Dat is handich en stadiger as brêgje, en it betsjut ek dat de eigen firewallregels en rûtebesluten fan 'e host noch jilde foar it oerset ferkear. De firtuele NAT giet net om 'e belied fan 'e host hinne; it brûkt it.

It eigen paad fan 'e host is in tredde ding

Alles hjirboppe giet derfan út dat de tsjinnerhost de bestimming berikke kin. In host sûnder wurkjend paad omheech, mei in beheinend útgeand belied of mei in adresfamylje dy't er net hat, sil it twadde beslút mislearje, hoe korrekt de hubkonfiguraasje ek is. Kontrolearje de host op himsels, bûten de tunnel, foar't jo syn mislearring oan SoftEther taskriuwe.

SecureNAT is ek gjin tastimming om elk netwurk te berikken dat oan 'e tsjinner ferbûn is. It set ferkear oer en stjoert troch dat him berikt; beslute wat de host berikke mei bliuwt wurk fan 'e firewall en rûte fan 'e host, en in ûntwerp dat op 'e tunnel fertrout om tagong te jaan is ien minne regel fan te folle jaan ôf.

Adresfamyljes fertsjinje har eigen kontrôle. In wurkjend IPv4 DHCP-foarbyld bewissiget net dat elke IPv6-mooglikheid yn jo build sit, dus lês de hânlieding foar de ferzje dy't jo echt draaie foar't jo gedrach mei dûbele stapel tasizze. De SecureNAT-seksje fan 'e hânlieding behannelet de firtuele NAT- en DHCP-funksjes foar de hjoeddeiske ferzje.

Kontrolearje elk beslút mei syn eigen test

Akseptearje it earste beslút mei in hierkontrôle: adres yn 'e pool, gateway gelyk oan 'e firtuele hostynterface, resolfer dy't jo konfigurearre hawwe. Akseptearje it twadde mei in útgeand fersyk fan 'e klant plus in each op 'e NAT-tabel op 'e tsjinner, want in tanimmend oantal sesjes is it iennige direkte bewiis dat oersetten bart en net allinnich oan stiet.

Skriuw dan de splitsing yn 'e ûntwerpnotysje: hokker komponint it adres leveret, hokker komponint trochstjoert en hokker hostynterface it ferkear út giet. As in werstart it gedrach feroaret, fertelt dy notysje hokker fan 'e trije jo besjen moatte, ynstee fan alles wer te starten en te hoopjen dat it symptoom ferpleatst.

Noch ien beslút heart by it record, sels as jo it hjoed net nimme: SecureNAT en in lokale brêge binne ferskillende ûntwerpen foar deselde hub, en in hub dy't beide nedich hat is in hub dy't in oar plan nedich hat. Kies bewust, skriuw op wêrom, en de folgjende persoan hoecht it net werom te yngenieursjen út in draaiende konfiguraasje.