Vista ødelægger DNS round-robin ved at følge standarden

Metoden virker fint ved IPv6, hvor alle maskiner har deres eget globale IP.

Ved IPv4 er NAT den mest gængse metode, er derved den IP adresse du har, er en internt IP.

Så det er ikke metoden der er noget galt med, det er implementeringen af metoden i IPv4.

Dem der har lavet standarten er da bare nogen hatte, at de ved IPv4 har valgt at bruge den lokale ip, på dem som er bag NAT.

To spørgsmål:
1) Betyder Round Robin ikke, at man tager serverne en for en, altså man får tildelt den næste server på listen og ikke en tilfældig?

2) Ip-nummer 192.168 er vel kun gældende i det lokale netværk, såvidt jeg forstår. Klistres der ikke en wrapper udenom pakken, sådan at serveren ikke kan se 192.168-adressen men IP-adressen på ydersiden af den router, man er koblet på? Dermed angiver adressen, hvor routeren står geografisk, og så findes problemet vel ikke.

#3

1. http://en.wikipedia.org/wiki/Round_robin_DNS

2. Det hele sker lokalt, så det er din lokale IP der bliver brugt. Ellers skulle windows ud og finde ud af hvad IP du har eksternt, og det kan den ikke.

#4
Ad 1)
Fra wikipedia:
"With each DNS response, the IP address sequence in the list is permuted. Usually, basic IP clients attempt connections with the first address returned from a DNS query so that on different connection attempts clients would receive service from different providers, thus distributing the overall load among servers."

Det er jo netop Round Robin, at man permuterer listen (roterer) og vælger fra toppen.

Nyheden her på newz skriver "hvor browseren får en liste over servere, hvorefter den vælger en tilfældig.". Det er jo i modstrid med det, wikipedia siger. Hvis man vælger en tilfældig fra listen, så er permuteringen af listen jo omsonst.

Ad 2)
Ah ja, det er den lokale browser, der vælger hosten, og denne ved ikke, hvor i verden, den står. Tak.

TuxDK (1) skrev:

Metoden virker fint ved IPv6, hvor alle maskiner har deres eget globale IP.

Vil det sige at hvis man udelukkende kører IPv6, så har samtlige computere en unik, global IP-adresse?

Hvad så med LAN adresser? Er det begreb bare forsvundet i IPv6?

#6: Nej, selvfølgeligt er lan-adresser da ikke bare forsvundet. Og man kan jo stadigvæk bruge ipv4 lokalt hvis man ønsker.

TuxDK's pointe er blot, at man med ipv6 har rigeligt adresser til at give alle maskiner en unik adresse, og at man derfor ikke behøver bruge nat af plads-hensyn.

#6

IPv6 vil fjerne behovet for NAT totalt.
Du smider jo stadig firewalls, etc foran dit net, saa selvom du har en global IP, saa vil der ikke vaere adgang til den udefra.

Man kan aldrig præcist afgøre hvad der er den nærmeste server bare ved at kigge på det længste prefix.

I stedet for at lægge funktionalitet som denne i klienten kunne en ISP også have et system hvor deres DNS servere modtager oplysninger fra BGP routerne så de rent faktisk kan regne ud hvad der er nærmest. Problemet er så bare, hvordan man skal kommunikere det ud til klienterne.

Hvis man kører et site med mange servere, så kan man lave sin egen loadbalancing i stedet for at basere sig på opførslen af andre folks DNS servere. Man kan f.eks. lade være med at give klienterne en liste af alle serverne, men kun dem der er forholdsvis tæt på. Man vil selvfølgelig kun kende lokaliteten af brugerens DNS server, så det vil kun virke så længe man bruger en DNS server i nærheden af sig selv. Hvis man vælger at sætte sin computer i Danmark op til at bruge en DNS server i USA, så vil det gå langsommere ikke blot fordi DNS opslagene i sig selv er langsomme, men også fordi man vil blive sendt til servere, der er tættere på ens DNS server.

TuxDK (1) skrev:

Metoden virker fint ved IPv6, hvor alle maskiner har deres eget globale IP.

Nej, der vil også være situationer med IPv6 hvor længste fælles prefix ikke giver den nærmeste maskine. (Et eller andet sted på nettet må der være en direkte forbindelse mellem to maskiner hvor den mest betydende bit er forskellig, og de to maskiner som er direkte forbundne vil så betragte afstanden imellem hinanden som værende større end afstanden til ca. halvdelen af nettet).

Xill (2) skrev:

Dem der har lavet standarten er da bare nogen hatte

