Domain based NAT

[Staatslot]

Ik heb een vraag waar ik al een aantal dagen mee bezig ben geweest, maar die ik nog niet heb kunnen oplossen.

De situatie
Meerdere virtuele server achter NAT, dus ip-adressen 192.168.1.1 - 192.168.1.10.
Daaronder zijn meerdere webservers, meerdere server die dezelfde poorten gebruiken in ieder geval.

De DNS wordt trouwens extern afgehandeld, bij Transip.

Wat ik wil?
bv sabnzb.mijndomein.nl > 192.168.1.5:80
maar ook webserver1.mijndomein.nl > 192.168.1.3:80
en ook webserver2.mijndomein.nl > 192.168.1.9:80

ofwel, aan de hand van de domeinnaam (of nog concreter; het subdomein) bepalen naar welk interne ip-adres moet worden geforward.

Poort forwarden in de router is geen probleem, maar daar kan ik natuurlijk niet filteren per domein ik kan alleen een poort(range) doorzetten naar een bepaald IP-adres.

Wat ik wil, maar dan uitgebreider
Naast http (poort 80) wil ik ook alle andere services kunnen forwarden, dus ssh naar diverse interne machines van buitenaf, webmin (poort 10.000), ftp etc moet dus op dezelfde manier worden doorgestuurd naar een intern adres...

Wat heb ik geprobeerd?
Ik heb uiteindelijk gevonden dat zoiets zou moeten kunnen met squid (reverse proxy).
Ik heb intern getest door een testmachine te maken, het hosts bestand aan te passen door deze voor 2 domeinen te laten verwijzen naar het interne ip van de squid machine, en in de squid config getracht deze om te leiden naar de juiste machine.

Dat is helaas niet gelukt, ik krijg het gewoon niet aan de praat.

Heeft iemand een tip voor me, zit ik wel goed met Squid of zijn er nog veel makkelijkere manieren die ik gewoon niet heb bedacht?

Bedankt!

[Voor 11% gewijzigd door Staatslot op 12-06-2011 16:35]

[Sendy]

Apache kan een reverse proxy zijn, net als squid. Dat is dus prima. Mischien vind je Apache eenvoudiger te configuren?

[Staatslot]

Sendy schreef op zondag 12 juni 2011 @ 16:26:
Apache kan een reverse proxy zijn, net als squid. Dat is dus prima. Mischien vind je Apache eenvoudiger te configuren?

Misschien had ik dat er nog even bij moeten vermelden, het gaat niet alleen om webservers.
Ik wil ook SSH-servers, mailservers etc aansturen op dezelfde manier..

Het lijkt me niet echt handig om dat allemaal via een webserver te laten lopen en door te laten stromen?

[CyBeR]

Hiervoor heb je inderdaad een reverse proxy nodig. Daar zijn er veel van. Squid kan het, maar is eigenlijk een forward proxy. Je kunt ook kijken naar Varnish (mijn favoriet), Pound, HAProxy, Traffic Server, nginx, lighttpd en inderdaad, Apache kan het ook.

Voor HTTP kan dit, voor de rest is 't eigenlijk niet zomaar mogelijk.

[Voor 12% gewijzigd door CyBeR op 12-06-2011 16:29]

[Staatslot]

CyBeR schreef op zondag 12 juni 2011 @ 16:28:
Hiervoor heb je inderdaad een reverse proxy nodig. Daar zijn er veel van. Squid kan het, maar is eigenlijk een forward proxy. Je kunt ook kijken naar Varnish (mijn favoriet), Pound, HAProxy, Traffic Server, nginx, lighttpd en inderdaad, Apache kan het ook.

Voor HTTP kan dit, voor de rest is 't eigenlijk niet zomaar mogelijk.

Bedankt, maar bedoel je dat apache het alleen voor HTTP kan of kunnen ze het allemaal eigenlijk alleen goed voor HTTP-verkeer?

[CyBeR]

Staatslot schreef op zondag 12 juni 2011 @ 16:32:
[...]


Bedankt, maar bedoel je dat apache het alleen voor HTTP kan of kunnen ze het allemaal eigenlijk alleen goed voor HTTP-verkeer?

Nou, de meeste protocollen houden helemaal geen rekening met virtualhosting zoals http dat doet. Dus bij HTTP kan 't heel makkelijk (met bovengenoemde opties). Voor IMAP kun je nog een truuk uithalen met de loginnaam (aangezien inloggen het eerste is wat je doet; je kunt dan bv inloggen met user@domain en de server selecteren op het domain deel) maar voor andere services wordt dat steeds moeilijker. Voor IMAP proxy'en gebruik ik zelf dovecot, maar er is ook Perdition en ik geloof zelfs dat nginx het ook kan.

[Voor 7% gewijzigd door CyBeR op 12-06-2011 16:51]

[Staatslot]

Ik heb inmiddels door wat standaardconfiguraties van squid te combineren squid aan de praat gekregen, dat is al heel wat na wat avondjes zonder resultaat..

Nu maar eens kijken of het ook mogelijk is ander verkeer dan http door de machine te duwen..

[donny007]

Kun je niet alle sites en services op één (misschien wat zwaardere) server zetten dmv Apache virtualhosts? Scheelt weer in stroomverbruik en beheer (hierbij neem ik aan dat het hobbywerk is, en geen productie, anders is NAT überhaupt niet the best way to go). Alle taken die je beschrijft kunnen prima door één goed ingerichte server afgehandeld worden (tenzij je over duizenden mailtjes en tienduizenden bezoekers per dag praat, maar dan bezwijkt een standaard routertje ook snel).

[Voor 32% gewijzigd door donny007 op 12-06-2011 20:02]

[Staatslot]

Bedankt voor je reactie, maar helaas dat kan niet.
Het is inderdaad hobby knutselwerk lekker thuis, maar het is een esxi server die ik juist wil benutten door virtuele machines en dus juist niet wil samenvoegen..

Maar wat ik niet begrijp, dit probleem moeten toch wel meer knutselaars thuis hebben waarom kan ik er dan zo weinig over vinden.. Het lijkt wel of ik de enige ben die dit probleem wil omzeilen..?
E nou heb ik dat Squid aan de praat, lijkt het alleen zijn werk te doen voor http(s) verkeer..

[ik222]

Dat het niet zomaar voor elk protocol werkt is logisch. Namelijk in principe doe je met het benaderen van een domeinnaam een DNS request, dat levert een ip op en vervolgens wordt de server gewoon op dat IP benaderd.

Om het verkeer naar de juiste server door te sturen op basis van een domeinnaam moet er dus in de applicatielaag zelf (op layer 7) een veld zijn wat de benaderde domeinnaam bevat, zodat de reverse proxy dat kan uitlezen en op basis daarvan zijn beslissing kan nemen. Dit veld is er bij http in de vorm van de http host header en daarom kan het bij http op die manier werken. Echter bij andere applicaties(SSH etc) is zo'n veld er simpelweg niet en dus gaat het ook niet op die manier werken. Dan kun je zoals Cyber zegt bij sommige applicaties op een andere manier het verkeer nog onderscheiden en naar de juiste server leiden maar dat wordt voor de meeste toepassingen erg lastig / onmogelijk.

[servicedb]

Http verkeer zou ik dmv een proxy afhandelen, en voor de rest (aangenomen dat dit niet publiekelijk toegangelijk is) zou ik dmv een vpn bereiken.

Technisch is het niet haalbaar om op domeinnaam basis een nat te krijgen, de router kijkt namelijk alleen naar de ip's en niet naar de domeinnamen.
De opties die je hebt: naast de reverse proxies:
* de server naar een data center verplaatsen, zoek een beetje rond en dit kan al voor 30 euro inclusief stroom en een Gbit verbinding.
* een vps afnemen met meerdere ip's en deze dmv een vpn doorzetten naar huis

[Staatslot]

Bedankt voor jullie reactie, het is me duidelijk..
Ook is me duidelijk dat dit waarschijnlijk met ipv6 geen probleem meer zou zijn, dan is er immers geen nat, maar zover zijn we helaas nog niet.

Ik heb zelf wat servers en dus vps min of meer gratis tot mn beschikking, maar sommige dingen wil ik gewoon lekker thuis klooien en aanmodderen met veel virtuele machines.. Ik ga het denk ik zoeken in een combinatie van eerder genoemde oplossingen al zal ik voor mn backup over ssh op tijd gebaseerde firewall regels toepassen.. De backup snachts wijst dan naar bij ssh naar intern adres x.y en overdag naar a.b denk ik.. Anders moet ik in mijn ssh scripts ssh wachtwoorden gaan zetten dat is ook niet al te veilig.

Bedankt voor alle informatie, we hebben in ieder geval een hoop trefwoorden voor toekomstige zoekopdrachten weteh te claimen met een hele heldere uitleg. Bedankt!

[donny007]

Ik weet wat je wil, heb er zelf ook al lang naar gezicht met de conclusie, het is (bijna) onmogelijk.

Als je een SSH sessie opent doet je SSH-client niets anders dan lookup(domein.nl), en gebruikt vervolgens het IP om te verbinden met de server, de server ziet niet welk (sub)domein je hebt gebruikt. Bij het HTTP protocol zend de webbrowser (http cliënt) wat informatie mee in de GET request -zoals het gebruikte domein- naar je server, daardoor kan Apache de domeinen onderscheiden en de juiste pagina serveren.

Het HTTP(s) protocol is (zover ik weet) het enige protocol met die functionaliteit.

Je kunt overwegen om bij je ISP meerdere vaste IPV4-adressen te nemen (is meestal erg duur), als je isp IPV6 (volledig) ondersteund kun je dat overwegen. Als tweede optie kun je toch overwegen om de boel samen te voegen, is zonde van je omgeving en brengt een hoop securityproblemen met zich mee, maar wel het meest praktische. Een andere oplossing is om alle websites (poort 80 spul) op een server zetten en benaderen via virtualhosts (eventueel met Apache's mod_proxy om je sabnzbd aan te spreken), ssh (poort 22) naar een server forwarden en via daar weer SSH'en naar de andere servers indien nodig, mailpoorten gewoon naar je mailserver forwarden, FTP is dan nog het enige knelpunt, daarvoor kun je poort 21 forwarden naar de server die je het meest gebruikt of die eventueel publiek moet zijn, de rest kun je met VPN of een SSH tunnel aan.

Ik zelf heb nu 2 fysieke servertjes, een als FreeNas die alleen lokaal bereikbaar is, en een als 'internethost' die de webhosting/ftp/sabnzbd/spotweb/ssh/vpn etc. verzorgt, waarbij alle websites zijn gescheiden met virtualhosts, die worden aangesproken via subdomeinen, sommige delen zijn alleen lokaal bereikbaar (zoals sab en spotweb). Sanbzbd schrijft weg naar de FreeNas via een NFS share. Op de Freenas zijn backups en downloads weer gescheiden, 4 lagen van beveiliging moeten er doorbroken worden om in de buurt van de belangrijke bestanden te komen, en dan zijn de backups ook nog is geëncrypt

[Voor 55% gewijzigd door donny007 op 13-06-2011 01:45]