[linux] Re: Doorgifte IP probleem

[Peter Fokker]

"Jan Rozema [NLLGG Member]" wrote:
> 
> > On Saturday 22 October 2005 10:56, Jan Rozema [NLLGG Member] wrote:
> >
> >>>> eth0:1 x.y.z.135 (Ik heb de beschikking over een range van 4  
> >>>> ipadressen, start x.y.z.132)
> >>>>
> >>>
> >>> Dit is niet een /30 subnet?
> >>>
> >> neen een /24 net
> >>
> > oh? ip = 4*bits =32
> > 32-24=8 bits
> > 8bits = 256 mogelijkheden, waarvan er een voor broadcast en een
> > voor de nul niet gebruikt worden.
> > Maar heeft een /30 subnet met dus 2 bits volgens dezelfde formule
> > nog maar 2 mogelijke ip adressen?
> > Maar wil je perse je linux doos als firewall/router gebruiken? want
> > anders zou arp-bridging toch ook een oplossing zijn?
> 
> Ik heb een range van ip-adressen tot mijn beschikking 213.160.254.129 
> met netmask 255.255.255.240
> 
> Vanaf .132 tot en met .142 heb ik tot mijn beschikking
> 
> De uiteindelijke configuratie bestaat uit een Gateway server(linux) met een LAN
> voor interne gebruikers en een koppeling naar o.a. een Windows 2003 S IIS server,
> 
> Waarmee o.a .asp websites worden gehost.
> 
> Dit even terzijde, 
> 
> iedereen binnen het netwerk kan de Windows web server bereiken en ik kan
> met deze server het internet bereiken. Zelfs pingen van buiten naar deze server 
> werkt, alleen aanvragen via tcp poort 80 lukt niet

Dat heeft waarschijnlijk toch te maken met routering. 'ping' is een connectionless
protocol. Het is dus niet nodig dat het reply via dezelfde weg terug gaat als het
request heen is gegaan. Voor TCP is dat nou net effe anders. Immers, als .132 nog
steeds de default gateway is (op de fedora/gatewayserver), dan zal een eerste
pakketje voor het opzetten van een  TCP-verbinding van buiten naar .135 waarschijnlijk wel naar de 
webserver geleid worden. Overigens zit daar al een NAT/MASQ tussen. De webserver
ziet dus als afzender 172.17.10.10 en stuurt het antwoord daarnaartoe terug.
De gateway neemt het (wederom na een NAT/MASQ) pakketje aan en stuurt het terug
naar de originele aanvrager,..... via .132 zijnde de default gateway. Dus: de
orginele aanvrager krijgt NOOIT een antwoord van .135 op zijn verzoek een TCP-verbinding
op te zetten. Hij krijgt wel vage pakketjes binnen van ene .132, maar dat zijn
ongeldige pakketjes (want: geen antwoord op een vraag die hij gesteld heeft). Die
kunnen dus gevoegelijk naar /dev/null...

Zoiets?

Ik denk dat je toch moet overwegen om dat adres .135 te laten vallen in dit geval.
Als je opziet tegen het inrichten van Squid als http accelerator dan kun je natuurlijk
alsnog de webserver ontsluiten via bijvoorbeeld x.y.z.132:81 (dus niet :80). Alle
verkeer voor poort 80 laat je dan bij de Apache op de fedora/gatewayserver uitkomen
en alle verkeer op poort 81 leid je door naar poort 80 op de webserver. Je kunt het
natuurlijk ook omdraaien: server de webstek van de fedore/gatewayserver op poort
81 en leidt poort 80 door naar poort 80 op de IIS webserver. Dan hoef je ook aan
mensen niet meer uit te leggen dat je soms "gewoon" op poort 80 kunt werken (nl.
vanaf het LAN) en soms op poort 81 (nl. vanaf buiten).

Overigens gaat dit er wel van uit dat je geen extra obstakels hebt op poort 81
binnen jouw range van IP-adressen. Als dat wel zo is, dan zou ik dat omzeilen
door domweg een tweede firewall/gateway te installeren. Dat geeft je nog veel
meer leuke (en leerzame!) mogelijkheden. Stel dat je een tweede fedora-machine
zou inrichten (laten we zeggen: 'fedora2' ;-)). Die geef je eth0=x.y.z.135 en
eth1=172.16.10.12. Dan kun je op de IIS webserver, die bijv. adres
172.16.10.20 heeft, de default route laten wijzen naar 172.16.10.12. D.w.z.:
al het verkeer vanaf de webserver naar buiten toe gaat dan via .135 naar buiten
en niet via .132. Alle client computers krijgen via DHCP gewoon .132 als
default gw. Daarmee kun je echt leuk 'spelen'. Oh well. Ik dwaal af.

Groeten,

--Peter Fokker

-- 
Get it right the first time!