SoftEther SecureNAT: DHCP un NAT ir divi lēmumi

SecureNAT ir viena izvēles rūtiņa, kas ieslēdz divus pakalpojumus, un tieši no tā rodas lielākā daļa neskaidrību par to. Virtuāls DHCP serveris klientam piešķir adresi, masku, vārteju un bieži arī resolveri. Virtuāls NAT pārsūta paketes aiz šīs vārtejas, izmantojot paša servera resursdatora tīkla steku. Tie atrodas blakus konfigurācijā un sabojājas neatkarīgi: klientam var būt nevainojama noma un neviena strādājoša ceļa, vai arī strādājošs ceļš ar iestatījumiem, kas norāda uz nepareizu resolveri. Pārbaudiet tos kā divus lēmumus, un diagnoze kļūst īsa.

Divi pakalpojumi aiz vienas izvēles rūtiņas

Virtuālā DHCP puse atbild uz konfigurācijas jautājumu: kādus iestatījumus šis klients saņem šajā virtuālajā koncentratorā. Virtuālā NAT puse atbild uz pārsūtīšanas jautājumu: kad klients sūta paketi uz adresi ārpus koncentratora, vai serveris to pārtulko un pārsūta. Pirmais ir lokāls koncentratoram un neprasa augšupēju tīklu. Otrais pilnībā atkarīgs no resursdatora.

Virtuālā resursdatora saskarne pieder pirmajam lēmumam, ne otrajam. Tās adrese, bieži pēc noklusējuma kaut kas līdzīgs 192.168.30.1, ir vārteja, ko piedāvā DHCP pakalpojums. Tā nav servera publiskā klausīšanās adrese, un abu sajaukšana rada ugunsmūra noteikumus un klienta iestatījumus, kas vērsti uz mašīnu, kuras šajā tīklā nav.

Lēmums 1: kas nodrošina adresi

Ja virtuālais DHCP ir ieslēgts, klientiem jāsaņem noma jūsu konfigurētajā kopā, ar virtuālo resursdatora saskarni kā vārteju un resolveri, ko norādījāt. Pārbaudiet nomu, nevis klienta statusa tekstu, jo «savienots» apraksta tuneli, nevis adreses piešķiršanu:

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

Divi atteices režīmi ir vērts zināt pirms jebkā cita atkļūdošanas. Klients ar atlikušu statisku adresi no iepriekšējā projekta saglabās to un ignorēs nomu, kas izskatās tā, it kā DHCP atteiktos atbildēt. Un otrs DHCP avots uz tiltā savienota segmenta sacentīsies par tiem pašiem klientiem, kas rada neregulāras adreses un atbalsta rindu, kas nevar reproducēt problēmu.

Pārklājošās kopas arī pieder šeit. Ja virtuālā DHCP kopa pārklājas ar resursdatora LAN apakštīklu vai cita koncentratora kopu, klients iegūst adresi, kas maršrutējas neviennozīmīgi, un katrs vēlākais tests ir nepārliecinošs.

Lēmums 2: kas pārsūta aiz virtuālās vārtejas

Kad virtuālais NAT ir ieslēgts, serveris pārtulko izejošo datplūsmu no koncentratora un nosūta to caur resursdatora maršrutēšanas tabulu. Tas nozīmē, ka pārsūtīšanas ķēde ir: klients uz virtuālo vārteju, virtuālais NAT uz resursdatora steku, resursdatora steks uz savu noklusējuma maršrutu. Katrs posms var sabojāties, neaizskarot pārējos, un atteices pazīmes atšķiras.

Pārbaudiet otro lēmumu ar kaut ko, kam jāatstāj koncentrators, nevis ar kaut ko tam lokālu. Virtuālās vārtejas ping pierāda tikai pirmo posmu un neko vairāk:

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

Ja vārdu izšķiršana darbojas, bet savienojumi ar publisku adresi neizdodas, jūs esat pārsūtīšanas ķēdē, nevis DHCP. Ja neizdodas abi, vispirms pārbaudiet resolveri, jo resolveris, kas nosūtīts kā nesasniedzama iekšējā adrese, liks strādājošam ceļam izskatīties pilnīgi salauztam.

SecureNAT pārsūtīšanu realizē servera process, nevis kodola pārsūtīšanas ceļš, ko izmantotu ar tiltu. Tas ir ērti un lēnāk nekā tiltēšana, un tas nozīmē arī to, ka paša resursdatora ugunsmūra noteikumi un maršrutēšanas lēmumi joprojām attiecas uz pārtulkoto datplūsmu. Virtuālais NAT neapiet resursdatora politiku; tas to izmanto.

Paša resursdatora ceļš ir trešā lieta

Viss iepriekš minētais pieņem, ka servera resursdators var sasniegt galamērķi. Resursdators bez strādājoša augšupēja maršruta, ar ierobežojošu izejas politiku vai ar adrešu saimi, kuras tam nav, neizdosies otrajā lēmumā, lai cik pareiza būtu koncentratora konfigurācija. Pārbaudiet resursdatoru atsevišķi, ārpus tuneļa, pirms attiecināt tā neveiksmi uz SoftEther.

SecureNAT arī nav atļauja sasniegt katru serverim pievienoto tīklu. Tas pārtulko un pārsūta datplūsmu, kas to sasniedz; izlemt, ko resursdators drīkst sasniegt, joprojām ir resursdatora ugunsmūra un maršrutēšanas darbs, un projekts, kas paļaujas uz tuneli piekļuves piešķiršanā, ir viena slikta noteikuma attālumā no pārāk daudz piešķiršanas.

Adrešu saimes ir pelnījušas savu pārbaudi. Strādājošs IPv4 DHCP piemērs nepierāda, ka jūsu būvējumā ir visas IPv6 iespējas, tāpēc pirms divkāršā steka uzvedības solīšanas izlasiet rokasgrāmatu tai versijai, kuru patiešām izmantojat. Rokasgrāmatas SecureNAT sadaļa aptver virtuālās NAT un DHCP funkcijas pašreizējam laidienam.

Pārbaudiet katru lēmumu ar tā paša testu

Pieņemiet pirmo lēmumu ar nomas pārbaudi: adrese kopā, vārteja vienāda ar virtuālo resursdatora saskarni, resolveris tas, ko konfigurējāt. Pieņemiet otro ar izejošu pieprasījumu no klienta un skatienu uz NAT tabulu serverī, jo augošs sesiju skaits ir vienīgais tiešais pierādījums, ka tulkošana notiek, nevis tikai ir ieslēgta.

Pēc tam ierakstiet sadalījumu projektēšanas piezīmē: kura komponente nodrošina adresi, kura komponente pārsūta un pa kuru resursdatora saskarni datplūsma iziet. Kad restartēšana maina uzvedību, šī piezīme pateiks, kuru no trim pārbaudīt, tā vietā lai restartētu visu un cerētu, ka simptoms pārvietosies.

Vēl viens lēmums pieder ierakstam, pat ja šodien to nepieņemat: SecureNAT un lokālais tilts ir atšķirīgi projekti vienam un tam pašam koncentratoram, un koncentrators, kuram vajag abus, ir koncentrators, kuram vajag citu plānu. Izvēlieties apzināti, pierakstiet kāpēc, un nākamajam cilvēkam nevajadzēs to rekonstruēt no strādājošas konfigurācijas.