Windows.  Virus.  Anteckningsböcker.  Internet.  kontor.  Verktyg.  Förare

  • 01.02.2010

Idag kommer vi att överväga frågan om att organisera internetåtkomstdelning och automatisk nätverkskonfiguration på Windows-plattformen. Trots att detta är en dyrare lösning, kommer dess användning vara motiverad vid en tät integration med nätverksinfrastrukturen utplacerad på basis av Windows Server.

Som arbetsplattform använde vi Windows Server 2008 R2, som den mest uppdaterade plattformen idag, dock gäller allt som sagts, med mindre ändringar, även tidigare versioner av Windows Server 2003/2008.

Inledningsvis måste du konfigurera nätverksgränssnitt. I vårt fall tar gränssnittet som tittar in i leverantörens nätverk emot inställningar via DHCP, vi döpte om det till EXT. Det interna gränssnittet (LAN) har en statisk IP-adress på 10.0.0.1 och en mask på 255.255.255.0.

NAT-inställning

Det enklaste sättet att organisera allmän tillgång till Internet kommer att aktivera motsvarande alternativ i nätverksanslutningsinställningarna. Men för all sin enkelhet är denna metod extremt oflexibel och är acceptabel endast om inga andra routinguppgifter placeras före servern. Det är bättre att gå en mer komplicerad, vid första anblicken, väg, men få tag på ett mycket kraftfullt och flexibelt verktyg som låter dig lösa mycket mer komplexa nätverksproblem.
Låt oss börja, som förväntat, med att lägga till en ny serverroll: Nätverkspolicy och åtkomsttjänster.

I rolltjänster, anm Routing och fjärråtkomsttjänster, allt annat intresserar oss inte nu. Efter framgångsrik installation av rollen kan du fortsätta till routinginställningarna.

I Kasta hitta routingtjänsten och genom menyn Handlingar välja Konfigurera och aktivera routing och Fjärranslutning . Inställningen görs med hjälp av en guide som guidar oss steg för steg genom alla inställningssteg. Som en konfiguration, välj Nätverksadressöversättning (NAT), alla andra funktioner kan konfigureras manuellt senare.

Här måste du ange vilket gränssnitt som vår server är ansluten till Internet med, om det behövs kan du skapa det (till exempel när du använder PPPoE eller VPN-anslutningar).

Vi lämnar resten av inställningarna som standard och efter att ha klickat på knappen är klar startar tjänsten Routing och Remote Access, vår server är redo att betjäna klienter från internt nätverk. Du kan kontrollera prestandan genom att ange klientdatorn en IP-adress från intervallet för det interna nätverket och ange som gateway och DNS-servrar vår serveradress.

Konfigurerar DHCP

För att automatiskt konfigurera nätverksinställningar på klientdatorer, ja, kör inte från plats till plats för att manuellt skriva ut IP-adresser, bör du lägga till rollen DHCP-server A.

För detta väljer vi Lägg till roll V Serverhanterare och markera det alternativ vi behöver.

Nu måste vi svara på några enkla frågor. I synnerhet för att välja för vilka interna nätverk DHCP ska användas, vid behov, kan du konfigurera olika inställningar för olika nätverk. Ange sedan parametrarna för DNS- och WINS-servrarna sekventiellt. Det senare kan i sin frånvaro utelämnas. Om ditt nätverk inte har gamla arbetsstationer som kör andra operativsystem än Windows NT 5 och högre (2000 / XP / Vista / Seven), så finns det inget behov av en WINS-server.

Att lägga till ett DHCP-scope bör behandlas med stor försiktighet, ett misstag här kan leda till att hela nätverket inte fungerar. Det är inget komplicerat här, ange bara noggrant alla nödvändiga nätverksparametrar, se till att det tilldelade IP-intervallet inte överlappar det som redan tilldelats för andra enheter och glöm inte att ange masken och gatewayen korrekt.

Separat bör du vara uppmärksam på en sådan parameter som hyresperioden för adressen. Efter att hälften av leasingavtalet löper ut skickar klienten en begäran till servern om att förnya leasingavtalet. Om servern inte är tillgänglig kommer begäran att upprepas efter halva återstående tid. I trådbundna nätverk, där datorer inte rör sig inom nätverket, kan du ställa in en tillräckligt lång hyresperiod, om tillgänglig. ett stort antal mobilanvändare (till exempel offentliga wifi-hotspot på ett café) kan hyresperioden begränsas till några timmar, annars kommer inte de hyrda adresserna att släppas i tid och poolen kanske inte innehåller gratisadresser.

Nästa steg är att vägra stöd för IPv6 och efter installation av DHCP-rollen är servern redo att fungera utan några ytterligare inställningar. Du kan kontrollera driften av klientdatorer.

Utfärdade IP-adresser kan ses i Hyrda adresser relaterat till området av intresse för oss. Här kan du också konfigurera reservationen för en specifik klient av en specifik adress (bindande med namn eller MAC-adress), om det behövs kan du lägga till eller ändra parametrarna för området. Filter låter dig skapa tillåta eller neka regler baserat på klienters MAC-adresser. En mer fullständig genomgång av alla funktioner i Windows Server 2008 R2 DHCP-servern ligger utanför ramen för den här artikeln och troligen kommer vi att ägna ett separat material till dem.

  • Taggar:

Vänligen aktivera JavaScript för att se kommentarerna som drivs av Disqus.

Spåra tillbaka

I vår tidigare artikel tittade vi på att ställa in NAT för Windows Server-plattformen. Som läsarens svar har visat uppstår vissa svårigheter vid användning av uppringda Internetanslutningar: VPN eller PPPoE. Idag ska vi ta en titt på...

NAT(Network Address Translation) är en IETF-standard (Internet Engineering Task Force). arbetsgrupp utveckling av internetteknik), med hjälp av flera datorer privata nätverk(med privata adresser i intervall som 10.0.x.x, 192.168.x.x, 172.x.x.x) kan dela en enda IPv4-adress som ger åtkomst till globalt nätverk. Den främsta orsaken till den växande populariteten för NAT är relaterad till den växande bristen på IPv4-adresser. Dessutom använder många Internet-gateways aktivt NAT, särskilt för att ansluta till bredbandsnät t.ex. via DSL eller kabelmodem.

