SoftEther SecureNAT: DHCP ja NAT on kaks otsust

SecureNAT on üks märkeruut, mis lülitab sisse kaks teenust, ja just sellest tuleb suurem osa sellega seotud segadusest. Virtuaalne DHCP-server annab kliendile aadressi, maski, lüüsi ja sageli resolveri. Virtuaalne NAT edastab pakette sellest lüüsist edasi, kasutades serveri hosti enda võrgupinu. Need seisavad konfiguratsioonis kõrvuti ja kukuvad läbi sõltumatult: kliendil võib olla täiuslik rent ja mitte ühtegi töötavat teed, või töötav tee seadetega, mis osutavad vale resolveri poole. Kontrollige neid kahe otsusena ja diagnoos jääb lühikeseks.

Kaks teenust ühe märkeruudu taga

Virtuaalse DHCP pool vastab konfiguratsiooniküsimusele: millised seaded see klient selles virtuaalses jaoturis saab. Virtuaalse NAT-i pool vastab edastamisküsimusele: kui klient saadab paki jaoturist väljapoole jäävale aadressile, kas server tõlgib ja edastab selle. Esimene on jaoturi suhtes kohalik ja ei vaja ülesvoolu võrku. Teine sõltub täielikult hostist.

Virtuaalne hosti liides kuulub esimese otsuse juurde, mitte teise. Selle aadress, sageli vaikimisi midagi sellist nagu 192.168.30.1, on lüüs, mida DHCP-teenus pakub. See ei ole serveri avalik kuulamisadress, ja nende kahe segamini ajamine tekitab tulemüürireegleid ja kliendiseadeid masinale, mida selles võrgus ei ole.

Otsus 1: kes aadressi annab

Kui virtuaalne DHCP on lubatud, peaksid kliendid saama renti teie konfigureeritud puulist, lüüsina virtuaalne hosti liides ja resolverina see, mille te andsite. Uurige renti, mitte kliendi olekuteksti, sest „ühendatud“ kirjeldab tunnelit, mitte aadressi määramist:

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

Enne kui midagi muud siluma hakkate, tasub teada kahte ebaõnnestumise viisi. Klient, kellel on eelmisest lahendusest jäänud staatiline aadress, jätab selle alles ja eirab renti, mis näeb välja nii, nagu DHCP keelduks vastamast. Ja teine DHCP-allikas silla kaudu ühendatud segmendis hakkab samade klientide pärast võistlema, mis tekitab katkendlikke aadresse ja tugijärjekorda, mis ei suuda probleemi korrata.

Kattuvad puulid kuuluvad samuti siia. Kui virtuaalse DHCP puul kattub hosti lokaalvõrgu alamvõrguga või mõne teise jaoturi puuliga, saab klient aadressi, mis marsruutub mitmeti, ja iga hilisem test on ebamäärane.

Otsus 2: kes edastab virtuaalsest lüüsist edasi

Kui virtuaalne NAT on lubatud, tõlgib server jaoturist väljuva liikluse ja saadab selle hosti marsruutimistabeli kaudu. See tähendab, et edastamisahel on: klient virtuaalse lüüsini, virtuaalne NAT hosti pinuni, hosti pinu oma vaikemarsruudini. Iga lüli võib läbi kukkuda teisi puutumata ja rikke tunnused erinevad.

Testige teist otsust millegagi, mis peab jaoturist lahkuma, mitte millegagi, mis on selle suhtes kohalik. Virtuaalse lüüsi pingimine tõestab esimest lüli ja mitte enamat:

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

Kui nimelahendus töötab, aga ühendused avaliku aadressiga nurjuvad, olete edastamisahelas, mitte DHCP-s. Kui mõlemad nurjuvad, kontrollige esmalt resolverit, sest kättesaamatu sisemise aadressina saadetud resolver paneb töötava tee täiesti katki nägema.

SecureNAT-i edastamise realiseerib serveri protsess, mitte tuuma edastustee, mida te sillaga kasutaksite. See on mugav ja sillast aeglasem, ning see tähendab ka, et hosti enda tulemüürireeglid ja marsruutimisotsused kehtivad endiselt tõlgitud liiklusele. Virtuaalne NAT ei möödu hosti poliitikast; see kasutab seda.

Hosti enda tee on kolmas asi

Kõik eelnev eeldab, et serveri host suudab sihtkohta jõuda. Host, kellel pole töötavat ülesvoolu marsruuti, kellel on piirav väljuv poliitika või kellel puudub aadressiperekond, kukub teise otsuse juures läbi, ükskõik kui õige on jaoturi konfiguratsioon. Kontrollige hosti eraldi, väljaspool tunnelit, enne kui omistate selle rikke SoftEtherile.

SecureNAT ei ole ka luba pääseda igasse serveriga ühendatud võrku. See tõlgib ja edastab liiklust, mis temani jõuab; otsustamine, mida host tohib saavutada, jääb endiselt hosti tulemüüri ja marsruutimise tööks, ja lahendus, mis loodab tunnelile juurdepääsu andmisel, on ühe halva reegli kaugusel liiga palju andmisest.

Aadressiperekonnad väärivad omaette kontrolli. Töötav IPv4 DHCP näide ei tõesta, et teie koostises on iga IPv6 võimekus olemas, seega lugege juhendit selle versiooni kohta, mida te tegelikult käitate, enne kui lubate kahekihilise pinu käitumist. Juhendi SecureNAT jaotis katab virtuaalse NAT-i ja DHCP funktsioonid praeguse väljaande jaoks.

Kontrollige iga otsust oma testiga

Võtke esimene otsus vastu rendikontrolliga: aadress puulistis, lüüs võrdne virtuaalse hosti liidesega, resolver see, mille konfigureerisite. Võtke teine vastu kliendi väljuva päringuga ja pilguga serveri NAT-tabelisse, sest kasvav sessioonide arv on ainus otsene tõend, et tõlkimine toimub, mitte ainult ei ole lubatud.

Seejärel kirjutage jaotus disainimärkmesse: milline komponent annab aadressi, milline komponent edastab ja millise hosti liidese kaudu liiklus väljub. Kui taaskäivitamine käitumist muudab, ütleb see märge, millist kolmest uurida, selle asemel et kõike taaskäivitada ja loota, et sümptom liigub.

Veel üks otsus kuulub kirjesse, isegi kui te seda täna ei tee: SecureNAT ja kohalik sild on sama jaoturi jaoks erinevad lahendused, ja jaotur, mis vajab mõlemat, on jaotur, mis vajab teist plaani. Valige teadlikult, kirjutage üles, miks, ja järgmisel inimesel ei tule seda töötavast konfiguratsioonist tagurpidi välja mõelda.