Fint. Så lad os skyde skylden på dem der har lavet standarden i stedet for dem der har implementeret Vista. Det viser sig at det også er Microsoft.

at de ved IPv4 har valgt at bruge den lokale ip, på dem som er bag NAT.

Kun hvis man ikke har noget andet valg. Længden af det fælles prefix bliver brugt som den niende regel på listen, og altså kun hvis ingen af de foregående otte regler har afgjort hvilken adresse der skal bruges.

I øvrigt står der i standarden at man kan ignorere regel nummer ni og ti hvis man har en bedre måde at vælge på.

Izaaq (3) skrev:

To spørgsmål:
1) Betyder Round Robin ikke, at man tager serverne en for en, altså man får tildelt den næste server på listen og ikke en tilfældig?

Jo, det er den egentlige betydning. I praksis kan man ikke helt lave round robin med DNS. Der er tale om mange servere og klienter, hvor hver enkelt kan cache data. Den oprindelige server har altså ingen idé om, hvor mange klienter der rent faktisk ender med at gøre brug af hver enkelt opslag. (Og den oprindelige server er faktisk ikke en enkelt server, men to eller flere servere, som kender de samme adresser, men kører uafhængigt og ikke kender hinandens svar). De forskellige servere i systemet behøver heller ikke være samme implementation, det kan sagtens tænkes at nogen bruger en tilfældig rækkefølge og andre cyckler igennem adresserne.

Hvis der er nok klienter vil en tilfældig rækkefølge give en god fordeling. Og hvis man selv anvender en tilfældig rækkefølge er man mindre sårbar overfor uheldige samvirkninger med opførslen af andre servere i systemet.

2) Ip-nummer 192.168 er vel kun gældende i det lokale netværk, såvidt jeg forstår. Klistres der ikke en wrapper udenom pakken, sådan at serveren ikke kan se 192.168-adressen men IP-adressen på ydersiden af den router, man er koblet på?

Hvis der bare vare en wrapper udenom (det man normalt kalder for en tunnel), så ville serveren jo netop kunne se adressen. Men NAT fungerer derimod ved at erstatte adressen, så serveren ikke vil se den lokale adresse.

Dermed angiver adressen, hvor routeren står geografisk, og så findes problemet vel ikke.

DNS serveren afleverer ikke kun en enkelt adresse som svar på en forespørgsel. Den afleverer en liste, som klienten kan afprøve en ad gangen. Det er klienten der i sidste ende afgører rækkefølgen. Når listen når frem til klienten er de i en tilfældig rækkefølge for at fordele belastningen jævnt over serverne. Men hvis klienterne sorterer dem, og anvender samme kriterie, så vil belastningen ikke længere være jævn.

Angelenglen (6) skrev:

Vil det sige at hvis man udelukkende kører IPv6, så har samtlige computere en unik, global IP-adresse?

Ja, det er formålet.

Hvad så med LAN adresser? Er det begreb bare forsvundet i IPv6?

De findes stadig, men der er ingen grund til at bruge dem. Oversættelse af adresser, som det gøres af NAT routere, har mange ulemper, så det er en god ting at slippe af med.

#6

Ja, mere eller mindre.
Som andre også allerede har sagt, er der ikke behov for NAT med IPv6, og alle maskiner og enheder, har deres eget unikke IPv6, som så bliver routed, ligesom IpV4 gjorde det (bare med andre metoder jo).

Kan ikke huske anekdoten, men der er flere tusinde IPv6 adresser per kvadratmeter på jordens overflade. Gider ikke lige finde det præcise tal :)

DNS Round Robin er også noget forbandet hø hvis man har brug for loadbalancing.
Det er billigt og nemt at sætte 2 maskiner op med Linux og lave loadbalancing + redundans(med heartbeat).

Du ved aldrig hvem der cacher hvad og hvor længe og nogle ISP har haft for vane sommetider TTL værdier man har sat på deres DNS servere(hej cybercity). Så man kan sætte TTL ned så meget man vil i god tid i forbindelse med en IP flytning.

Derfor er det fedeste at have en fast IP man bruger med en loadbalancer foran og så kan man ellers kaste rundt med trafikken som man lyster. Og som jeg nævner behøver det ikke være besværligt eller dyrt at lave endda med komplet redundans.

#11 Offtopic.

og nogle ISP har haft for vane sommetider TTL værdier man har sat på deres DNS servere(hej cybercity)

Que?
Spellcheck! >.<

Men ja, Round-Robin er nok den daarligste form for "redundans" man kan lave -.-