Ställer in NAT

För att fungera som en router måste servern ha 2 nätverksgränssnitt. Internet och själva nätverket, som måste lanseras på Internet. jag har nätverkskopplingar kallas LAN_1 (Internet) och LAN_2 (lokalt nätverk).

Låt mig bara säga att tjänsten Windows-brandvägg/internetanslutningsdelning (ICS) bör inaktiveras.

Så låt oss börja med installationen:





NAT-inställning

Så vi har installerat nätverksgränssnitten, nu ska vi konfigurera dem.

Först av allt, låt oss ställa in Externt gränssnitt (LAN_1):

192.168.0.2 - IP-adressen till användaren som kommer åt nätverket via vår server

10.7.40.154 - extern IP-adress för servern

Genom att komma åt Internet med denna teknik får du en IP-adress på 10.7.40.154. Det finns olika sätt att ställa in, du kan reservera adresser för varje maskin separat. I reservationen kan du ange mer än ett adressintervall eller inte ange alls, sedan vilken IP-adress som helst lokalt nätverk kommer att kunna surfa på Internet via servern.

Konfigurera klientdatorn

Vi går till Egenskaper lokal nätverkskort, Ytterligare TCP/IP-egenskaper. Vi föreskriver klientens IP, mask, in Huvudingång ange serverns IP-adress. I DNS-fälten måste du ange IP-adressen för DNS-leverantören eller IP-adressen för den installerade lokala DNS-servern.

Allt! Detta slutför installationen och konfigurationen.

Nätverksadressöversättning (NAT) är ett sätt att mappa om ett adressutrymme till ett annat genom att ändra information, det vill säga att pakethuvuden ändras medan de är på väg genom en trafikdirigeringsenhet. Denna metod användes ursprungligen för att enkelt omdirigera trafik på IP-nätverk utan att numrera om varje värd. Det har blivit ett populärt och viktigt verktyg för att bevara och allokera globalt adressutrymme inför bristen på IPv4-adresser.

NAT - vad är det?

Den ursprungliga användningen av nätverksadressöversättning är att mappa varje adress i ett adressutrymme till motsvarande adress i ett annat utrymme. Detta är till exempel nödvändigt om ISP har ändrats och användaren inte har möjlighet att offentligt meddela en ny rutt till nätverket. Med den förutsebara globala utarmningen av IP-adressutrymmet har NAT-teknik använts alltmer sedan slutet av 1990-talet i kombination med IP-kryptering (vilket är en metod för att flytta flera IP-adresser till ett utrymme). Denna mekanism är implementerad i en routingenhet som använder tillståndsbestämda översättningstabeller för att mappa "dolda" adresser till en enda IP-adress, och vidarebefordrar utgående IP-paket på väg ut. Sålunda visas de som kommer ut från routingenheten. Omvänt mappas svar till käll-IP-adressen med hjälp av regler lagrade i översättningstabeller. Översättningstabellreglerna rensas i sin tur efter en kort period om ny trafik inte uppdaterar sitt tillstånd. Detta är den grundläggande mekanismen för NAT. Vad betyder det här?

Denna metod tillåter endast kommunikation via routern när anslutningen är på ett krypterat nätverk, eftersom detta skapar översättningstabeller. Till exempel kan en webbläsare i ett sådant nätverk visa en webbplats utanför det, men när den är installerad utanför det kan den inte öppna en resurs som finns i den. Men de flesta NAT-enheter låter dig idag konfigurera översättningstabellposter för permanent användning. Denna funktion kallas ofta statisk NAT eller portvidarebefordran, och den tillåter trafik som kommer från det "utanför" nätverket att nå utsedda värdar på det krypterade nätverket.

På grund av populariteten för denna metod, som används för att spara IPv4-adressutrymme, har termen NAT (vad det faktiskt är - nämnt ovan) blivit nästan synonymt med en krypteringsmetod.

Eftersom Network Address Translation ändrar adressinformationen för IP-paket har detta allvarliga konsekvenser för kvaliteten på en Internetanslutning och kräver noggrann uppmärksamhet på detaljerna i dess implementering.

NAT-implementationer skiljer sig från varandra i sitt specifika beteende i olika fall när det gäller påverkan på nätverkstrafik.

Grundläggande NAT

Den enklaste typen av nätverksadressöversättning (NAT) tillhandahåller en-till-en-översättning av IP-adresser. RFC 2663 är huvudtypen av denna översättning. I denna typ ändras endast IP-adresserna och kontrollsumman för IP-huvudena. De grundläggande översättningstyperna kan användas för att ansluta två IP-nätverk som har inkompatibel adressering.

NAT - vad är det i en en-till-många-koppling?

De flesta varianter av NAT är kapabla att kartlägga flera privata värdar till en enda offentligt angiven IP-adress. I en typisk konfiguration använder LAN en av subnätets tilldelade "privata" IP-adresser (RFC 1918). En router i detta nätverk har en privat adress i detta utrymme.

Routern ansluter också till Internet med en "offentlig" adress som tilldelas av Internetleverantören. Eftersom trafiken passerar från det lokala källnätverket i varje paket, översätts den i farten från en privat adress till en offentlig. Routern håller reda på grundläggande information om varje aktiv anslutning (särskilt destinationsadress och port). När svaret returneras till det använder det anslutningsdata som lagras under den utgående etappen för att bestämma den privata adressen för det interna nätverket som svaret ska dirigeras till.

En fördel med denna funktion är att den fungerar som en praktisk lösning på den förestående utmattningen av IPv4-adressutrymmet. Även stora nätverk kan anslutas till Internet med en enda IP-adress.

Alla paketdatagram på IP-nätverk har 2 IP-adresser - källa och destination. Typiskt kommer paket som färdas från det privata nätverket till det offentliga nätverket att ha källadressen för paketen som ändras under övergången från det offentliga nätverket tillbaka till det privata nätverket. Mer komplexa konfigurationer är också möjliga.

Egenheter

