Tror iaf svaret ligger i det GunnarD sa. Att moderna routrar lyssnar efter FTP-paket med kommandot PORT och öppnar sedan den port som anges.
Förklara denna FTP-session
33 svar · 971 visningar · startad av Gein · sida 2 av 2
Frågan, av Gein
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
Läs frågan i sin helhet →"bredbandsroutrar"/brandväggar cachar ingenting.
I TCP protokollet finns det definierat hur en session skall startas och avslutas och då vet brandväggen när den skall koppla ner, om det sedan kommer trafik mot den porten så stoppar brandväggen det.
Om man tittar på ftp protokollet i aktiv mode så sker följande:
- Klienten öppnar en tcp kanal mot port 21 från en slumpmässig hög port (N).
- Servern öppnar sedan en tcp kanal mot port N+1 från port 20
Det är i punkt 2, där servern försöker kontakta klienten, som en vanlig brandvägg spärrar om den inte känner av att man tidigare öppnat en kanal mot 21 på servern och använder ftp protokollet.
Nu vet jag inte vad du svarade på men huvuddiskussionen handlade om NAT och hur det hanteras när servern svarar. Enligt din teori stoppas alltså alltid allt vilket uppenbarligen inte sker :)
Grunfunktionen i NAT är att det finns en tabell/lista med anslutningar så routern vet vem som initierade vad. Om inte detta stämmer är även jag intresserad av att få en utförlig förklaring på hur detta fungerar :)
legis skrev:
Nu vet jag inte vad du svarade på men huvuddiskussionen handlade om NAT och hur det hanteras när servern svarar. Enligt din teori stoppas alltså alltid allt vilket uppenbarligen inte sker :)
Om inte brandväggen har en ftp-proxy så fungerar inte ftp igenom den.
legis skrev:
Grunfunktionen i NAT är att det finns en tabell/lista med anslutningar så routern vet vem som initierade vad. Om inte detta stämmer är även jag intresserad av att få en utförlig förklaring på hur detta fungerar :)
Detta stämmer för trafik innifrån till utsidan. Listan gäller bara trafil innifrån och ut.
För att en maskin på utsidan skall kunna initiera ett tcp koppel mot ex. en webserver på insidan så måste man öppna för den porten i brandväggen, gör man inte det så får man inget svar.
Problemet är att ftp-servern initierar minst en ytterligare tcp koppel mot klienten, det är denna som brandväggen stoppar om den inte vet om hur ftp protokollet fungerar, vet den hur ftp-protokollet fungerar så kommer brandväggen att dynamisk öppna för den porten så att servern kan initiera ett koppel mot klienten på insidan. Detta oavsett om man kör NAT/PAT eller ej.
Jo exakt men det är inte det som det hela handlar om. Att servern initierar en koppling tillbaka tar stopp även den OM nu inte routern vet om att den ska släppa igenom det OCH dessutom till vilken klient. Det är ju det vi diskuterar. ftp-proxy eller NAT-tabell spelar ingen roll här som jag skrev ovan. Funktionen/resultatet i sig blir detsamma.
Resten är saker man ser i tracen hur lätt som helst.
Med din förklaring så skulle alltså ALL FTP-trafik ALLTID släppas igenom. Jag får inte ihop den förklaringen.
legis skrev:
Med din förklaring så skulle alltså ALL FTP-trafik ALLTID släppas igenom. Jag får inte ihop den förklaringen.
Läs gärna igenom mina inlägg och fundera en stund.
Kruxet är när serverv försöker initiera datakanalen mot klienten.
Detta är precis som om man försökte köra mot ex. port 80 på brandväggen, är inte brandväggen konfigurerad att "portforwarda" den porten in mot klienten så stoppas den.
I ftp falllet där "bredbandsroutern"/brandväggen har en ftp-proxy så vet den att om en klientet försöker köra från port N till port 21 så skall den automatiskt "portforwarda" port N+1 i brandväggen in till klienten så att server kan initiera datakanalen.. När sedan klienten stänger ner controll-kanale så vet ftp-proxy att den kan ta bort den dynamiskt upplagda "portforwardingen" som den skapat.
Det är av denna anledning som "passive" mode har kommit till, där initierar klienten både controll- och data-kanale, vilket gör att brandväggen slipper ha en "ftp-proxy".
Läs gärna texten jag tidigare hänvisade till.
Det är detta jag sagt hela tiden men som du med bland annat följande kommentar inte hållt med om:
"bredbandsroutrar"/brandväggar cachar ingenting."
Det scenario vi diskuterar är klient på NAT som efterfrågar information från server på utsidan. Inte tvärtom. De scenariot är mycket lättare. Precis som jag tidigare sagt så blir det i pratiken samma resultat som om du gör en port forwarding men förutom i dina två senaste inlägg så har du dementerat att det finns information på routern som berättar vart paketen ska (se citat ovan).
Bra att vi äntligen är överens ;)
legis skrev:
Det är detta jag sagt hela tiden men som du med bland annat följande kommentar inte hållt med om:
"bredbandsroutrar"/brandväggar cachar ingenting."
Exact, ner servern försöker initiera kontakt med klienten så finns ingenting i cachen.
Det scenario vi diskuterar är klient på NAT som efterfrågar information från server på utsidan. Inte tvärtom. De scenariot är mycket lättare. Precis som jag tidigare sagt så blir det i pratiken samma resultat som om du gör en port forwarding men förutom i dina två senaste inlägg så har du dementerat att det finns information på routern som berättar vart paketen ska (se citat ovan).
Det jag försökt förklara är att ftp i "aktiv mode" så intiteras kontak även från server till klienten, däremot i "passive mode" initierar endast klienten kontakt.
Självklart är det enklare när endast klienten initierar kontakt, men just i ftp fallet så gör även servern det och det är detta som brandväggar har svårt med.
Känns som vi pratar om 2 olika saker.
Precis vad jag också kände så det är nog lika bra att lägga ner det. Får väl ta upp diskussionen om vi träffas irl nån gång ;)
Hmm, men om din dator säger åt servern (via routern) att skicka dig en fil på port 2554, så sparas denna session i routerns NATtabell, och då vet den visst vart paketen ska när servern sedan skickar filen. Eller? :-)
niklasw skrev:
Hmm, men om din dator säger åt servern (via routern) att skicka dig en fil på port 2554, så sparas denna session i routerns NATtabell, och då vet den visst vart paketen ska när servern sedan skickar filen. Eller? :-)
Nja.
Det som händer är att klienten kommer att lyssna på port 2554 och servern initierar en tcp-connection mot den vilket brandväggen stoppar OM den inte har en ftp-proxy som ligger och lyssnar på controlkanalen och fångar upp port kommandot och då dynamisk portforwardar den porten in till din dator.
Det kan också hända att port 2554 redan används på brandväggens WAN interface, då måste brandväggen ändra porten som servern skall koppla upp sig mot.. Förutsatt att man kör PAT (en public ip-adress)
Problemet med ftp protokollet är just att både klienten och server kan initiera tcp-sessioner (agera som "server")
Tja, en sista gång då. Trafiken måste fortfarande ta sig från router till klient och den kan inte genom magi lista ut vilken klient som ska ha paketet.
Såja, nu drar jag mig ur igen ;)
GunnarD, hur länge håller en brandvägg/router som har ftp-proxy en port öppen då den lyssnat av ett PORT-kommando?
Gein skrev:
GunnarD, hur länge håller en brandvägg/router som har ftp-proxy en port öppen då den lyssnat av ett PORT-kommando?
Lite osäker men gissar på att den väntar ett tag på att servern skall koppla upp sig, då borde den stänga porten när server kopplar ner sessionen, annars ligger det nog en timeout på porten (vild gissning).