LAN IP'er i IPv6 hedder "Link-Local", og kan bruges flere steder i et netværk. Problemet er så, at sørge for at router protokoller ved, at de skal snakke med hverandre på disse local-only netværk. Disse netværk skal så, af router-protokollen, fjernes fra at blive sendt rundt med router protokollen.
De ligger i området FE80::0/10, mindes jeg.
Kilde.

#6,13

Link local adresser svarer til de 169.254.0.0/16 adresser man får i IPv4 hvis man ikke kan kontakte en DHCP server. Det er altså adresser der autokonfigureres. Disse hedder helt korrekt fe80::/10.

Derudover findes der også Unique local adresser, der hedder fc00::/7. De erstatter de tidligere site-local adresser. Forskellen er, at hvor site local adresser mindede meget om de private IP adresser vi kender fra IPv4 (fx 192.168.1.0/24), så er unique local adresser (med stor sandsynlighed) globalt unikke. Dette sker ved at generere et 40 bit tilfældigt tal for hvert site der benytter dem. Fordelen ved dette, er at hvis man fx sammenlægger to afdelinger i en virksomhed, så bliver der ikke konflikter mellem adresserne (flere har nok prøvet at lægge to afdelinger sammen, der begge kørte med 192.168.1.0/24 IPv4 adresser). Det er disse adresser man bruger til at lave private netværk, da de ikke må routes på internettet.

Derudover er der så de global adresser, der routes på internettet.

I modsætning til de fleste IPv4 setup, så har et IPv6 interface flere adresser. Det har fx altid en link local adresse, men kan også samtidigt have både en eller flere unique local, samt global adresser.

Det ser ud til at MS igen bare har kopieret linux - eller inplenteret samme rfc i hvert fald. Debian er langt foran Vista når det gælder denne her fejl i hvert fald.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=4...

fidomuh (8) skrev:

#6
IPv6 vil fjerne behovet for NAT totalt.
Du smider jo stadig firewalls, etc foran dit net, saa selvom du har en global IP, saa vil der ikke vaere adgang til den udefra.

Det lyder lækkert, men jeg tror dog ikke behovet for NAT forsvinder fra private forbindelser, da jeg let kan forestille mig at ISP'erne ikke bare tildeler private IP'er i flæng, selvom der er "uendeligt" mange IPv6 IP'er tilgængeligt.
Og hvis de fortsat kun tildeler private forbindelser én adresse, så er NAT et must, i hvert fald for folk som mig :-)

Men for virksomheder kan jeg let se at det bliver unødvendigt med NAT.

Trogdor (11) skrev:

DNS Round Robin er også noget forbandet hø hvis man har brug for loadbalancing.
Det er billigt og nemt at sætte 2 maskiner op med Linux og lave loadbalancing + redundans(med heartbeat).

Det er endnu nemmere at sætte to uafhængige maskiner op og lade DNS resolve til begge navne. Hvis du vil have to maskiner til at overtage hinandens IP adresser i tilfælde af fejl er de jo nødt til at være på samme lokalnet, hvilket øger risikoen for at begge forsvinder fra nettet på samme tid.

Den ene løsning er nok bedre til load balancing og den anden er bedre til at opnå redundans. Men selvfølgelig er det ikke optimalt at være afhængig af at klienterne prøver en anden IP hvis den første fejler. Det ville være bedre hvis man hurtigt kunne fjerne den fejlede IP fra DNS opslag.

Du ved aldrig hvem der cacher hvad og hvor længe og nogle ISP har haft for vane sommetider TTL værdier man har sat på deres DNS servere(hej cybercity). Så man kan sætte TTL ned så meget man vil i god tid i forbindelse med en IP flytning.

Det er nu engang et problem man må leve med hvis man vil drive en server der skal kunne tilgås af mange forskellige mennesker. Cybercity er ikke alene om den synd. Man kan undre sig over hvorfor de gør det, for det lyder jo som om deres kunder må få en oplevelse af en mindre stabil netforbindelse på den måde. Det kan i nogle tilfælde være en god idé at cache adressen ud over TTL og så kun bruge den i tilfælde af at DNS serverne for domænet fejler. Men når TTL er udløbet skal man da i det mindste forsøge på at slå den op igen.

Derfor er det fedeste at have en fast IP man bruger med en loadbalancer foran og så kan man ellers kaste rundt med trafikken som man lyster. Og som jeg nævner behøver det ikke være besværligt eller dyrt at lave endda med komplet redundans.

Hvis IP adressen er bundet til en lokalitet er det af begrænset værdi. Det kan selvfølgelig hjælpe hvis man er nødt til at udføre nogle tunge beregninger for hver request. Men drejer det sig om redundans og at få spredt trafikken over forskellige forbindelser, er det af begrænset værdi.