NAT-inställningen kan ha vissa egenheter. Ytterligare modifieringar krävs för att undvika svårigheter med att översätta de returnerade paketen. Den stora majoriteten av internettrafiken går via TCP- och UDP-protokollen och deras portnummer ändras på ett sådant sätt att kombinationen av IP-adress och portnummer börjar matcha när data skickas tillbaka.

Protokoll som inte är baserade på TCP och UDP kräver andra översättningsmetoder. Message Control Protocol (ICMP) korrelerar i allmänhet den överförda datan med en befintlig anslutning. Det betyder att de måste visas med samma IP-adress och nummer som ursprungligen ställdes in.

Vad bör man ta hänsyn till?

Att ställa in NAT på routern ger den inte ände-till-ände-anslutning. Därför kan sådana routrar inte delta i vissa Internetprotokoll. Tjänster som kräver initiering av TCP-anslutningar från ett externt nätverk eller icke-protokollanvändare kanske inte är tillgängliga. Om NAT-routern inte anstränger sig så mycket för att stödja sådana protokoll kan inte inkommande paket nå sin destination. Vissa protokoll kan lagras i samma översättning mellan deltagande värdar ("passivt läge" FTP, till exempel), ibland med hjälp av en applikationslager-gateway, men anslutningen kommer inte att upprättas när båda systemen är separerade från Internet av NAT . Användningen av NAT komplicerar också "tunneling"-protokoll som IPsec eftersom det ändrar värden i rubriker som interagerar med förfrågningsintegritetskontroller.

Befintligt problem

End-to-end-anslutning har varit en kärnprincip för Internet sedan starten. Nätverkets nuvarande tillstånd visar att NAT är ett brott mot denna princip. Det finns en allvarlig oro bland experter om den allestädes närvarande användningen av nätverksadressöversättning i IPv6, och frågan om hur man effektivt kan eliminera det tas upp.

På grund av den kortlivade karaktären hos översättningstillståndstabellerna i NAT-routrar, förlorar interna nätverksenheter sin IP-anslutning, vanligtvis inom en mycket kort tidsperiod. På tal om vad NAT är i en router, vi får inte glömma denna omständighet. Detta minskar avsevärt driftstiden för kompakta enheter som drivs av batterier och ackumulatorer.

Skalbarhet

Vid användning av NAT övervakas dessutom endast portar som snabbt kan tömmas. interna applikationer, som använder flera samtidiga anslutningar (till exempel HTTP-förfrågningar för webbsidor med ett stort antal inbäddade objekt). Detta problem kan mildras genom att spåra destinations-IP förutom porten (därmed delas en lokal port av många fjärrvärdar).

Vissa svårigheter

Eftersom alla interna adresser är maskerade som en enda publik adress, blir det omöjligt för externa värdar att initiera en anslutning till en viss intern värd utan speciell konfiguration på brandväggen (som måste vidarebefordra anslutningar till en specifik port). Applikationer som IP-telefoni, videokonferenser och liknande tjänster måste använda NAT-traversalmetoder för att fungera korrekt.

Omvänd adress och portöversättning (Rapt) gör att en värd vars riktiga IP-adress ändras från tid till annan förblir tillgänglig som en server med en fast IP-adress hemnätverk. I grund och botten bör detta tillåta servrarnas inställningar att behålla anslutningen. Även om detta inte är en perfekt lösning på problemet, kan det vara en annan användbart verktyg i en nätverksadministratörs arsenal när man löser problemet med hur man konfigurerar NAT på en router.

Port Address Translation (PAT)

Cisco Rapts implementering är Port Address Translation (PAT), som mappar flera privata IP-adresser som en enda offentlig IP-adress. Flera adresser kan visas som en adress eftersom var och en spåras av ett portnummer. PAT använder unika källportnummer på den inre globala IP-adressen för att skilja mellan dataöverföringsriktningen. Dessa tal är 16-bitars heltal. Det totala antalet interna adresser som kan översättas till en extern kan teoretiskt nå 65536. Det faktiska antalet portar som en enskild IP-adress kan tilldelas är cirka 4000. Som regel försöker PAT behålla den ursprungliga porten för " original". Om den redan används tilldelar Port Address Translation det första tillgängliga portnumret, från början av lämplig grupp - 0-511, 512-1023 eller 1024-65535. När det inte finns fler tillgängliga portar och det finns mer än en extern IP-adress, går PAT vidare till nästa för att försöka allokera källporten. Denna process fortsätter tills tillgängliga data tar slut.

Adress- och portmappningen görs av en Cisco-tjänst som kombinerar översättningsportadressen med IPv4-pakettunnlingsinformation över det interna IPv6-nätverket. Det är i huvudsak ett inofficiellt alternativ till CarrierGrade NAT och DS-Lite som stöder IP-adress/portöversättningar (och därmed stöds NAT-inställning). Således undviker den problem med att upprätta och underhålla en anslutning, och tillhandahåller också en övergångsmekanism för IPv6-distribution.

Översättningsmetoder

Det finns flera sätt att implementera nätverksadress och portöversättning. I vissa applikationsprotokoll som använder IP-adressapplikationer som körs på ett krypterat nätverk är det nödvändigt att bestämma den externa NAT-adressen (som används i den andra änden av anslutningen), och dessutom är det ofta nödvändigt att studera och klassificera typ av överföring. Detta görs vanligtvis för att det är önskvärt att skapa en direkt kommunikationskanal (antingen för att hålla dataöverföringen genom servern oavbruten eller för att förbättra prestanda) mellan två klienter, som båda ligger bakom separata NAT:er.

För detta ändamål (hur man ställer in NAT) utvecklades ett speciellt protokoll RFC 3489 2003, som ger en enkel förbikoppling av UDP över NATS. Idag är det föråldrat, eftersom sådana metoder inte är tillräckliga idag för att korrekt utvärdera prestandan hos många enheter. De nya metoderna standardiserades i RFC 5389, som utvecklades i oktober 2008. Denna specifikation är nu känd som SessionTraversal och är ett verktyg för att köra NAT.

Skapa en tvåvägslänk

Varje TCP- och UDP-paket innehåller käll-IP-adressen och dess portnummer, samt koordinaterna för destinationsporten.

