Bekijk Volledige Versie : Webserver niet bereikbaar vanaf klant en public wifi datacenter
Hallo allemaal,
Ik zit even met het volgende.
Vanaf het huis van een klant en vanaf het publieke wifi ap van ons datacenter zijn de websites die we hosten niet bereikbaar.
Vanaf mijn eigen huis en die vanaf mijn collega en andere klanten zijn de websites wel gewoon te benaderen.
Ik heb de firewall server doorgespit maar kan niets geks vinden.
Nu moet ik zeggen dat ik afgelopen nacht in het datacenter aan het werk geweest ben om alle servers te voorzien van ssd's (duurde iets langer dan geplanned) dus ik ben niet helemaal helder vandaag.
Wellicht zie ik iets over het hoofd dus vraag ik jullie advies in welke richting ik zou kunnen zoeken.
Graag wil ik vermelden dat de servers achter de firewall draaien op 1 na welke wel bereikbaar is.
Onze webservers draaien op debian en de firewall server draait op dit moment pfsense.
Verder wil ik nog vermelden dat dit probleem al een tijdje speelt en ik ook contact heb gezocht met de technische dienst van het datacenter maar tot op heden hebben we nog geen oplossing kunnen vinden.
Alvast bedankt en een goede nachtrust.
M.vr.gr,
Wesley
Zit je klant toevallig op dezelfde netwerk leverancier? Lijkt op routing issue waar verkeer bestemd voor je eigen netwerk niet weggerouteerd word. Wat zegt je fw log? Komt er verkeer toe en hoe gedraagt het zich ?
Sent from my Nexus 5 using webhostingtalk mobile app
Doe eens een trace (route) zou ik zeggen. Daaraan kun je zien hoe ver je wel of niet komt.
Sent from my iPhone using webhostingtalk mobile app
Dezelfde netwerk levenerancier lijkt mij niet. De klant heeft upc internet welke ik zelf echter ook heb en bij mij gaat alles goed. Ik heb 1 server buiten de firewall om draaien en daar kan wel naar toe geconnect worden vanaf het datacenter. Helaas heb ik dit niet kunnen testen bij de klant. in de firewall log staat niets over een verbinding vanaaf upc of vanaf de wifi ap van het datacenter.
De traceroutes had ik al gemaakt voor de jongens van het datacenter en die stopte bij de openpeering van het datacenter.
Vanaf mijn firewall server is er ook een traceroute genomen naar de klant maar daar gaat het gelijk al fout bij de eerste.
Wellicht is het handig om te vermelden dat de servers in het datacenter van TransIP draaien.
CharlieRoot
17/11/14, 12:03
Klinkt als een VLAN/Firewall issue..
Klinkt als een VLAN/Firewall issue..
Wij maken geen gebruik van vlan's. Firewall issue is goed mogelijk alleen waar zou het kunnen zitten.
In de firewall log staat helaas verder geen info.
Wij maken geen gebruik van vlan's. Firewall issue is goed mogelijk alleen waar zou het kunnen zitten.
In de firewall log staat helaas verder geen info.
Dan moet je niet in de log, maar met tcpdump kijken.
De eerste vraag is of Wifi verkeer de buitenkant van je firewall haalt.
Kijk eerst even in de log van de server die _wel_ bereikt wordt, met welk IP adres het wifi netwerk aankomt.
Dan kijk je op je firewall met tcpdump (tcpdump -ni <extern interface> host <verwachte IP van wifi netwerk> ) of verkeer uberhaupt de buitenkant van de firewall haalt.
Je kunt ook met traceroute vanaf het wifi netwerk kijken hoe ver je komt , en vooral of je door andere hops richting je onbereikbare servers versus degene die wel werken (in hetzelfde datacenter).
Het zou nog kunnen dat dat zo'n intern gekoppeld netwerk bijvoorbeeld de afslag 'eerst door NAT' mist, als dat iets verderop gedaan wordt.
Of misschien dat het wifi netwerk nogal hard 'naar buiten' geduwd wordt, en dan niet meer goed 'terug' gerouteerd wordt voor een netwerk wat in hetzelfde DC gehost wordt.
Ik begrijp dat enkel je servers achter de firewall niet bereikbaar zijn en diegene die niet achter de firewall zit wel. Zal je toch daarnaar moeten kijken verwacht ik.
Ik begrijp dat enkel je servers achter de firewall niet bereikbaar zijn en diegene die niet achter de firewall zit wel. Zal je toch daarnaar moeten kijken verwacht ik.
Met de gegeven informatie ligt dat voor de hand, inderdaad.
Maar als de bereikbare en onbereikbare servers in een ander netwerk segment zitten is een routing issue natuurlijk niet uitgesloten.
Maar als TS niet meer informatie wil geven duurt het alleen maar langer om wat te gokken naar de oorzaak. Afijn, zijn probleem.
Puur op basis van wat je net geschreven hebt:
Waarschijnlijk heb je een aparte categorie/group in je firewall voor het huis/kantoor van de klant en de publieke wifi van het DC (of die laatste nog apart in een groep). Misschien staat deze per ongeluk op block of niet in de juiste volgorde?
DB Service
17/11/14, 17:55
Kan de klant wel op andere sites op deze server en of binnen jullie netwerk?
Verzonden vanaf mijn iPhone met behulp van webhostingtalk
Al eens bekeken welke DNS server jij (je router eventueel) thuis gebruikt en de klant?
Als ik me niet vergis heeft TransIP een tijd terug ipsec in dienst gesteld en naargelang de gebruikte DNS loopt het wel eens mis. Met Google DNS en OpenDNS ging het goed, met onze Belgische Telenet DNS niet. Maar niet voor iedereen. ipV6 had er ook nog mee te maken, waardoor mijn eurocent op de verkeerde plaats terechtkwam...
Dan moet je niet in de log, maar met tcpdump kijken.
De eerste vraag is of Wifi verkeer de buitenkant van je firewall haalt.
Kijk eerst even in de log van de server die _wel_ bereikt wordt, met welk IP adres het wifi netwerk aankomt.
Dan kijk je op je firewall met tcpdump (tcpdump -ni <extern interface> host <verwachte IP van wifi netwerk> ) of verkeer uberhaupt de buitenkant van de firewall haalt.
Je kunt ook met traceroute vanaf het wifi netwerk kijken hoe ver je komt , en vooral of je door andere hops richting je onbereikbare servers versus degene die wel werken (in hetzelfde datacenter).
Het zou nog kunnen dat dat zo'n intern gekoppeld netwerk bijvoorbeeld de afslag 'eerst door NAT' mist, als dat iets verderop gedaan wordt.
Of misschien dat het wifi netwerk nogal hard 'naar buiten' geduwd wordt, en dan niet meer goed 'terug' gerouteerd wordt voor een netwerk wat in hetzelfde DC gehost wordt.
Ik ga dat eens proberen. ik moet wel zeggen dan een server buiten de firewall om wel bereikbaar is.
Kan de klant wel op andere sites op deze server en of binnen jullie netwerk?
Verzonden vanaf mijn iPhone met behulp van webhostingtalk
Nee, alles achter de firewall is niet te benaderen.
Alles voor de firewall wel.
Al eens bekeken welke DNS server jij (je router eventueel) thuis gebruikt en de klant?
Als ik me niet vergis heeft TransIP een tijd terug ipsec in dienst gesteld en naargelang de gebruikte DNS loopt het wel eens mis. Met Google DNS en OpenDNS ging het goed, met onze Belgische Telenet DNS niet. Maar niet voor iedereen. ipV6 had er ook nog mee te maken, waardoor mijn eurocent op de verkeerde plaats terechtkwam...
Ik maak voor de serveers gebruik van de DNS servers van transip.
Verder gebruik ik thuis de standaard DNS server van UPC en bij de klant ook.
Ook heb ik bij de klant andere DNS servers gebruikt om het te testen.
Ipv6 maken we geen gebruik van op dit moment.
- - - Updated - - -
Puur op basis van wat je net geschreven hebt:
Waarschijnlijk heb je een aparte categorie/group in je firewall voor het huis/kantoor van de klant en de publieke wifi van het DC (of die laatste nog apart in een groep). Misschien staat deze per ongeluk op block of niet in de juiste volgorde?
Op dit moment staan er geen blocks in de firewall.
Met de gegeven informatie ligt dat voor de hand, inderdaad.
Maar als de bereikbare en onbereikbare servers in een ander netwerk segment zitten is een routing issue natuurlijk niet uitgesloten.
Maar als TS niet meer informatie wil geven duurt het alleen maar langer om wat te gokken naar de oorzaak. Afijn, zijn probleem.
Welke informatie zou je willen hebben? wellicht dat ik je die kan geven.
Heeft er toch alle schijn van dat de firewall de issue is. Probeer die ip's eens te whitelisten anders?
Welke informatie zou je willen hebben? wellicht dat ik je die kan geven.
Wat zou helpen zijn
ip,subnetmask,gateway van hosts achter de firewall
ip,subnetmask,gateway van de host 'buiten' de firewall
ip,subnetmask,gateway van een wifi client die de gefirewallde hosts niet kan bereiken
traceroute vanaf wifi client naar gefirewallde en niet gefirewallde (werkende) host
Er zijn een aantal netwerk structuren te verzinnen bij je omschrijving, en de plek waar het probleem kan zitten verschilt afhankelijk van wat het is.
Als werkende en gefirewallde hosts in een heel ander subnet zitten, kan het hele pad (inclusief een routing of firewall issue in het datacenter domein) anders zijn.
Als het wifi net eventueel een (centrale) NAT /firewall gebruikt en er toevallig verkeer naar de niet-werkende setup voordien al 'ontsnapt' (met rfc1918 source ) wat dan (terecht) tegengehouden wordt.
Om maar iets te noemen.
Met een beeld van de topologie kun je gericht zoeken (cq - kan ik, of iemand) gericht suggesties geven waar te zoeken in plaats van met hagel te schieten naar duizend en één manieren waarop iets in elkaar zou kunnen zitten.
Wat soms ook nog wel eens wil voorkomen dat je DNS servers niet sync met elkaar zijn hierdoor kan het gebeuren dat de ene provider bijvoorbeeld NS1 gebruikt en een andere provider NS2. Even met dig/nslookup direct bij je nameservers controleren welke antwoorden ze geven.
DB Service
17/11/14, 23:00
Ip whithlisten of je firewall kort bypassen en dan checken of t wel lukt
Verzonden vanaf mijn iPhone met behulp van webhostingtalk
Ipv6 maken we geen gebruik van op dit moment.
Dat dacht ik ook. Maar de DNS had daar een ander idee over...
Wat zou helpen zijn
ip,subnetmask,gateway van hosts achter de firewall
ip,subnetmask,gateway van de host 'buiten' de firewall
ip,subnetmask,gateway van een wifi client die de gefirewallde hosts niet kan bereiken
traceroute vanaf wifi client naar gefirewallde en niet gefirewallde (werkende) host
Er zijn een aantal netwerk structuren te verzinnen bij je omschrijving, en de plek waar het probleem kan zitten verschilt afhankelijk van wat het is.
Als werkende en gefirewallde hosts in een heel ander subnet zitten, kan het hele pad (inclusief een routing of firewall issue in het datacenter domein) anders zijn.
Als het wifi net eventueel een (centrale) NAT /firewall gebruikt en er toevallig verkeer naar de niet-werkende setup voordien al 'ontsnapt' (met rfc1918 source ) wat dan (terecht) tegengehouden wordt.
Om maar iets te noemen.
Met een beeld van de topologie kun je gericht zoeken (cq - kan ik, of iemand) gericht suggesties geven waar te zoeken in plaats van met hagel te schieten naar duizend en één manieren waarop iets in elkaar zou kunnen zitten.
Bedankt voor de heldere informatie.
Hosts achter de firewall:
IP's Intern: 192.168.1.10 tot 192.168.1.50
Netmask intern: 255.255.255.0
Gateway intern:192.168.1.1
webserver ip: 80.69.84.144 (buitenkant)
webserver ip: intern een adres binnen de reeks hierboven
netmask: 255.255.255.128
gateway: 80.69.84.129
DNS1: 80.69.66.67
DNS2: 80.69.67.66
Host buiten de firewall:
IP: 80.69.84.142
netmask: 255.255.255.128
gateway: 80.69.84.129
DNS1: 80.69.66.67
DNS2: 80.69.67.66
Ik hoop dat ik het zo goed heb beschreven.
Voor de overige informatie zal ik in deze dagen even naar het datacenter moeten.
Ik heb eventueel wel een traceroute van mijn firewall server naar de klant maar weet niet of dat relevant is.
Traceroute output for 80.56.89.38:
1 v984.router1.dcg.transip.net (80.69.84.221) 54.429 ms 0.310 ms 0.440 ms
2 ibgp.router2.dcga.ams.transip.net (87.253.141.250) 0.437 ms 0.270 ms 0.346 ms
3 transip.customer.openpeering.nl (82.150.154.57) 9.374 ms 0.569 ms 0.691 ms
4 openpeering-10g.upc.nl (82.150.153.114) 0.836 ms 0.936 ms 0.788 ms
5 84.116.136.29 (84.116.136.29) 5.681 ms
84.116.134.114 (84.116.134.114) 5.509 ms 5.696 ms
6 84.116.244.70 (84.116.244.70) 6.495 ms 6.169 ms 6.225 ms
7 212.142.56.230 (212.142.56.230) 7.682 ms 7.607 ms 7.676 ms
8 * * *
9 * * *
10 * * *
11 * * *
Voor de vergelijking staat hieronder een traceroute naar mijn eigen huis (ook UPC)
Traceroute output for 89.99.215.171:
1 v984.router1.dcg.transip.net (80.69.84.221) 0.316 ms 0.265 ms 0.262 ms
2 ibgp.router2.dcga.ams.transip.net (87.253.141.250) 0.411 ms 0.265 ms 0.267 ms
3 transip.customer.openpeering.nl (82.150.154.57) 0.683 ms 0.759 ms 0.794 ms
4 openpeering-10g.upc.nl (82.150.153.114) 1.856 ms 0.769 ms 0.754 ms
5 84.116.135.201 (84.116.135.201) 10.526 ms 3.860 ms
84.116.135.181 (84.116.135.181) 3.903 ms
6 84.116.244.22 (84.116.244.22) 4.583 ms 4.268 ms 4.666 ms
7 212.142.55.230 (212.142.55.230) 6.534 ms 6.518 ms 6.428 ms
8 dhcp-089-099-215-171.chello.nl (89.99.215.171) 17.763 ms 11.652 ms 11.769 ms
- - - Updated - - -
Dat dacht ik ook. Maar de DNS had daar een ander idee over...
Hoe bedoel je precies want wellicht kan ik hier ook induiken.
- - - Updated - - -
Ip whithlisten of je firewall kort bypassen en dan checken of t wel lukt
Verzonden vanaf mijn iPhone met behulp van webhostingtalk
Beide geprobeerd, echter zonder resultaat.
Hoe bedoel je precies want wellicht kan ik hier ook induiken.
Ik dacht dat ipV6 geen rol speelde, omdat het om een oudere server zonder ipV6 ging. Ik was echter vergeten dat het control panel daar wel iets voor invult in de web interface. En de DNS was wel ipV6 klaar. Het werkte wel met OpenDNS en Google DNS, maar SOMS niet met die van de ISP.
Waarom het in dat specifiek geval misging met een ipV4 naar ipV4 verbinding is me verder een raadsel.
Ik dacht dat ipV6 geen rol speelde, omdat het om een oudere server zonder ipV6 ging. Ik was echter vergeten dat het control panel daar wel iets voor invult in de web interface. En de DNS was wel ipV6 klaar. Het werkte wel met OpenDNS en Google DNS, maar SOMS niet met die van de ISP.
Waarom het in dat specifiek geval misging met een ipV4 naar ipV4 verbinding is me verder een raadsel.
Bedankt voor je reactie, ik ga hier eens naar kijken.
Is er iemand die dit kan ophelderen?
Bedankt voor de heldere informatie.
Hosts achter de firewall:
IP's Intern: 192.168.1.10 tot 192.168.1.50
Netmask intern: 255.255.255.0
Gateway intern:192.168.1.1
webserver ip: 80.69.84.144 (buitenkant)
webserver ip: intern een adres binnen de reeks hierboven
netmask: 255.255.255.128
gateway: 80.69.84.129
DNS1: 80.69.66.67
DNS2: 80.69.67.66
Host buiten de firewall:
IP: 80.69.84.142
netmask: 255.255.255.128
gateway: 80.69.84.129
DNS1: 80.69.66.67
DNS2: 80.69.67.66
Ik hoop dat ik het zo goed heb beschreven.
Voor de overige informatie zal ik in deze dagen even naar het datacenter moeten.
Ik heb eventueel wel een traceroute van mijn firewall server naar de klant maar weet niet of dat relevant is.
[knip]
Ok, dank.
Nu is in elk geval duidelijk dat firewall buitenkant en werkende host in hetzelfde subnet zitten, en dat maakt het erg waarschijnlijk dat routing tussen Wifi en hosts hetzelfde pad en dezelfde componenten (wifi nat ?, firewall voor wifi net) passeert.
Volgende stap is dan de traceroute vanaf een wifi client, en vooral met tcpdump kijken op de ontvangende host of verkeer ook aankomt.
Ik zou op de werkende host even controleren welk source IP je vanaf Wifi krijgt (wordt dat genat naar buiten toe ?), en dan met tcpdump kijken op de firewall.
Op een Linux gebaseerde firewall kijkt tcpdump 'voor' de firewall regels, dwz, je ziet nog steeds packets die de firewall later zal droppen.
De vraag is of verkeer vanaf het wifi net wel aankomt aan de buitenkant van je firewall - zo ja, dan moet je harder zoeken in de rules .
Ok, dank.
Nu is in elk geval duidelijk dat firewall buitenkant en werkende host in hetzelfde subnet zitten, en dat maakt het erg waarschijnlijk dat routing tussen Wifi en hosts hetzelfde pad en dezelfde componenten (wifi nat ?, firewall voor wifi net) passeert.
Volgende stap is dan de traceroute vanaf een wifi client, en vooral met tcpdump kijken op de ontvangende host of verkeer ook aankomt.
Ik zou op de werkende host even controleren welk source IP je vanaf Wifi krijgt (wordt dat genat naar buiten toe ?), en dan met tcpdump kijken op de firewall.
Op een Linux gebaseerde firewall kijkt tcpdump 'voor' de firewall regels, dwz, je ziet nog steeds packets die de firewall later zal droppen.
De vraag is of verkeer vanaf het wifi net wel aankomt aan de buitenkant van je firewall - zo ja, dan moet je harder zoeken in de rules .
Probleem is verholpen.
Ik heb 2 netwerkkaarten in de firewall server zitten en ik verander van kaart en alles werkt naar behoren. net de klant nog aan de lijn gehad en deze kan alles benaderen.
CharlieRoot
19/11/14, 11:05
Probleem is verholpen.
Ik heb 2 netwerkkaarten in de firewall server zitten en ik verander van kaart en alles werkt naar behoren. net de klant nog aan de lijn gehad en deze kan alles benaderen.
Ik kan inderdaad ook alles benaderen. Misschien zelfs iets te veel ;-)
PORT STATE SERVICE
21/tcp open ftp
25/tcp open smtp
80/tcp open http
110/tcp open pop3
143/tcp open imap
389/tcp closed ldap
443/tcp open https
465/tcp open smtps
993/tcp open imaps
995/tcp open pop3s
2222/tcp open EtherNet/IP-1