Blir inte alls klok på detta scenario och hoppas någon kan förklara. Jag sitter just nu bakom en brandvägg (kör för tillfället delad 20mbit) och sedan har jag en egen router. Så min arbetsstation sitter således bakom ett NAT:at nätverk. Jag är klienten.
Servern sitter också den bakom ett NAT:at nätverk med portarna 20-21 öppnade.
Öppnade en anslutning med Total Commander, hämtade hem en fil och stängde sedan processen. Loggade alla paket med ethereal och så här såg det hela ut:
Min klient ansluter från port 2552 till port 21 på servern
Servern accepterar anslutningen. Användarnamn och lösenord tas emot och användaren accepteras för inloggning
Min klient använder kommandot PORT 192,168,0,102,9,250 för att säga till servern att ansluta till detta IP samt 2554 som portnummer för ftp-data
Min klient begär filen BBDRAG.MID
Servern skapar sedan en anslutning till mej på port 2554 från port 20 och skickar över filen
Min klient skickar kommando för att avsluta sessionen som sedan stängs ner
Hur kan en anslutning till mej på port 2554 öppnas? För det första borde brandväggen säga ifrån och om paketet ens kom in till min router så skulle den inte vidarebefodra pakektet då jag inte har öppnat en enda port till min arbetsstation. Försöker den inte ansluta till 192.168.0.102 eller vad använder den det IP:t till?
Varför syns inte det i ethereal då? Anslutningen initieras av servern inte av klienten. (Datakommunikationen ska dessutom initieras av servern enligt protokollet)
Nja. Själv brukar jag använda Network Monitor så jag kan inte riktigt tala för Ethereal, men min gissning är att den liksom Network Monitor bara visar till/från vilka portar som används. D.v.s. jag tror inte den egentligen visar att session initieras av servern, den använder bara den port som klienten har sagt att den vill kommunicera på.
Ethereal visar ju tid och detta avslöjar att det första TCP-paketet kommer från servern. Dessutom säger ju protokollet att dataanslutningen ska initieras av servern. Kan du förklara det?
red/ Styrker mitt påstående med hjälp av ett citat.
RFC0959 skrev:
The user-DTP or its designate should "listen" on
the specified data port, and the server initiate the data
connection and data transfer in accordance with the specified
parameters.
Jo, men servern använder den port som klienten har sagt att den vill använda. Därav har klienten denna port öppen. Kolla sekvenspaketen. Du kan följa ack'arna även i Ethereal misstänker jag.
Men hur kan paketen ta sig hela vägen fram? Klienten kan inte påverka hur routern ska bete sig. Även om klienten lyssnar på porten i fråga så vet inte routern om det.
Men routern har ju inte en aning om vart paketen ska? För det första har jag en brandvägg som inte jag styr över. Sedan har jag min router. Och jag har inte öppnat port 2554 till min dator, dvs, routern ska inte alls skicka trafiken vidare. Den vet ju inte ens vart trafiken ska!?
En router är inte så smart. Den låter bara trafiken passera. Din maskin svarar på det IP som paketet skickas till.
Din maskin är sedan tidigare redo att ta emot information på port 2554 eftersom den inititerat anslutningen och talat om för servern att det är den porten som ska användas. Det servern gör sen är helt enkelt bara att skicka informationen till det IP och den port den blivit tillsagd att skicka det.
Hur kan mitt IP stå i paketet? Antingen står mitt lokala IP i paketet och då skulle den inte ens komma fram till min router utan skulle vimsa runt i serverns lokala nätverk. Om det istället står mitt publika IP så kommer den visserligen till routern men sedan vet den inte vart den ska längre.
Min klient initierar inte anslutningen.. det är ju det som är grejen. Den använder anslutningen över port 21 för att berätta att port 2554 går bra att använda när data ska skickas. Men en anslutning över denna port görs ju inte föränn data ska skickas.
Hela idén med NAT är att som namnet säger Network Address Translation. Din router fördelar IP misstänker jag. Det är nätverkskortets MAC-adress som kopplas till IP't. På detta sätt så kan paketen hitta från din router till din klient. Jag ska se om jag kan förklara det nedan. Det blir säkert lite rörigt men jag tar risken ;)
Det är alltid ditt publika IP som används utanför ditt nät. Kortfattat kan man säga att vi abetar på två nivåer. Ethernet lokalt, vilket mappas mot MAC-adresser och sen IP utanför din router. Paketet från din maskin innehåller din MAC som source och sen interna adressen till din router som destination. På IP-nivå är dock destination ftp-serverns IP-adress.
Det är nu när paketet kommer till din router som NAT kommer igång. NAT håller reda på alla paket den översatt. Man kan säga att den har en liten lista över alla paket den paketerat om och skickat iväg med sig själv som souce. Paketet översätts till att innehålla din routers externa IP som source men den behåller ftpservern som destination. Vi rör oss nu på IP-nivå. Nu skickas paketet till ftpservern.
OM den port din klient sade att den vill använda är ledig hos routern så används den även från routern till ftpservern. Det är alltså inte säkert att samma port används på ditt interna nät som mellan din router och ftpservern.
När sen ftpservern skickar tillbaka informationen så kommer den tillbaka till din router. Din router ser att destinationen i paketet från ftpservern faktiskt är den själva och den börjar då kolla sin NAT. Den kollar paketet den fått mot den lista jag nämnde tidigare och jämför source, destination samt vilken port som användes. Den hittar då den request din klient skickat tidigare. Ett nytt paket byggs som skickas till din maskin. Ungefär i omvänd ordning som ovan.
Problemet är att ftp protokollet är så uppbygt att både klienten och servern kan initiera en koppling vilket en enkel filterlista stoppar.
Många "bredbandsroutrar"/brandväggar ligger därför och lyssnar av trafiken på "controll-kanalen" och öppnar dom portar som "port" kommandot anger, detta förutsätter att "bredbandsroutrar"/brandväggar vet om att det är ftp trafik på portarna.
Har en text som beskriver problemt ftp ihop med brandväggar här: "bredbandsroutrar"/brandväggar
Tack för era svar!
legis, jag är väl medveten om vad NAT är, hur det fungerar och hela den biten. Det jag inte förstod var hur servern kan initiera en anslutning på en port hos klienten när denna port inte är angiven i klientens router/brandvägg.
Ungefär samma tanke som:
Jag installerar en webbserver som lyssnar på port 80 och bara med hjälp av det så skulle klienter kunna initiera en anslutning till denna webbserver utan att jag har konfigurerat routern på något sätt. Detta går givetvis inte och av samma skäl tycker jag det borde bli problem med min session.
Men det är nog isåfall som GunnarD säger att det finns någon form av intelligens i routrarna då dom lyssnar på kontrollkanalen. GunnarD, jag ser ingen länk till texten du hänvisar till. Vart hittar jag den?
Nja kanske jag som tänker helt fel men jag ser inget konstigt i det. Det är ju inte så att den hittar på något helt på egen hand direkt som i ditt exempel. Det finns en cache/lista i routern på trafiken. Finns det inget där så droppas paketen.
Nätverkstracen borde kunna tala om exakt hur det hela går till. Source och destination finns lagrat hela vägen. Om du vill kan du skicka tracen så kan jag utifrån den försöka förklara om du vill.
Det var bland annat därför jag frågade om du i din router stoppar inkommande trafik på den port din klient initierade anslutningen. FTP-proxybiten är instressant men i sig inte annorlunda än hur NAT fungerar. Borde synas i tracen.
Ponera följande scenario: Jag har en router hemma och därmed ett NAT:at nätverk då jag bara har en publik IP-adress och flera datorer bakom routern. Jag sätter upp en webbserver på en av datorerna som sedan börjar lyssna på inkommande trafik, port 80. Routern är inte på något sätt konfigurerad att vidarebefodra specifik trafik till vissa datorer. En klient gör en webbförfrågan mot min publika IP-adress. Anropet kommer aldrig gå längre än till routern som inte har en susning om vem som bör ta denna förfråga. Routern släpper paketet.
Är vi överens så långt?
Ja, eller som jag ser det, anslutningen initieras från klienten och anropet kan aldrig komma igenom routern. Men det är samma sak som det du menar.
Så, det är ingen egentligen skillnad mellan det scenario jag precis skrev och det jag tog upp i början.
En anslutning görs från klienten (jag, bakom NAT) till servern (också bakom sitt NAT). Klienten säger till servern, Hej, jag tänker strax efterfråga en fil och när du skickar den så kan du ansluta till port N, där jag väntar på filen. Observera att ingen trafik ännu har strömmat över port N och routern har således inte cachat någonting. Klienten säger till servern Nu vill jag ha filen abc.xyz (fortfarande över samma anslutning som skapades från början) och i samma stund görs ett nytt anrop från servern till klienten på port N.
Således helt analogt med ett webbanrop som jag beskrev i scenariot med en webbserver bakom NAT.