För offentliga tjänster som e-postserverfunktionalitet är portnumret viktigt. Till exempel kopplar till programvara webbserver och 25 till SMTP Mejl server. IP-adressen för den offentliga servern är också viktig, som en postadress eller ett telefonnummer. Båda dessa parametrar måste vara tillförlitligt kända för alla noder som avser att upprätta en anslutning.

Privata IP-adresser spelar bara roll i de lokala nätverk där de används och även på värdportar. Portar är unika kommunikationsslutpunkter på en värd, så NAT-anslutning stöds med en kombinerad port- och IP-adressmappning.

PAT (Port Address Translation) löser konflikter som kan uppstå mellan två olika värdar som använder samma källportnummer för att skapa unika anslutningar samtidigt.

/05.07.2004 20:43/

Under de senaste åren, bland ryska nätverksadministratörer, modet för FireWall och NAT. Eserv-användare har känt till min inställning till dessa tekniker sedan mitten av 90-talet, men ibland ställs sådana frågor om FireWall / NAT av nybörjare, och jag måste upprepa mig själv. Därför skrev jag för ungefär ett år sedan en separat artikel om FireWall, och idag är det NAT:s tur.

Motto

Tillagd 2005-12-28. Google gjorde en bra sammanfattning av NAT-problemet: "NAT-enheter, allt populärare i hem och kontor, tillåter flera maskiner att dela en enda Internetadress. Följaktligen blir det svårare och svårare för applikationer som röstchatt, som kräver att kamrater kontakta varandra direkt för att skapa en peer-to-peer-anslutning på ett tillförlitligt sätt." (NAT-enheter, som växer i popularitet i hem och kontor, tillåter flera maskiner att dela ett internetadress. Som ett resultat kan applikationer som röstchatt, som kräver direkt adressering av parter, svårare och svårare att skapa pålitliga förbindelser prick-prick.)

Dokument innehållsförteckning

NAT:s historia