Carceri (14) skrev:

Derudover findes der også Unique local adresser, der hedder fc00::/7. De erstatter de tidligere site-local adresser. Forskellen er, at hvor site local adresser mindede meget om de private IP adresser vi kender fra IPv4 (fx 192.168.1.0/24), så er unique local adresser (med stor sandsynlighed) globalt unikke. Dette sker ved at generere et 40 bit tilfældigt tal for hvert site der benytter dem. Fordelen ved dette, er at hvis man fx sammenlægger to afdelinger i en virksomhed, så bliver der ikke konflikter mellem adresserne (flere har nok prøvet at lægge to afdelinger sammen, der begge kørte med 192.168.1.0/24 IPv4 adresser). Det er disse adresser man bruger til at lave private netværk, da de ikke må routes på internettet.

Det lyder alt sammen korrekt, men jeg har endnu ikke forstået idéen i site local adresser. Hvorfor tager man ikke bare en lille del af de adresser man har som allerede er garanteret at være globalt unikke og så bare lader være med at route dem? Selvfølgelig er 40 bits godt nok til at undgå kollisioner i langt de fleste tilfælde (Det er sjældent man fusionerer en million virksomheder), men er det ikke bedre at være garanteret unikke adresser, og have muligheden for at route dem hvis man engang i fremtiden finder et behov for det?

Angelenglen (16) skrev:

Det lyder lækkert, men jeg tror dog ikke behovet for NAT forsvinder fra private forbindelser, da jeg let kan forestille mig at ISP'erne ikke bare tildeler private IP'er i flæng, selvom der er "uendeligt" mange IPv6 IP'er tilgængeligt.
Og hvis de fortsat kun tildeler private forbindelser én adresse, så er NAT et must, i hvert fald for folk som mig :-)

Hvis jeg har forstået det ret, så er det meningen at din udbyder skal tildele dig et /48 interval af IPv6 adresser. Det betyder at du kan opdele dit lokalnet i op til 65536 segmenter og putte 18 trillioner maskiner på hvert segment.

Jeg ved ikke hvad der er gjort for at sikre, at din udbyder giver dig de IPv6 adresser du har krav på.

michael007dk (15) skrev:

Det ser ud til at MS igen bare har kopieret linux - eller inplenteret samme rfc i hvert fald. Debian er langt foran Vista når det gælder denne her fejl i hvert fald.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=4...

Jesus, nu kan de ikke engang implementere en standard uden at kopiere fra andre?????

#16

Det lyder lækkert, men jeg tror dog ikke behovet for NAT forsvinder fra private forbindelser, da jeg let kan forestille mig at ISP'erne ikke bare tildeler private IP'er i flæng, selvom der er "uendeligt" mange IPv6 IP'er tilgængeligt.

Sidst jeg tjekkede kunne alle og enhver faa en /48 .. :)

Og hvis de fortsat kun tildeler private forbindelser én adresse, så er NAT et must, i hvert fald for folk som mig :-)

Men det er der ingen grund til at goere.
Som skrevet tidligere saa er der mange, mange, mange, ip'er pr kvm paa jorden :)

Men for virksomheder kan jeg let se at det bliver unødvendigt med NAT.

Faktisk vil jeg tro at mange virksomheder vil bruge NAT anyway, om ikke andet saa for at skjule interne ip'er.. MEn saa kan man jo blot bruge proxy istedet :)

#18

OMG! THEY ARE STEALING CODE! BAD MS! :D

fidomuh (19) skrev:

Faktisk vil jeg tro at mange virksomheder vil bruge NAT anyway, om ikke andet saa for at skjule interne ip'er.. MEn saa kan man jo blot bruge proxy istedet :)

Begge dele har ulemper. Der kræver en maskine som skal bevare tilstand om åbne forbindelser. Denne maskine kan fejle eller løbe tør for resourcer, og så virker tingene ikke mere som de burde. Desuden er er ting som bare ikke virker gennem NAT og proxies.

En bedre løsning, hvis man blot er interesseret i at hemmeligholde interne IP adresser, er at anvende midlertidige IP adresser til den kommunikation hvor man ønsker at holde adresserne hemmelige.

#19:

Som skrevet tidligere saa er der mange, mange, mange, ip'er pr kvm paa jorden :)

Husk at IPv6 er en standard der skal holde lang tid ud i fremtiden. Og selv om der er masser af IP'er så skal man huske at flere og flere (specielt i løbet af de kommende år) enheder vil blive koblet på nettet. De har alle brug for IPer.

jeg laver mobil software til dagligt og jeg tror ikke vi skal kigge ret langt ud i fremtiden før end vores mobil telefoni bliver IPbaseret. Og SÅ skal der rigtigt mange IPer til. - Og det ville da være surt at løbe tør igen om 10 år.

Så jeg tror godt du kan regne med at ISPerne vil holde dem tæt ind til kroppen og ikke dele dem ud for fornøjelsens skyld.

#22

Der er vidst heller ingen fare for at vi løber tør efter 10 år..

en.wikipedia.org/wiki/IPv6 skrev:

The very large IPv6 address space supports a total of 2128 (about 3.4×1038) addresses—or approximately 5×1028 (roughly 295) addresses for each of the roughly 6.5 billion (6.5×109) people alive in 2006.[9] In a different perspective, this is 252 addresses for every observable star in the known universe

Så ISP'erne kan roligt være rundhåndet med IP'er.

#22

Så jeg tror godt du kan regne med at ISPerne vil holde dem tæt ind til kroppen og ikke dele dem ud for fornøjelsens skyld.

RIPE uddeler en /48 i IPv6 til stort set alle der bare vifter lidt med fingeren..
Det er vel ligegodt 65536 IP'er, saa medmindre du har mobiltelefoner "up the ying-yang", saa gaar det nu nok :)

#21

Der kræver en maskine som skal bevare tilstand om åbne forbindelser. Denne maskine kan fejle eller løbe tør for resourcer, og så virker tingene ikke mere som de burde.

Ja, ofc.
MEn det er klart at foretraekke fremfor at have hvert klient-OS direkte paa nettet.

Desuden er er ting som bare ikke virker gennem NAT og proxies.

Saasom?
Umiddelbart har jeg ikke brugt een eneste ting paa mit arbejde, som ikke virker igennem en TCP proxy, eller et knudepunkt af en art :)

En bedre løsning, hvis man blot er interesseret i at hemmeligholde interne IP adresser, er at anvende midlertidige IP adresser til den kommunikation hvor man ønsker at holde adresserne hemmelige.

Eh? Hvordan har du taenkt dig at goere det?
Du vil altsaa skifte IP'er internt?

Det handler jo ikke som saadan om at holde adresserne hemmelige, men mere om at soerge for at klient maskiner ikke er et stort sikkerhedshul ;)

Hvis du vil bruge "andre" ip'er til "noget" kommunikation, saa kommer du da ud paa et skraaplan anyway :)

#21

Jeg kan ikke umiddelbart tænke mig til hvad der ikke virker i et NAT og hvorfor du skal huske tilstande.

Lad os sige du har en firewall der natter en ekstern addresse ind imod en privat addresse, så gør den jo ikke andet end at natte indgående trafik så det har den interne addresse som modtager addresse og udgående trafik så det har den eksterne som afsendelses addresse, jeg kan ikke helt se hvor du skal huske tilstandsinformation henne, det vil jeg umiddelbart sige ligger i trafikken.

Det eneste tilfælde jeg lige kan tænke mig til, hvor du skal huske tilstandinformation er hvis du har flere interne addresser der sender trafik ud på de samme portnumre.

fidomuh (24) skrev:

RIPE uddeler en /48 i IPv6 til stort set alle der bare vifter lidt med fingeren..
Det er vel ligegodt 65536 IP'er

Helt præcist 1208925819614629174706176, men det er vel også lige godt 65536.

MEn det er klart at foretraekke fremfor at have hvert klient-OS direkte paa nettet.

Hvad mener du med direkte paa nettet? (Og hvad mener du med hvert klient-OS for den sags skyld?)

Sikkerhedsmæssigt er der ingen fordel ved at bruge NAT. Hvis du har lyst til at filtrere trafikken kan du gøre det nøjagtigt på samme måde som du ville have gjort det uden NAT, eller du kan gøre det lidt simplere og undgå at skulle lave tilstandsbaseret filtrering.

Umiddelbart har jeg ikke brugt een eneste ting paa mit arbejde, som ikke virker igennem en TCP proxy, eller et knudepunkt af en art :)

På mit arbejde bruger jeg ikke NAT ret meget. Det meste af den kommunikation jeg foretager er indenfor vores eget netværk. Meget af den kommunikation foregår imellem forskellige netsegmenter med pakkefiltre imellem dem, men ingen translation. Det eneste tilfælde hvor jeg kommer i forbindelse med NAT er hvis jeg henter eksterne websider eller kører ssh forbindelser til eksterne ssh servere, og det er nogle af de ting som fungerer gennem NAT.

Til gengæld bruger jeg tit http proxies, men ikke alt fungerer igennem dem. For eksempel kan man ikke umiddelbart køre ssh eller videoconference gennem en http proxy.

Privat er der flere ting jeg gerne ville gøre, men som ikke fungerer fornuftigt med NAT. F.eks. er IP telefoni gennem NAT problematisk. Jeg kan ikke ssh direkte til en maskine bagved NAT, jeg kan heller ikke køre HTTP eller SMTP trafik direkte til en maskine bagved NAT. Og endeligt er der problemet med tilstand gemt af NAT enheden. Den tilstand forsvinder hvis der går for lang tid uden aktivitet, eller enheden bliver genstartet.

Desuden er der problemer med bittorrent fordi maskiner ikke kan connecte direkte til hinanden. Og alt der bruger IP adresser i kommunikationen (andre steder end blot i pakkernes source og destination), vil have problemer.

Eh? Hvordan har du taenkt dig at goere det?
Du vil altsaa skifte IP'er internt?

Der står lidt om det i RFC 3041, jeg kan ikke huske om det hele står der, eller om der er flere RFCer. En maskine kan tildeles to IPv6 adresser, en fast baseret på MAC adressen, og en midlertidig tilfældig som kan bruges til f.eks. webbrowsing.

Det handler jo ikke som saadan om at holde adresserne hemmelige, men mere om at soerge for at klient maskiner ikke er et stort sikkerhedshul ;)

Det var dig der begyndte at snakke om at skjule IP adresser. Det eneste man kan opnå ved det er en lille smule anonymitet. Sikkerhedsmæssigt er der ingen grund til at skjule adresser.

Hvis du vil bruge "andre" ip'er til "noget" kommunikation, saa kommer du da ud paa et skraaplan anyway :)

Nej, hvis det hele foregår på klientmaskinen er det ikke noget problem. Så længe det kun er de to endepunkter for kommunikationen, der skal opbevare tilstand, fungerer ting som regel. Det er først når enheder derimellem skal opbevare tilstand, at der er problemer.

#26

Helt præcist 1208925819614629174706176, men det er vel også lige godt 65536.

*host* det er da klart det samme :P

Hvad mener du med direkte paa nettet? (Og hvad mener du med hvert klient-OS for den sags skyld?)

At der skal et knudepunkt imellem af en art.
Fx en Firewall.

Sikkerhedsmæssigt er der ingen fordel ved at bruge NAT.

Naeh, derfor smider man en firewall paa.

Hvis du har lyst til at filtrere trafikken kan du gøre det nøjagtigt på samme måde som du ville have gjort det uden NAT, eller du kan gøre det lidt simplere og undgå at skulle lave tilstandsbaseret filtrering.

Mjaeh, firewalls.

Det eneste tilfælde hvor jeg kommer i forbindelse med NAT er hvis jeg henter eksterne websider eller kører ssh forbindelser til eksterne ssh servere, og det er nogle af de ting som fungerer gennem NAT.

Generelt alt traffik du sender ud paa internettet, ja.
Eller alt traffik der proever at komme ind til dig :)

Til gengæld bruger jeg tit http proxies, men ikke alt fungerer igennem dem. For eksempel kan man ikke umiddelbart køre ssh eller videoconference gennem en http proxy.

...?
Jo, det kan du godt.

Og jeg snakker ikke om en "http proxy" ( Que? ), men om en "proxy".
Fx en TCP proxy.
Eller en SSH proxy.

Privat er der flere ting jeg gerne ville gøre, men som ikke fungerer fornuftigt med NAT. F.eks. er IP telefoni gennem NAT problematisk.

Alle telefonsystemer idag koerer igennem en PBX af en art, saa det er ikke noget stoerre problem.

Jeg kan ikke ssh direkte til en maskine bagved NAT, jeg kan heller ikke køre HTTP eller SMTP trafik direkte til en maskine bagved NAT.

Yes, det samme vil ske med IPv6, da man saa bruger firewalls.
Jeg kan ikke se fordelen i at have klient maskiner direkte paa nettet.

Og endeligt er der problemet med tilstand gemt af NAT enheden. Den tilstand forsvinder hvis der går for lang tid uden aktivitet, eller enheden bliver genstartet.

Jeg forstaar ikke helt, det problem sker ikke med firewalls, eller?
NAT regler fungerer paa samme maade som firewall regler, more or less.

Desuden er der problemer med bittorrent fordi maskiner ikke kan connecte direkte til hinanden. Og alt der bruger IP adresser i kommunikationen (andre steder end blot i pakkernes source og destination), vil have problemer.

Ja.
Det er ikke saa interessant for firmaer vil jeg vove at paastaa.

Der står lidt om det i RFC 3041, jeg kan ikke huske om det hele står der, eller om der er flere RFCer. En maskine kan tildeles to IPv6 adresser, en fast baseret på MAC adressen, og en midlertidig tilfældig som kan bruges til f.eks. webbrowsing.

Ah nice, det vidste jeg faktisk ikke :)

Det var dig der begyndte at snakke om at skjule IP adresser. Det eneste man kan opnå ved det er en lille smule anonymitet. Sikkerhedsmæssigt er der ingen grund til at skjule adresser.

Tjah, umiddelbart ved man ikke hvilken IP klient maskinen har og kan kun hive fat i firewall'en.
Som jeg skrev kan man snildt goere det igennem en proxy :)

Men jeg tror faktisk vi er rimeligt enige, som jeg hele tiden har sagt, saa er NAT ikke saerligt brugbart med IPv6, da alle de ting man ville bruge NAT til, kan loeses af firewalls og proxyer.

#26

NAT bliver først et problem når der ikke er et 1:1 forhold imellem offentlige og private addresser. (eller rettere, et 1:1 forhold imellem portene)

Hvis du bare vil skjule en intern IP bag en offentlig addresse har du ingen af de problemer du omtaler.

Årsagen til at bruge NAT på den måde, er at du frit kan linke dine interne addresser sammen med dine eksterne som du har lyst til, uden at ændre dine interne addresser.

fidomuh (27) skrev:

At der skal et knudepunkt imellem af en art.
Fx en Firewall.

Et normalt knudepunkt på internettet er en router (eller en samling af routere og switches). Firewalls derimod er normalt ikke i internettets knudepunkter, men derimod på kanten.

fidomuh (27) skrev:

Til gengæld bruger jeg tit http proxies, men ikke alt fungerer igennem dem. For eksempel kan man ikke umiddelbart køre ssh eller videoconference gennem en http proxy.

...?
Jo, det kan du godt.

Og jeg snakker ikke om en "http proxy" ( Que? ), men om en "proxy".
Fx en TCP proxy.
Eller en SSH proxy.

Når der snakkes om proxy er der normalt tale om en http proxy, og i sjældnere tilfælde en socks proxy. Jeg kender ingen http proxy der tillader ssh i default configurationen. Det kan lade sig gøre at sætte det op, men det er lidt besværligt, specielt når man skal fejlfinde fordi det ikker virker.

Under alle omstændigheder er det upraktisk at skulle have forskellige typer proxies sat op for hver type trafik. Det er ikke sådan internettet er designet til at skulle fungere, transportlaget skal være så uafhængig af den overliggende protokol som muligt. Desuden virker det kun for TCP forbindelser, jeg har endnu ikke set en proxy der kunne håndtere UDP eller andre protokoller.

Endeligt kræver det proxy support i hver eneste applikation. Ikke alle applikationer understøter proxies.

Forresten tror jeg ikke der findes nogen decideret ssh proxy. Den eneste proxy support der er i openssh klienten er muligheden for at kalde et eksternt program, der håndterer alt kommunikationen. Det er selvfølgelig meget fleksibelt, men det kræver altså at sådanne eksterne programmer skal skrives for hvert type proxy man ønsker at bruge.

Uanset hvordan man vender og drejer det, så er det større arbejde at sætte noget op der kan fungere med proxies end bare at have IP trafik mellem de to endepunkter og et passende sæt filtre på routere derimellem.

fidomuh (27) skrev:

Privat er der flere ting jeg gerne ville gøre, men som ikke fungerer fornuftigt med NAT. F.eks. er IP telefoni gennem NAT problematisk.

Alle telefonsystemer idag koerer igennem en PBX af en art, saa det er ikke noget stoerre problem.

Jo, når der er NAT mellem klienten og PBXen.

fidomuh (27) skrev:

Jeg kan ikke ssh direkte til en maskine bagved NAT, jeg kan heller ikke køre HTTP eller SMTP trafik direkte til en maskine bagved NAT.

Yes, det samme vil ske med IPv6, da man saa bruger firewalls.

Min firewall vil selvfølgelig tillade ssh trafik til alle de maskiner hvor der er behov for det.

Jeg kan ikke se fordelen i at have klient maskiner direkte paa nettet.

Jeg kan ikke nævne flere end dem jeg allerede har nævnt.

fidomuh (27) skrev:

Og endeligt er der problemet med tilstand gemt af NAT enheden. Den tilstand forsvinder hvis der går for lang tid uden aktivitet, eller enheden bliver genstartet.

Jeg forstaar ikke helt, det problem sker ikke med firewalls, eller?
NAT regler fungerer paa samme maade som firewall regler, more or less.

Hvis der kun skal filtreres pakker uden at ændre på dem, så kan det gøres tilstandsløst.

Og hvis man alligevel vælger at holde øje med noget tilstand, så er det en simplere tilstand man skal holde øje med. Det betyder at tilstanden nemmere kan replikeres mellem to enheder, og hvis man kun har en enkelt enhed, så kan tilstanden regenereres efter en genstart ved at observere trafik fra indersiden.

En typisk situation er følgende. En maskine på indersiden af firewallen åbner en TCP forbindelse til en maskine på ydersiden. Hvis ikke pakkerne bliver ændret af firewallen skal den bare huske, afsender og modtager adressen så pakker udefra kan komme ind. Bliver firewallen genstartet kan den blot droppe pakker udefra indtil den første pakke indefra bliver set. Dermed vil forbindelsen opretholdes. Havde man lavet translation ville firewallen skulle huske hvordan der skulle oversættes, og hvis firewallen blev genstartet ville disse oplysninger blive glemt.

Har man redundante firewalls er det nemmere at replikere tilstanden. De skal bare fortælle hinanden når de opretter nye indgange for udgående pakker. Når der at blive sendt pakker gennem begge firewalls før tilstanden er replikeret, så vil de alligevel oprette den samme indgang i deres tabel, så de skal altså bare kunne se om en indgang allerede findes, og alt vil fungere. Hvis derimod der var oversættelse af adresserne, så skal de for det første være enige om hvordan de holder styr på frie adresser, og ved pakketab og retransmission under oprettelse af en forbindelse er der en risiko for, at de to firewalls opretter modstridende indgange for samme forbindelse.

fidomuh (27) skrev:

Desuden er der problemer med bittorrent fordi maskiner ikke kan connecte direkte til hinanden. Og alt der bruger IP adresser i kommunikationen (andre steder end blot i pakkernes source og destination), vil have problemer.

Ja.
Det er ikke saa interessant for firmaer vil jeg vove at paastaa.

Jeg har da arbejdsmæssigt haft brug for bittorrent en enkelt gang, så det er jeg ikke enig i.

SmackedFly (28) skrev:

NAT bliver først et problem når der ikke er et 1:1 forhold imellem offentlige og private addresser. (eller rettere, et 1:1 forhold imellem portene)

Ja, hvis du har en 1:1 mapping, så giver NAT ikke så mange ulemper. Men på den anden side får man heller ikke ret mange fordele ud af NAT med en 1:1 mapping.

Hvis du bare vil skjule en intern IP bag en offentlig addresse har du ingen af de problemer du omtaler.

Jo, protokoller som sender IP adresserne, som f.eks. FTP giver problemer. Desuden er der ikke ret meget pointe i sådan en mapping. Hvis formålet er anonymitet afsører den eksterne adresse jo lige så meget som den interne, netop fordi der er en 1:1 mapping. Den interne adresse er jo ikke i sig selv interessant, men det er interessant at kunne genkende ting der kommer fra samme adresse.

Årsagen til at bruge NAT på den måde, er at du frit kan linke dine interne addresser sammen med dine eksterne som du har lyst til, uden at ændre dine interne addresser.

Jeg kan se hvordan det i nogle tilfælde kan være interessant. Men der ville jeg nok i stedet lade være med at bruge nogen form for NAT, og blot opdatere DNS records hvis et navn skal pege på en ny maskine.

Jeg vil til enhver tid mene at den anonymitet og fleksibilitet man får ved at have nok adresser og ingen oversættelse undervejs er langt bedre end de få fordele som NAT giver.

#29

Det virker ikke med protokoller som kører direkte imod IP addresser, et meget konkret eksempel er DNS.

Derudover giver det dig også mulighed for at splitte allerede eksisterende platforme op ved brug af portnatning. Ikke noget du bør gøre, men det giver dig lidt ekstra fleksibilitet at arbejde med.

Jeg er iøvrigt 100% enig i at IPv6 er en kæmpe fordel over IPv4 sammen med nat, den mængde hacks der er blevet lavet igennem tiden for at slå hul i et NAT setup er evindelig.

1:1 nat har nogle fordele til server design, men det betyder selvfølgelig ikke at man nødvendigvis skal bruge det. Det er dog værd at være opmærksom på at i Teleselskaber med komplekse net kan der være årsager til ikke at bruge offentlige addresser til alt, f.eks. management net, og så ender du med nogle komplekse private net som giver dig rigtig god grund til at seperere dine eksterne addresser fra dine private net.