Netwerken en port forwarding

[w4rguy]

Dames en heren,

Ik heb een creatief verzoek en een idee, maar wilde even sparren of er misschien andere mogelijkheden zijn.

Er is een domein. Laten we die even www.testdomein.com noemen. Dit domein verwijst naar een WAN ip. Laten we zeggen dat het ip-adres 80.76.54.32 is.

In het LAN netwerk staan twee verschillende hardwarematige servers. Laten we zeggen ServerA en ServerB. Beide servers hebben een webserver draaien. Deze servers mogen intern op andere poorten draaien. De externe poorten moeten echter dezelfde zijn.

Even kort door de bocht:
Als ik naar http://serverA.testdomein.com:80 ga moet ik uitkomen bij de webserver van ServerA
Als ik naar http://serverB.testdomein.com:80 ga moet ik uitkomen bij de webserver van ServerB

Een simpele oplossing zou zijn: pak een andere externe poort. Dat wil ik echter niet.

De oplossing waar ik aan zat te denken is een proxypass. Het oprichten van ServerC met apache waarin ik een proxypass instel. Deze moet kijken naar de virtualhost en een proxypass uitvoeren als wordt voldaan aan het juiste domein naar de juiste server. Poort 80 kan dan geforward worden naar ServerC en de andere servers behoeven dan geen port forwarding omdat die alleen communiceren met ServerC (intern dus).

Het kan zomaar zijn dat ik de plank helemaal mis sla, maar dan hoor ik het ook graag en wat dan wel zou werken. Belangrijk om er bij te vermelden is dat ik maar 1 IP-adres tot mijn beschikking heb. Anders had ik daar een statische mapping voor gemaakt en gekoppeld aan een subdomein.

**edit**
even een plaatje toegevoegd.. paintskillssssss

[ Voor 3% gewijzigd door w4rguy op 16-10-2013 13:36 ]

[ElCondor]

Dat is mogelijk. Als je de mogelijkheid hebt, kun je ook een reverse proxy opstelling gebruiken die je http requests op poort 80 afvangt en dan relayed naar de internet server met content. Zie reverse proxy op google voor meer informatie. Ik weet dat Microsoft eigen modules levert voor IIS om een reverse proxy in te richten.

Maar wat je wilt, kan inderdaad.

Een kleine aanvulling: als je met IIS een reverse proxy in gaat richten, dan verdeel je de sites door middel van een host header value mee te geven. Dit moet het DNS record zijn van je website.
Je moet de betreffende websites in je externe DNS dan ook als twee verschillende records hebben gedefiniëerd.

[ Voor 29% gewijzigd door ElCondor op 16-10-2013 15:04 ]

[w4rguy]

ElCondor schreef op woensdag 16 oktober 2013 @ 14:56:
Dat is mogelijk. Als je de mogelijkheid hebt, kun je ook een reverse proxy opstelling gebruiken die je http requests op poort 80 afvangt en dan relayed naar de internet server met content. Zie reverse proxy op google voor meer informatie. Ik weet dat Microsoft eigen modules levert voor IIS om een reverse proxy in te richten.

Maar wat je wilt, kan inderdaad.

Een kleine aanvulling: als je met IIS een reverse proxy in gaat richten, dan verdeel je de sites door middel van een host header value mee te geven. Dit moet het DNS record zijn van je website.
Je moet de betreffende websites in je externe DNS dan ook als twee verschillende records hebben gedefiniëerd.

Ik ben nu bezig om squid3 op pfsense in te stellen voor reverse proxy. Één van de achterliggende sites communiceert over HTTPS dus daar moet ik nog even naar kijken. Kreeg net voor die HTTPS-site een foutmelding die vermoedelijk te maken heeft met het certificaat wat de chain of trust doorbreekt. Uiteindelijk was het idee van die apache2 server om ook reverse proxy uit te voeren, alleen moest ik dan iets toevoegen aan mijn netwerk/router. Nu draait het op het bestaande systeem...

[w4rguy]

hm, ik kom er nog niet helemaal uit. Zit een beetje in mijn maag met hoe het zit met de domeinnamen. Mogen de domeinnamen in een lokale DNS-server geregistreerd staan of moet dat een domein bij een registrar zijn? Moet ik dan ook het subdomein registeren bij de registrar? En als ik de proxyserver poort 8000 geef, moet ik dan ook 8000 achter de URL plaatsen van het domein?

voorbeeld:
http://serverA.testdomein.com:8000 ---> website serverA op poort 80 (dan is de reverseproxy uiteraard ingesteld om door te verwijzen naar poort 80)

Wat ik heel vaak kreeg was dat ik terug kwam op de loginpagina van pfsense, ook als ik serverA.testdomein.com invoerde...

*notitie*
ik heb bewust geen edit gedaan omdat de inhoud een nieuwe vraag is binnen het onderwerp.

[lier]

Op basis van een domeinnaam example.com (en eventueel een A record www.example.com) maak je DNS entries aan. Volgens mij laat je deze allen naar hetzelfde IP adres verwijzen (hint).

Hoe ziet je config eruit?

Wat ik heb gedaan (Apache + IIS):
- reverse proxy
- interne DNS

code:

<VirtualHost *:80>
        ServerAdmin [e-mail]
        ServerName webservices.example.com
        ProxyRequests Off
        <Proxy *>
                Order deny,allow
                Allow from all
        </Proxy>
        ProxyPass / http://webservices.example.com/
        ProxyPassReverse / http://webservices.example.com/
</VirtualHost>

Bovenstaande is de config op mijn Apache server die webservices.example.com doorstuurt naar IIS. Op basis van webservices.example.com wordt deze geresolved naar de IIS server.

[w4rguy]

lier schreef op donderdag 17 oktober 2013 @ 10:25:
Op basis van een domeinnaam example.com (en eventueel een A record www.example.com) maak je DNS entries aan. Volgens mij laat je deze allen naar hetzelfde IP adres verwijzen (hint).

Hoe ziet je config eruit?

Wat ik heb gedaan (Apache + IIS):
- reverse proxy
- interne DNS

code:

<VirtualHost *:80>
        ServerAdmin [e-mail]
        ServerName webservices.example.com
        ProxyRequests Off
        <Proxy *>
                Order deny,allow
                Allow from all
        </Proxy>
        ProxyPass / http://webservices.example.com/
        ProxyPassReverse / http://webservices.example.com/
</VirtualHost>

Bovenstaande is de config op mijn Apache server die webservices.example.com doorstuurt naar IIS. Op basis van webservices.example.com wordt deze geresolved naar de IIS server.

Op dit moment draait het op packages die ik op Pfsense heb geinstalleerd. Dergelijke overzichten zoals jij laat zien heb ik dus niet. Ik kan vanavond wel kijken om gewoon apache te installeren op het FreeBSD platform (waar pfsense op draait). Dan kan ik het met de hand doen, alleen moet ik telkens de shell in duiken om wijzigingen te maken. Nu kan dat zo mooi via de webGUI van pfsense..

[lier]

Je denkt toch niet dat ik een GUI op mijn (Debian) server heb!?

[w4rguy]

lier schreef op donderdag 17 oktober 2013 @ 11:36:
Je denkt toch niet dat ik een GUI op mijn (Debian) server heb!?

webGUI .. web interface van pfsense

[vliegjong]

Ondersteunt je Appache server geen Server name Indication (onderdeeltje van TLS)? Zodoende kan je meerder certificaten koppelen achter hetzelfde ip:443 combinatie..

Ja dus maar het heet Named Virtual Hosts binnen Apache. Je dus je bouwt een rev proxy waarbij je op basis van de host header in de HTTP get de juiste forward doet naar de backend server (a of b) en afhankelijk van de SNI in de TLS handshake gooit je rev proxy het juiste certificaat naar de client om zodoende de goede Common Name te laten zien (anders gaat de client lopen miepen)

Wikipedia: Server Name Indication

[ Voor 42% gewijzigd door vliegjong op 17-10-2013 16:21 ]

[w4rguy]

Uiteindelijk is het gelukt. Ik heb een aparte ubuntuserver op onze ESXi geïnstalleerd. hierop draait apache2 met reverse proxy. Ik heb de certificaten ingeladen en kan per virtual host de certificaten aangeven die hij mee moet geven.

Iets anders waar ik tegenaan liep was het feit dat hij een default heeft. Oftewel: als de naam van de request niet voldoet aan een bekende virtual host, dan verwijst hij door naar de eerste virtual host in de rij. Super onwenselijk natuurlijk! Dan kan iemand zonder kennis één van de pagina's bereiken.

Ik heb daarvoor de website (HTTP en HTTPS) van apache2 intact gelaten. Daar een .htaccess file op geplaatst die toegang voor iedereen verbiedt. Vervolgens de server signature uitgeschakeld zodat die niet in de 404-error meer naar voren komt.

Alvast bedankt voor de hulp en input

[Osiris]

Euhm, waarom gewoon niet een default virtualhost maken met iets van "onder deze domeinnaam is geen website geconfigureerd" en je serverA en serverB-vhosts respectievelijk als 2e en 3e virtualhost instellen?

En waarom vliegjong opeens over SNI en TLS begint te bazelen is mij compléét niet duidelijk .

De enige reden waarom SNI bestaat, is omdat je anders niet d.m.v. de HTTP 1.1 Host-header een apart certificaat kunt presenteren.

Die Host-header is wat je nodig hebt om een non-IP-based virtualhost in te stellen. Of dat nou met of zonder SNI gaat of niet, who f*cking cares? Not part of the solution iig, aangezien ik de TS nergens hoor praten over SSL, TLS of poort 443, maar alleen over poort 80, non-HTTPS-verkeer dus.

[ Voor 56% gewijzigd door Osiris op 18-10-2013 01:04 ]

[3DDude]

Er is een domein. Laten we die even www.testdomein.com noemen. Dit domein verwijst naar een WAN ip. Laten we zeggen dat het ip-adres 80.76.54.32 is.

De eerste vraag die ik heb wat voor verwijzing is dat ? alles ? MX ? A ? srv? enz

Verder zul je iets van een firewall appliance die de mogelijkheid tot een loadbalancer heeft ofzo moeten gebruiken.

Ik heb een project met exchange en OWA loadbalance gedaan en heb daarvoor destijds een virtuele loadbalancer van KEMP Technologies gebruikt.

[Osiris]

3DDude schreef op vrijdag 18 oktober 2013 @ 01:10:
[...]


De eerste vraag die ik heb wat voor verwijzing is dat ? alles ? MX ? A ? srv? enz

En dat is relevant... Hoe?

3DDude schreef op vrijdag 18 oktober 2013 @ 01:10:
Verder zul je iets van een firewall appliance die de mogelijkheid tot een loadbalancer heeft ofzo moeten gebruiken.

Zie jij de TS praten over loadbalancing? Nee, hij heeft twee aparte hostnames voor twee aparte servers. Dat de TS een hostname (dat met www. ervoor in z'n topicstart) vergist met een domein (het "testdomein.com"-deel) is iets anders.

3DDude schreef op vrijdag 18 oktober 2013 @ 01:10:
Ik heb een project met exchange en OWA loadbalance gedaan en heb daarvoor destijds een virtuele loadbalancer van KEMP Technologies gebruikt.

Aandelen daarin toevallig?

[w4rguy]

Osiris schreef op vrijdag 18 oktober 2013 @ 01:02:
Euhm, waarom gewoon niet een default virtualhost maken met iets van "onder deze domeinnaam is geen website geconfigureerd" en je serverA en serverB-vhosts respectievelijk als 2e en 3e virtualhost instellen?

Omdat dat eigenlijk hetzelfde is als wat hij nu doet. Er draaien default hosts op HTTP en HTTPS (poorten 80 en 443 naar buiten). Het externe domeinnaam heeft een wildhard. *.domein.com. Als je "vreuinveuri.domein.com" invoert kom je altijd uit bij de webserver.

Als je nu "vrmiov.domein.com" invult kom je op de webserver uit (defualt webserver). Op die webserver wordt de toegang geweigerd. Oftewel, je MOET het domeinnaam weten voordat je de lokale server kunt bereiken.

Overigens was HTTPS ook ter sprake, alleen was dat niet mijn eerste stap. Ik wilde eerste alles werkend hebben voor HTTP om vervolgens te kijken voor HTTPS, dat is inmiddels ook gelukt (al kan het nog wat finetuning van de certificaten gebruiken).

Wat betreft loadbalancing, inderdaad gebruik ik niet. Je hoort het vaak wel hand-in-hand met reverse proxy maar zo pas ik het niet toe. Het zijn aparte lokale webapplicaties op aparte services die op dezelfde poort naar buiten gaan.