Först några ord om historien om uppkomsten av behovet av proxy / gating / tunnling på Internet, sedan kommer möjligheterna för olika tillvägagångssätt och deras "hierarki" att bli tydligare. Som ni vet förutspåddes bristen på IP-adresser i 4-byte adressutrymmet redan i början av 90-talet (plus bristen på pengar för att hyra adressblock i vissa företag. Därför kom de redan i mars 1994 överens om adressen " segmentering" av det totala utrymmet - tilldelning för lokala nätverk separata intervall av IP-adresser och exkludering av dessa IP-adresser från användning på Internet (http://www.ietf.org/rfc/rfc1597.txt Mars 1994 Adresstilldelning för privata Internet; citat om syftet med detta dokument "Författarna hoppas att användningen av dessa metoder kommer att leda till betydande besparingar i tilldelningen av adresser"). Denna lösning gjorde det möjligt för företag att allokera små block av IP-adresser till sina internetservrar, och inom LAN tilldelades IP-adresser för sina egna behov av företagen själva från intervallen för lokala nätverk. Det gjorde att företagens internetservrar (mail och www/ftp) var lättillgängliga både från internet och från LAN, och inom LAN kommunicerade datorer utan problem med samma IP-protokoll. Men detta beslut skapade en barriär mellan lokala nätverk och Internet: samma IP-adress kan användas i olika LAN, och eftersom av denna anledning slutade Internet att dirigera paket till adressblock som tilldelats för LAN. De där. i själva verket en "fysisk barriär" (utan att skära av ledningar, vilket var kul i ryska banker efter de första hackningarna, och utan att installera FireWall, vilket är vad de nu är beroende av). Nätverk har blivit isolerade, eftersom uppgifter är isolerade i modern operativsystem- var och en har sitt eget adressutrymme. Denna barriär var inte ett problem för posten, eftersom företagspostservrar placerades i utkanten av nätverk och var synliga från både Internet och LAN. Men med åtkomst från LAN till externa resurser – till ftp och http-servrar som fortfarande växte i popularitet under dessa år, började problem. Om det tidigare var möjligt att direkt interagera med servern från vilken dator som helst, har nu bara datorer med riktiga internetadresser denna möjlighet. till vilket LAN som ska skickas ett svar till ett IP-paket som har en lokal adress i returadressen - routern kommer inte att kunna avgöra.

Den enklaste lösningen på detta problem - ersättningen av returadressen i utkanten av nätverk - låg på ytan och var inte långsam med att publiceras: i maj 1994, dvs. två månader efter "sektionen av nätverk" föreslogs NAT-specifikationen: http://www.ietf.org/rfc/rfc1631.txt The Network Address Translator (NAT) maj 1994 Författarna meddelade detta som en "kortsiktig lösning", d.v.s. tillfällig lösning av det angivna problemet, ett slags "hack", tills normala lösningar blir utbredda. Men som ni vet är ingenting så permanent som att tillfällig IPv6, mot förmodan, inte snabbt slog rot, och under de senaste 10 åren har vi sett fler och fler strider vid gränserna mellan LAN och Internet. NAT har blivit utbredd, eftersom. det fanns ingen annan acceptabel lösning på detta problem under dessa år: FTP-klienter och HTTP-klienter (webbläsare) hade inte tid att anpassa sig till den förändrade bilden av världen, kunde inte arbeta från ett LAN med externa resurser, så för att göra gränsen genomskinlig för dem, de "lurade" helt enkelt programmässigt med hjälp av NAT - alla IP-paket adresserade från LAN till utsidan utsattes för den enklaste behandlingen vid gränsen: att ersätta den omvända IP-adressen med den verkliga adressen för "gräns"-datorn , och omvänt ersätter det i inkommande paket. Dessutom ersattes vanligtvis portnumret för LAN-källan också. paket kan komma från olika maskiner på LAN med samma portnummer. De där. inte bara IP-adresser översätts, utan även portnummer (ibland kallas portöversättare för en separat förkortning PAT). I den villkorliga klassificeringen är NAT uppdelad i "statisk, dynamisk och maskerad (maskerad)", men i praktiken används huvudsakligen den tredje typen, den låter dig betjäna tusentals anslutningar från LAN genom en riktig adress (helst), medan portöversättning används alltid. På en NAT-dator eller router + NAT tilldelas ett antal portar som används för översättning, till exempel med nummer större än 60000 (för att snabbt skilja dessa portar från de som tilldelats för denna dators egna behov) och en dynamisk tabell över aktuella sessioner / adresskartläggningar. Varje passerande paket kontrolleras mot denna tabell av och port och lämpliga ersättningar görs. Tekniken är så enkel att det nu blir allt mer sällsynt att hitta en router eller kabelmodem utan inbyggd NAT (och FireWall, lika primitiv som NAT), och NAT kan redan hittas även i hubbar med priser som börjar på $ 40. Inte för att nämna den "fria" NAT, som är en del av flera senaste versionerna Windows som heter " anslutningsdelning"och" anslutningsdelning". Det är tillgänglighet, lätt att förstå/använda och kravlös för klientprogramvara som gjorde NAT välförtjänt populär.

NAT "genom ögonen" på internetprogram

Om allt i praktiken var så enkelt, så skulle det inte vara intressant, men, som med alla andra mjukvaruknep, började olika obehagliga biverkningar genast smyga sig fram i NAT. När NAT dök upp var ett av de mest populära protokollen FTP, och det var detta protokoll som blev det första icke-smältbara protokollet för NAT. Detta avslöjade ett problem som aldrig hade lösts framgångsrikt i NAT under de senaste 10 åren. Och i det allmänna fallet kan det inte lösas inom NAT, det kan bara göras justeringar för specifika protokoll, men dessa justeringar kan inte anses vara en tillförlitlig lösning. Problemet är att i vissa protokoll, bland vilka FTP är det äldsta, överförs klientmaskinens IP-adress, och denna IP-adress används av servern för att överföra data till klienten. Eftersom i fallet med NAT, klientprogrammet som arbetar från LAN "luras" av NAT, kan det bara skicka sin egen lokala IP-adress till servern, som den externa servern inte kommer att kunna ansluta till på grund av osynligheten av lokala nätverk från Internet Andra exempel är protokollen ICQ, MS NetMeeting, RealAudio och många andra protokoll, vars utvecklare tydligen satt i nätverk utan
NAT NAT kan bara erbjuda en lösning på detta problem - baserat på portnummer, gissa det specifika protokollet som översätts och börja övervaka innehållet i IP-paket. När de stöter på PORT FTP-kommandot, som specificerar: porten för den lokala klienten (ett textkommando i paketets brödtext och inte i IP-paketets rubrik), ersätt inte bara rubrikerna utan hela paketet , med omräkning av kontrollsumman och organisation av avlyssning av en inkommande port. Tyvärr för NAT är TCP-protokollet i vilket FTP-protokollkommandona överförs ett strömningsprotokoll organiserat över - PORT-kommandot, när det träffar IP-lagret, kan delas upp i 2 paket (eller till och med fler, beroende på FTP-klienten och buffring i operativsystemet). Därför, för att på ett tillförlitligt sätt upptäcka NAT-spoofing, måste du rekonstruera den ursprungliga TCP-strömmen, buffra och sätta ihop paket. Vi kommer att återgå till "rekonstruktionen av protokoll" i NAT, men för tillfället noterar vi bara den flerskiktade nivån av potentiella fel och opålitlighet i denna process.I praktiken leder detta till att standard FTP-läge som använder kommandot PORT over NAT vanligtvis INTE fungerar.

Därför måste "NAT-problemet" i FTP-protokollet lösas på ett speciellt sätt i FTP-klienter eller i en annan mellanliggande specialiserad FTP-proxy. I FTP-klienten måste du för detta byta till den så kallade. "passivt läge" - använd PASV-kommandot istället för PORT-kommandot. PASV ber FTP-servern att öppna en extra port på sig själv och berätta för klienten dess :port. Klienten ansluter sedan till den angivna (NAT lurar den igen, sänder den) och sessionen lyckas. Förutom behovet av att stödja PASV-läge i FTP-klienten (det finns inte i standarden ftp.exe), kräver detta också en viss ansträngning från FTP-serveradministratörens sida - speciellt om han också är delvis blockerad av brandväggar och NAT:er (eftersom FTP-utvecklarservrarna för Eserv känner till dessa problem från första hand). Generellt sett hjälper inte NAT här att ansluta, utan stör.

Nu om rekonstruktionen av protokollet inuti NAT för en "transparent" för klienten att kringgå problemet. De få NAT:er som kan göra detta (även om de i praktiken också deklarerar snarare än de kan, går faktiskt upp ett nätverkslager - istället för det enklaste paketet framåt med adressöversättning i huvudet, börjar de göra samma sak som TCP-stacken gör - att sätta ihop TCP-paket och på så sätt omvandla dem från en överutvecklad router till en underutvecklad TCP-applikationsproxy. det här fallet till en FTP-proxy eller en FTP-grind. Underutvecklad eftersom klienten inte känner till denna proxy, och NAT fortsätter i sin tur att gissa protokollet och ta itu med en uppgift som är obekväm att lösa på sin nivå (nivån för IP-paket).

Den här uppgiften är mycket lättare att lösa om du istället för NAT eller utöver den omedelbart använder en specialiserad proxy (FTP-gate) eller universella TCP-proxyer som Socks eller, i extremfallet, https (det här extrema fallet kommer fortfarande att fungera bättre än NAT). De arbetar initialt på TCP-nivå och lurar inte FTP-klienten, utan samarbetar med den. Tre lager av problem försvinner på en gång: FTP-klienten kan använda vilket läge som helst - aktivt eller passivt (i HTTPS endast passivt, som i NAT), det finns ingen anledning att gissa protokollet och dubbel TCP-montering. Dessutom har administratören fler möjligheter att påverka processen (mer om det senare).

Om klientprogrammet inte vet hur man arbetar genom en speciell proxy (det finns praktiskt taget ingen kvar, men vi kommer att prata om de värsta fallen), då när man använder en Socks-proxy, kan klientens arbete också göras transparent med SocksCapture eller inrikes FreeCap-program. Transparensen av gränsen är alltid ett knep, men SocksCapture eller FreeCap fångar inte upp IP-paket, utan programanrop till OS, så de vet alltid exakt, och beräknar inte från paketströmmen, exakt vilken åtgärd programmet vill utföra , och följaktligen omdirigera dessa åtgärder genom Socks -proxy.

NAT vs strumpor

Eftersom vi pratar om strumpor, måste vi säga några ord om detta proxyprotokoll. Dessutom var Socks historiskt sett nästa sätt att korsa gränsen mellan LAN och Internet efter NAT: den första recensionsartikeln "vad är strumpor" publicerades i oktober 1994, Socks4-specifikationen dök snart upp (tidigare "versioner" användes inte i någon produkter) http ://www.socks.nec.com/protocol/socks4a.protocol och endast av version 5 i mars 1996 var mogen för publicering i ietf som en RFC: http://www.ietf.org/rfc/ rfc1928.txt. Det finns en rysk version av detta dokument - översättningen gjordes av Alexander Gorlach, som sedan (97 och 98) arbetade i vårt företag och deltog i skapandet av Eserv / 2, se sidan Socks5.

Socks har övervunnit alla begränsningar av NAT, plus lagt till minst tre praktiska verktyg som inte bara gör det möjligt att "proxy" nästan alla TCP- och UDP-protokoll, utan också för att förbättra kontrollen över användningen av Internet från LAN:

  1. Socks hanterar inte bara utgående anslutningar, utan låter dig också skapa lyssnande inkommande sockets på en proxymaskin (BIND-metoden) på begäran av en proxyklient - det är precis vad FTP och liknande mesh-protokoll kräver.
  2. Socks4a och Socks5 låter dig ta bort uppgiften att lösa domännamn på klienten från klienten och göra det direkt i proxyn. De där. en DNS-server eller DNS-mappning (via NAT eller speciell UDPMAP) blir onödig på maskinen inuti LAN, en "tick" av hans bekymmer tas bort från admin, plus, på grund av DNS-cache på servern, fungerar klienten snabbare.
  3. Socks5 stöder olika alternativ för explicit klientautentisering och auktorisering. I NAT var det möjligt att skilja vänner från främlingar endast med .
Men Socks, även om det har förbättrat användbarheten jämfört med NAT, förblir en universell "programmerbar mappning". Några av NAT-problemen förblev olösta i den. Och de kan inte lösas på en låg nivå utan att gå in på detaljerna i det specifika protokollet som fullmaktseras. Precis som till exempel en telefon kan överföra mänskligt tal, men inte kan förstå det och filtrera bort missbruk.Därför använder de administratörer som vill ha fullständig kontroll över vad som händer på deras nätverk specialiserade proxyservrar.

NAT och specialiserade proxyservrar genom en sysadmins ögon

Först en liten utvikning i historien. HTTP-protokollet utvecklades i början av 90-talet (den så kallade "versionen 0.9"), och i mitten av 90-talet blev det Internets "killer app" - den som inte bara forskare och militär började ansluta till till Internet, men också "vanliga affärsmän och lekmän". Det finns därför ett behov av standardisering. I maj 1996 släpptes HTTP/1.0-specifikationen under det landmärke segernumret RFC:1945. Författarna till specifikationen har redan tagit hänsyn till Internets nya verklighet, inkl. behovet av protokollproxying för LAN. Dessutom har HTTP i praktiken funnits i mer än ett år och haft "erfarenhet av proxying". Därför har nödvändiga definitioner och kommentarer om fullmakter, gateways och tunnlar gjorts i dokumentet. Och i själva verket definierades inte bara själva HTTP-protokollet där (ur en vanlig webbservers synvinkel), utan även HTTP-proxy- och HTTPS-proxy-protokollen beskrevs. Metoden "CONNECT", som introducerades i HTTP-protokollet specifikt för att tillåta anslutning till säkra HTTP-servrar via en proxy, fick ändå inte begränsas till port 443, utan att ange vilken port som helst för anslutning. Så inför en HTTPS-proxy får vi ytterligare en "programmerbar TCP-mappning" för vilket protokoll som helst, om än med mycket mer begränsade möjligheter än Socks5. En HTTP-proxy är en helt annan sak för dess "native" HTTP-protokoll. Den kan behandla den med full kunskap om saken - cache, filtrera efter URL och innehåll, begränsa, dirigera, auktorisera, etc. Ofta kräver dessa åtgärder sådana icke-triviala åtgärder på nivån för TCP och andra OS-komponenter som är praktiskt taget omöjliga på NAT-paketnivå eller Socks blindmapping.

Det är samma sak med alla andra applikationsprotokoll för vilka det finns specialiserade proxyservrar - de är alltid en storleksordning mer hanterbara än generiska lågnivåer. Till exempel låter många POP3-proxyer dig filtrera spam, som PopFile (även om det är mycket mer korrekt att filtrera spam inte på proxyn, utan på SMTP-servern). Strumpor och NAT för detta skulle kräva speciella färdigheter för att förstå det överförda protokollet, d.v.s. faktiskt "emulering" av en POP3-proxy med hjälp av medel som inte är särskilt bekväma för detta.

Därför kan man överväga att använda Socks eller NAT för att arbeta med de protokoll för vilka det finns specialiserade proxyservrar (HTTP, HTTPS, FTP, SMTP, POP3, IMAP) eller den allmänt accepterade arkitekturen för mellanservrar (SMTP, POP3, IMAP, DNS). en påtvingad icke-optimal lösning. Tvingad - antingen från oförmågan att använda den önskade typen av proxy av organisatoriska skäl (det finns ingenstans att placera den önskade typen av proxy, eller anslutningstypen tillhandahåller inte närvaron av någon riktig IP-adress, vilket är fallet med Internet via GPRS eller hemnätverk alternativ - i dessa fall NAT eller "tvungen HTTP proxy" är redan på sidan av leverantören), eller från otillräcklig medvetenhet om ansvariga personer, inkl. administratörer. Jag tar inte hänsyn till ekonomiska begränsningar, eftersom det finns många alternativ för gratis eller mycket billiga proxyservrar för alla dessa protokoll.

I vissa fall är användningen av Socks5 ganska motiverad - till exempel för ICQ och andra budbärare. För dessa protokoll utvecklas helt enkelt inte speciella proxyservrar, eftersom de är nästan osynliga mot den allmänna bakgrunden av nätverksanvändning. Om det inte finns någon e-postserver eller pop3/smtp-proxy i LAN, kommer Socks5 också att vara nästa kandidat, även om inte alla e-postklienter stöder det, och vissa har icke-uppenbara funktioner (se Mozilla ThunderBird).

När du sorterar igenom alternativen kommer NAT att vara den "sista utvägen" - ifall inget bättre hittades, eller om NAT ställdes in av leverantören initialt - i ett kabelmodem, router, mobilanslutning(NAT är installerat i dessa järnbitar, och inte speciella proxyservrar för populära protokoll, på grund av den extrema enkelheten i dess grundläggande implementering: källkoden för liknande NAT UDPMAP-plugin i Eproxy har en storlek på endast 4Kb). Vissa av protokollen kommer inte att fungera, det blir svårt att hantera arbetet. Men i sådana extrema fall är det bättre att arbeta åtminstone på något sätt än att inte arbeta alls.

Här kommer en utförlig förklaring av min välkända ståndpunkt de senaste 8 åren - "Eserv kommer aldrig att ha NAT" I de allra flesta fall behöver du antingen inte NAT, eller så har du det redan som ett straff för att välja leverantör A , du kan använda den inbyggda Windows-anslutningsdelningen, det fungerar precis som NAT.

Se även "krycka" för NAT på Microsofts sajt: NAT-traversal - genomgång av NAT genom applikationsanpassning, NAT/Brandväggskonfiguration via UPnP. Om du hör frasen NAT-traversal för första gången beror det på att utvecklarna föredrar Socks5 istället för kryckor för patchar, och detta initiativ har inte fått "kodstöd". Men artikeln är bra för sina bilder (till skillnad från min och en annan oberoende beskrivning av NAT-problem.

NAT, ICS är redan inbyggt i alla nya versioner av Windows



I alla Windows-versioner släppt sedan 1999, NAT ingår. Först under namnet ICS (Internet Connection Sharing - anslutningsdelning), och senare under deras eget NAT-namn. Här är dialogrutan för att aktivera NAT i Windows 2003 (via "Routing och fjärråtkomst" system32rrasmgmt.msc).


I Windows XP är NAT/ICS aktiverat i Internetanslutningsegenskaperna.


Om du får meddelandet "Kan inte tillåta delning. Fel: 1722: RPC-servern är inte tillgänglig." ("Kan inte aktivera delad åtkomst. Fel: 1722: RPC-servern är inte tillgänglig."), då har du troligen stoppat eller inaktiverat DHCP-klienttjänsten, du måste starta den innan du aktiverar ICS.

NAT genom ögonen på en Linux-leverantör sysadmin

(Tillägg daterat 6 juli 2004 - första svaret på artikeln. Som i artikeln om FireWall, låt oss ge ordet till en riktig systemadministratör

Citat Om vi ​​jämför arbete genom NAT med verklig, så har jag hittills haft problem med NAT endast med röst-, video- och filöverföring i program som MSN Messenger. Kanske finns det i vissa NAT-implementationer även problem med aktiv ftp, anslutning till externa VPN-servrar etc., men när man arbetar genom NAT i Linux (med lämpliga inställningar) är det inga problem med detta. Fördelen med NAT i det här fallet är att spara IP-adresser och brandvägg.

Om vi ​​jämför NAT med en proxy (som ett sätt att komma åt Internet, d.v.s. omdirigeringsförfrågningar utan att ta hänsyn till funktionerna för cachning, URL-tolkning, etc.), så fungerar fler applikationer och protokoll genom NAT (alla); NAT kräver inga speciella inställningar från användarens sida; proxyn är mer krävande på hårdvaran. Proxies tillhandahåller vanligtvis inte Destination NAT (DNAT) funktionalitet, även om du i Eserve kan uppnå en partiell likhet med DNAT genom att använda tcp/udp-mappning. Slut på citat.

Det här citatet visar att leverantörer också har väldigt olika krav från administratörer i företag.

bakåtlänkar
Internetrouter, åtkomstserver, brandvägg. Den mest populära är Källa NAT(SNAT), essensen av mekanismen är att ersätta källadressen (källan) när paketet passerar i en riktning och omvänt ersätta destinationsadressen (destination) i svarspaketet. Tillsammans med käll-/destinationsadresserna kan käll- och destinationsportnumren också ersättas.

Förutom SNAT, d.v.s. förse användare av det lokala nätverket med interna adresser för att komma åt Internet, används ofta också Destination NAT, när förfrågningar utifrån sänds av brandväggen till en server på det lokala nätverket som har en intern adress och därför inte är direkt åtkomlig från det externa nätverket (utan NAT).

Figurerna nedan visar ett exempel på hur NAT-mekanismen fungerar.


Ris. 7.1.

Användare företagsnätverk skickar en förfrågan till Internet, som kommer kl internt gränssnitt router, åtkomstserver eller brandvägg (NAT-enhet).

NAT-enheten tar emot paketet och gör en post i anslutningsspårningstabellen som hanterar adressöversättning.

Den ersätter sedan källadressen för paketet med sin egen externa publika IP-adress och skickar paketet till sin destination på Internet.

Destinationsvärden tar emot paketet och skickar ett svar tillbaka till NAT-enheten.

NAT-enheten söker i sin tur, efter att ha tagit emot detta paket, upp avsändaren av originalpaketet i anslutningsspårningstabellen, ersätter IP-adress destination till motsvarande privata IP-adress och vidarebefordrar paketet till källdatorn. Eftersom NAT-enheten skickar paket på uppdrag av alla interna datorer ändrar den originalet nätverksport Och denna informationen lagras i anslutningsspårningstabellen.

Det finns tre grundläggande begrepp för adressöversättning:

  • statisk (SAT, statisk nätverksadressöversättning),
  • dynamisk (DAT, dynamisk adressöversättning),
  • maskerad (NAPT, NAT Overload, PAT).

Statisk NAT mappar lokala IP-adresser till specifika allmänna adresser på en-till-en-basis. Används när den lokala värden måste vara åtkomlig utifrån med hjälp av fasta adresser.

Dynamisk NAT mappar en uppsättning privata adresser till en uppsättning offentliga IP-adresser. Om antalet lokala värdar inte överstiger antalet tillgängliga allmänna adresser kommer varje lokal adress garanterat att matcha en offentlig adress. Annars kommer antalet värdar som samtidigt kan komma åt externa nätverk att begränsas av antalet publika adresser.

Maskerad NAT(NAPT, NAT Overload, PAT, maskerad) är en form av dynamisk NAT som mappar flera privata adresser till en enda offentlig IP-adress med hjälp av olika portar. Även känd som PAT (Port Address Translation).

Det kan finnas flera mekanismer för interaktion mellan ett internt lokalt nätverk och ett externt publikt nätverk – det beror på specifik uppgift för att ge tillgång till det externa nätet och vice versa och föreskrivs av vissa regler. 4 typer av nätverksadressöversättning definieras:

  • Full kon
  • Begränsad kon
  • Portbegränsad kon
  • Symmetrisk (symmetrisk)

I de tre första typerna av NAT används samma externa port för att kommunicera med olika IP-adresser i det externa nätverket med adresser från det lokala nätverket. Den fjärde typen - symmetrisk - använder en separat extern port för varje adress och port.

Full häst, är enhetens externa port (router, åtkomstserver, brandvägg) öppen för förfrågningar som kommer från vilken adress som helst. Om en användare från Internet behöver skicka ett paket till en klient som ligger bakom NAT, behöver han bara känna till den externa porten på enheten genom vilken anslutningen upprättas. Till exempel, en dator bakom en NAT med en IP-adress på 192.168.0.4 skickar och tar emot paket på port 8000 som mappar till den externa IP-adressen och porten som 10.1.1.1:12345. Paket från det externa nätverket anländer till enheten med IP-adress:port 10.1.1.1:12345 och skickas sedan till klientdatorn 192.168.0.4:8000.

I inkommande paket kontrolleras endast transportprotokollet; destinationsadress och port, källadress och port spelar ingen roll.

När du använder NAT fungerar det som Begränsad kon, den externa porten på enheten (router, åtkomstserver, brandvägg) är öppen för alla paket som skickas från klientdatorn, i vårt exempel: 192.168.0.4:8000. Och ett paket som kom från ett externt nätverk (till exempel från dator 172.16.0.5:4000) till en enhet med adress:port 10.1.1.1:12345 kommer att skickas till dator 192.168.0.4:8000 endast om 192.168.0.4:8000 tidigare skickat en begäran till IP-adressen för den externa värden (i vårt fall till datorn 172.16.0.5:4000). Det vill säga, routern kommer bara att vidarebefordra inkommande paket från en specifik källadress (i vårt fall är datorn 172.16.0.5:4000), men källportnumret kan vara vad som helst. Annars blockerar NAT paket som kommer från värdar som 192.168.0.4:8000 inte har skickat en begäran till.

NAT-mekanism Portbegränsad kon nästan lik NAT Restricted Cone-mekanismen. Endast i detta fall blockerar NAT alla paket som kommer från värdar till vilka klientdatorn 192.168.0.4:8000 inte skickade en begäran till någon IP-adress och port. Routern är uppmärksam på att matcha källportnumret och uppmärksammar inte källadressen. I vårt exempel kommer routern att vidarebefordra inkommande paket med valfri källadress, men källporten måste vara 4000. Om klienten skickade förfrågningar till det externa nätverket till flera IP-adresser och portar, då kommer de att kunna skicka paket till klienten på IP-adressen: port 10.1 .1.1:12345.

Symmetrisk NAT skiljer sig avsevärt från de tre första mekanismerna i hur den mappar en intern IP-adress:port till en extern adress:port. Denna mappning beror på IP-adress:porten på den dator som den skickade begäran är avsedd för. Till exempel, om en klientdator på 192.168.0.4:8000 skickar en begäran till dator #1 (172.16.0.5:4000), kan den visas som 10.1.1.1:12345, samtidigt om den skickar från samma port (192.168. 0.4:8000) till en annan IP-adress, visas den annorlunda (10.1.1.1:12346).

  • Låter dig förhindra eller begränsa extern åtkomst till interna värdar, vilket ger möjlighet till åtkomst från det interna nätverket till det externa. När en anslutning initieras från nätverket skapas en översättning. Svarspaket som kommer utifrån matchar den skapade översättningen och hoppas därför över. Om det inte finns någon motsvarande översättning för paket som kommer från det externa nätverket (och det kan skapas när anslutningen initierades eller statisk), hoppas de inte över.
  • Låter dig dölja vissa interna tjänster för interna värdar/servrar. I huvudsak utförs samma översättning som ovan på en specifik port, men det är möjligt att ersätta den interna porten för en officiellt registrerad tjänst (till exempel 80:e TCP-port(HTTP-server) till extern 54055th). Således, utanför, på den externa IP-adressen, efter adressöversättning till webbplatsen (eller forumet) för kunniga besökare, kommer det att vara möjligt att komma till adressen http://dlink.ru:54055 , men på den interna servern bakom NAT , det kommer att fungera på normal port 80.
  • Men nackdelarna med denna teknik bör också nämnas:

    1. Alla protokoll kan inte "överträffa" NAT. Vissa misslyckas med att fungera om det finns en adressöversättning på vägen mellan kommunicerande värdar. Dedikerade brandväggar som översätter IP-adresser kan rätta till denna brist genom att ersätta IP-adresser på lämpligt sätt, inte bara i IP-rubriker utan även på högre nivåer (till exempel i FTP-protokollkommandon).
    2. På grund av översättningen av många-till-en-adresser finns det ytterligare svårigheter med användaridentifiering och behovet av att lagra fullständiga översättningsloggar.
    3. DoS-attack av en NAT-värd - om NAT används för att ansluta många användare till samma tjänst kan detta ge illusionen av en DoS-attack på tjänsten (flera framgångar och misslyckanden). Till exempel leder ett för stort antal ICQ-användare bakom NAT till problem med att ansluta till servern för vissa användare på grund av att den tillåtna anslutningshastigheten överskrids.

    Om du upptäcker ett fel, välj en textbit och tryck på Ctrl + Retur
    DELA MED SIG: