Centos: DNS requests forwarden van backend naar frontend

[biggydeen2]

Hoi Tweakers,

Ik heb nog niet heel veel ervaring met Centos maar ik loop nu echt vast. Na vele dagen online speuren heb ik het probleem nog niet kunnen oplossen:

Ik heb 2 servers met centos. Een frontend server A met apache en een backend server B met mysql. Ik wil een predefined backupscript draaien op server B om een backup te maken naar een object store in de cloud. Het probleem is dat server B geen toegang heeft tot het internet. Nu heb ik het volgende gedaan:

- Op server A de internet facing nic een NAT router van gemaakt d.m.v.masquarade
- Op server B een default gw toegevoegd die verwijst naar de interne nic van server A

Het gevolg:

Ik kan vanaf server B pingen naar publieke ipadressen. Ik kan ook een webpagina ophalen op basis van ip maar ik kan ip's niet resolven naar een naam. Bijvoorbeeld ik kan wel 8.8.8.8 pingen en krijg een response terug maar ping maar www.google.nl werkt niet. De connectie met internet lijkt dus goed te zijn echter werkt DNS niet.

Ik heb de /etc/resolv.conf en de .conf file van de eth01 aanpast naar de juiste name/dns servers maar dat lost het probleem niet op. Ik krijg DNS niet aan de praat. Ik heb ook upd poort 53 ACCEPT toegevoegd in iptables voor zowel inbound als outbound.

Iemand enig idee waar ik verder kan zoeken of waar het probleem misschien in zit?


Dank!

[Hero of Time]

Als je gewoon verkeer heen en weer kan sturen, dan is het instellen van de juiste DNS servers genoeg. Heb je al wat meer gedaan, zoals telnetten naar de een en ander om te kijken of je wel met poort 53 naar de juiste machines kan? Simpelweg iptables aanpassen is geen garantie dat het werkt. Welke DNS servers heb je bijvoorbeeld toegevoegd? Zijn die bekend met de online namen (middels forwarding)? En als het toch maar 1 server is waar je 't heen stuurt, wat weerhoud je ervan om die in /etc/hosts te zetten?

[biggydeen2]

Veel tools zoals telnet en nslookup kan ik op die server niet gebruiken omdat deze (nog) niet geinstalleerd zijn. Een yum install kan ik niet gebruiken omdat deze vanaf het internet packages probeert te downloaden op basis van url welke de server niet kan resolven. Mij werd aangeraden om b.v. bind-utils te installeren zodat ik nslookup en dig commands kan gebruiken.

Ik heb de DNS server van Google 8.8.8.8 toegevoegd. Er stonden ook al een drietal nameservers in. De server is een kopie van de webserver waar ik wel kan resolven. Op de webserver staan dezelfde drietal nameservers ingevuld.

Wat betreft /etc/hosts ben ik vergeten te melden. Dit heb ik geprobeert maar ik weet niet precies waar het script allemaal connectie mee maakt. Ik heb een paar domeinen die ik tegenkwam in het script toegevoegd in /etc/hosts maar dat werkt helaas niet.

[thunder7]

Je zou natuurlijk op de éne server de gewenste rpms kunnen downloaden, die (met ssh/scp) naar de andere kopieren en daar installeren.

[biggydeen2]

Klopt dat heb ik ook gedaan maar dat werkt helaas niet. Tijdens de installatie maakt het script connectie naar de object store in de cloud waarbij er geauthentiseerd moet worden. Maar dat werkt helaas niet.

De installatie van het script loopt ook niet door. Vermoedelijk omdat hij probeert te authentiseren wat niet lukt maar dat kan ik helaas niet zien. Hetzelfde install script op server A werkt prima.

[ Voor 4% gewijzigd door biggydeen2 op 28-12-2015 21:48 ]

[Hero of Time]

Tools als telnet kan je ook met server A downloaden en naar server B brengen, kan je gewoon fatsoenlijk testen. Nu probeer je met een steeksleutel een spijker in een plank te meppen en een schroef vast te draaien. Dat gaat natuurlijk niet.

[biggydeen2]

Daar heb je gelijk in. Ik heb gister nog even geprobeerd om o.a. bind-utils via een rpm package te installeren op server B maar dan krijg ik missing dependenties als melding...

Zal vandaag verder kijken of ik telnet en alsnog bind-utils aan de praat krijg.

[thunder7]

Die missing dependencies geven toch aan welke rpms je eerst moet downloaden en installeren?

[biggydeen2]

Ik ben een tijd bezig geweest om die rpm packages voor bind-utils te installeren maar dat is een regelrecht drama. Wat thunder7 zegt klopt inderdaad. Ik download een rpm package vervolgens krijg ik de melding missing dependencies. Download ik vervolgens die dependencies krijg ik daar de melding dat er weer andere dependencies missen. Download ik vervolgens weer die depencies missen die weer andere dependencies.... wie dat bedacht heeft... yum install installeert alles in één keer maar dat kan ik helaas niet gebruiken.

Ik ben eerst maar gestopt met de rpm packages want dat schiet niet op. Maar misschien is daar een handige manier voor die ik nog niet heb ontdekt

Ik heb wel telnet op deze manier kunnen installeren. Als ik een telnet doe naar de webserver op poort 80 werkt dat wel maar op poort 53 geeft hij aan "no route to host". Vanaf de webserver naar de backend geeft telnet op zowel poort 80 als 53 connection refused.

Hier ga ik even verder naar kijken.

[thunder7]

Ik ben niet helemaal thuis in redhat, maar je kunt toch op server A, die wel alle correcte rpms heeft, een lijst maken van alle rpms, die vervolgens dowloaden (in een script, wget ofzo) en dan in 1x installeren op systeem B ?

[Hero of Time]

Telnet is even genoeg. Waarom probeer je een telnet verbinding op poort 53 te maken naar server A? Die heeft helemaal geen DNS service draaien. Je moet juist kijken of je via die server juist het internet op kan over die poort. Dus 'telnet 8.8.8.8 53' en gaan. Werkt dat, mooi, dan zou 'nameserver 8.8.8.8' in /etc/resolve.conf je een werkende DNS moeten geven.

Werkt het niet, dan ga je met andere tools aan de slag. Een daarvan is tcptraceroute, iets wat ik veel gebruik bij problemen. Standaard traceroute gebruikt icmp en dat wordt vaak geblokkeerd. Met tcptraceroute maak je een TCP verbinding op de aangegeven poort. Bijvoorbeeld een traceroute naar een webserver heeft niet altijd zin. Tcptraceroute ernaar wel, want poort 80 is open en krijg je wel antwoord.

[biggydeen2]

Dank voor de antwoorden.

@thunder7

Dat zou goed kunnen. Ik heb hier weinig ervaring mee. Ik wil de systemen wel clean houden aangezien het om "live" servers gaat. Sommige zaken zijn nog een beetje onduidelijk.

@HeroofTime

Daar heb je gelijk in. telnet 8.8.8.8 53 vanaf de backend werkt niet. No route to host. Vanaf de webserver werkt het wel. Ik ga tcptraceroute even proberen en verder onderzoeken. Dank!

[Blokker_1999]

Als je niet met live servers wenst te knoeien, is het dan niet aan te raden om de setup even na te bouwen in een gevirtualiseerde omgeving? Niet alle services zullen moeten draaien en geconfigureerd zijn, gewoon 2 kale servers. 1 met NAT en de andere die de NAT gebruikt voor internet. Dan gewoon even de firewall instellingen overnemen en kijken of je hetzelfde resultaat bekomt. Dan kan je in je virtuele omgeving op zoek gaan naar de oplossing.

[ Voor 8% gewijzigd door Blokker_1999 op 30-12-2015 09:02 ]

[biggydeen2]

Dat is inderdaad wel de beste manier. Daar ben ik ook al even mee bezig geweest maar kost ook veel tijd om goed te configureren. De servers draaien in de Cloud en kan ik ook niet even snel een kopie van downloaden. Een extra test omgeving opzetten in de Cloud kost weer extra geld. Ik ben wel van plan om hier een testomgeving voor te maken want dat is uiteindelijk vanuit beheer/test oogpunt onvermijdelijk.

Ik ben er van overtuigt dat het een simpel iets is. Verkeer wordt geblokkeerd of niet goed gerouteerd.

Update:

Traceroute krijg ik niet geinstalleerd. NMAP wel. Aantal port scans gedaan en poort 53 (DNS) is niet bereikbaar. Op aanraden heb ik dnsmasq geinstalleerd omdat het resolven vanuit de hostfile wel werkt naar buiten toe en op deze manier al het DNS verkeer via dnsmasq via een wildcard in de hostfile naar buiten te laten gaan. Nog niet succesvol. Daarnaast is port 53 nog steeds geblokkeerd. Volgens mij hoort deze poort open te staan om DNS verkeer te ontvangen/versturen.

[ Voor 32% gewijzigd door biggydeen2 op 31-12-2015 09:58 ]

[biggydeen2]

Update:

Inmiddels weer vele dingen geprobeerd. Het lijkt niet aan de firewall te liggen op de DB server. Het lijkt er op dat de netwerk routes nog niet helemaal goed zijn. Telnet naar 8.8.8.8 53 vanaf de webserver werkt goed. Vanaf de backend krijg ik "no route to host"

Vanaf de backend naar localhost op poort 53 of 80 geeft connection refused. Dat klopt want ik heb geen services draaien die op deze poorten luisteren. Echter als ik vanaf de webserver een telnet naar de backend doe op poort 80 krijg ik connection refused maar op poort 53 no route to host.

Ik kan vanaf de backend wel een telnet doen naar de webserver op poort 80. Een ping naar tweakers.net werkt vanaf de backend maar een telnet op poort 80 geeft no route to host terwijl dit op de webserver wel werkt.

Ik heb de volgende settings gebruikt op de huidige routes te genereren:

Op webserver eth0 (internet facing):
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sysctl net.ipv4.ip_forward=1

Op backend een default gateway toegevoegd naar het interne ip van de webserver.

Aan de andere kant is het ook wel vreemd dat een telnet vanaf de webserver op poort (backend) 22 (ssh) en 80 wel werkt en op 53 niet. Firewall op backend staat uit.

[ Voor 7% gewijzigd door biggydeen2 op 02-01-2016 11:53 ]

[_-= Erikje =-_]

DNS is over het algemeen een UDP service, telnet op poort 53 is TCP dus dat hoeft niet te werken (geen idee of google DNS tcp doet

Aan de andere kant is het ook wel vreemd dat een telnet vanaf de webserver op poort (backend) 22 (ssh) en 80 wel werkt en op 53 niet. Firewall op backend staat uit.

Huh? je probeert naar 53 te telnetten op je backend? heb je daar bind of een andere DNS server op draaien dan?

[ Voor 73% gewijzigd door _-= Erikje =-_ op 02-01-2016 11:59 ]

[biggydeen2]

Dank voor je reactie.

1. Klopt
2. ik heb een default route toegevoegd naar de webserver. Ik kan externe ip adressen vanaf de backend pingen
3. Zodra een DNS packet groter wordt dan x dan wordt TCP gebruikt volgens mij. En bij zone transfers.

Maar ik kan vanaf de webserver wel een telnet doen naar 8.8.8.8 53 dus dat verkeer wordt op de webserver of extern niet geblokkeerd. Een telnet vanaf de backend naar 8.8.8.8 werkt echter niet. Het enige wat wel lijkt te werken naar buiten toe is ping.

_-= Erikje =-_ schreef op zaterdag 02 januari 2016 @ 11:58:

Huh? je probeert naar 53 te telnetten op je backend? heb je daar bind of een andere DNS server op draaien dan?

Puur als test. Telnet op een poort werkt namelijk wel ook al draait er niks op die poort. In dat geval krijg je een connection refused. Dat geeft aan dat de verbinding er wel is maar er niks op de poort luistert. Vanaf de webserver krijg ik connection refused op poort 80 maar op poort 53 no route to host.

[ Voor 37% gewijzigd door biggydeen2 op 02-01-2016 12:11 ]

[DiedX]

En wat als je nu iets van unbound op je frontend installeert, en die gebruikt als resolver?

Edit: Heb je wel nagedacht over patchmanagement met deze? En hoe kan je wél iets aan het internet hangen maar geen idee hebben hoe het geconfigureerd moet worden?

[ Voor 49% gewijzigd door DiedX op 02-01-2016 12:17 ]

[biggydeen2]

Dat zou een optie kunnen zijn. Maar ik wil eerst begrijpen waarom het nu niet werkt. Ik zou gewoon een publieke DNS moeten kunnen gebruiken vanaf de backend.

[DiedX]

Telnet werkt (zover ik weet) nog steeds met TCP, terwijl DNS UDP is. Je kan wel iets van NetCat gebruiken.

Als je iptables -L geeft op je backend, wat komt er dan uit je firewall zetten?

Op backend een default gateway toegevoegd naar het interne ip van de wegserver.

Ik neem aan dat je een route bedoeld? Als dit echt je default gateway is, dan snap ik niet waarom je pings aankomen.

Vragen voor de zekerheid:

* Beide systemen hangen in hetzelfde datacentrum?
* Beide systemen hebben een 'extern' en een 'intern' IP-Adres? Extern is voor mij: direct benaderbaar vanaf het internet. Intern zie ik als RFC 1918
* Beide systemen zijn met elkaar verbonden via een tweede NIC

[biggydeen2]

Ik heb een default gateway( geen route) ingesteld naar de webserver. Deze gaat vervolgens naar buiten toe. Er zit verder geen router o.i.d. tussen.

- Beide systemen hangen in hetzelfde datacentrum
- Alleen de webserver heeft een extern ip (en een itern ip). De backend heeft alleen een intern ip
- De webserver is verbonden met de backend via de interne NIC

[DiedX]

Duidelijk. Heb je de volledige iptables -L voor ons van de frontend? Kunnen we daar even meekijken

[biggydeen2]

Jazeker:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
INPUT_direct  all  --  anywhere             anywhere            
INPUT_ZONES_SOURCE  all  --  anywhere             anywhere            
INPUT_ZONES  all  --  anywhere             anywhere            
ACCEPT     icmp --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
FORWARD_direct  all  --  anywhere             anywhere            
FORWARD_IN_ZONES_SOURCE  all  --  anywhere             anywhere            
FORWARD_IN_ZONES  all  --  anywhere             anywhere            
FORWARD_OUT_ZONES_SOURCE  all  --  anywhere             anywhere            
FORWARD_OUT_ZONES  all  --  anywhere             anywhere            
ACCEPT     icmp --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited
ACCEPT     all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
OUTPUT_direct  all  --  anywhere             anywhere            

Chain FORWARD_IN_ZONES (1 references)
target     prot opt source               destination         
FWDI_public  all  --  anywhere             anywhere            [goto] 
FWDI_public  all  --  anywhere             anywhere            [goto] 
FWDI_public  all  --  anywhere             anywhere            [goto] 

Chain FORWARD_IN_ZONES_SOURCE (1 references)
target     prot opt source               destination         

Chain FORWARD_OUT_ZONES (1 references)
target     prot opt source               destination         
FWDO_public  all  --  anywhere             anywhere            [goto] 
FWDO_public  all  --  anywhere             anywhere            [goto] 
FWDO_public  all  --  anywhere             anywhere            [goto] 

Chain FORWARD_OUT_ZONES_SOURCE (1 references)
target     prot opt source               destination         

Chain FORWARD_direct (1 references)
target     prot opt source               destination         

Chain FWDI_public (3 references)
target     prot opt source               destination         
FWDI_public_log  all  --  anywhere             anywhere            
FWDI_public_deny  all  --  anywhere             anywhere            
FWDI_public_allow  all  --  anywhere             anywhere            

Chain FWDI_public_allow (1 references)
target     prot opt source               destination         

Chain FWDI_public_deny (1 references)
target     prot opt source               destination         

Chain FWDI_public_log (1 references)
target     prot opt source               destination         

Chain FWDO_public (3 references)
target     prot opt source               destination         
FWDO_public_log  all  --  anywhere             anywhere            
FWDO_public_deny  all  --  anywhere             anywhere            
FWDO_public_allow  all  --  anywhere             anywhere            

Chain FWDO_public_allow (1 references)
target     prot opt source               destination         

Chain FWDO_public_deny (1 references)
target     prot opt source               destination         

Chain FWDO_public_log (1 references)
target     prot opt source               destination         

Chain INPUT_ZONES (1 references)
target     prot opt source               destination         
IN_public  all  --  anywhere             anywhere            [goto] 
IN_public  all  --  anywhere             anywhere            [goto] 
IN_public  all  --  anywhere             anywhere            [goto] 

Chain INPUT_ZONES_SOURCE (1 references)
target     prot opt source               destination         

Chain INPUT_direct (1 references)
target     prot opt source               destination         

Chain IN_public (3 references)
target     prot opt source               destination         
IN_public_log  all  --  anywhere             anywhere            
IN_public_deny  all  --  anywhere             anywhere            
IN_public_allow  all  --  anywhere             anywhere            

Chain IN_public_allow (1 references)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http ctstate NEW
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:smtp ctstate NEW
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh ctstate NEW
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:https ctstate NEW
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:imaps ctstate NEW
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:mysql ctstate NEW

Chain IN_public_deny (1 references)
target     prot opt source               destination         

Chain IN_public_log (1 references)
target     prot opt source               destination         

Chain OUTPUT_direct (1 references)
target     prot opt source               destination

[ Voor 0% gewijzigd door Hero of Time op 02-01-2016 13:55 . Reden: Leesbaarder ]

[biggydeen2]

Update:

Ik ben erin geslaagd de firewall op de frontend te disablen en vervolgens NAT weer toe te voegen. In dat geval werkt DNS op de backend

Dit lost niet direct het probleem op maar ik weet in ieder geval waar ik verder moet zoeken. Heeft iemand een idee welke regel (uit bovenstaande output) het probleem kan veroorzaken?

[thunder7]

Waar komen die iptables regels vandaan? Meerdere regels staan er tot 3x identiek in, lijkt het. Dat kan toch niet kloppen?

[biggydeen2]

Dit is een standaard image vanuit de cloud. Ik heb wel een aantal regels toegevoegd dus daar zou het van kunnen komen. Ik vond het ook al vreemd. DNS probleem is opgelost door de volgende regels toe te voegen:


iptables -I FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -I FORWARD -i eth1 -o eth0 -j ACCEPT

Oftewel om forwarding toe te laten op de interfaces. Deze rules heb ik al eerder toegevoegd alleen met iptables -A ipv -I. De regels worden daardoor onderaan gezet onder een reject. Deze regels gaan dus nooit werken. Met -I insert je de rules bovenin de iptable rules (of een aangewezen plek door een nummer mee te geven).

Een wget "website" levert helaas nog niet het gewenste resultaat op. Op server A wordt de index.html direct gedownload maar op server B krijg ik een error: 301 moved permanently. Het backup script welke ik wil gebruiken op server B loopt vast op HTTPS welke hij niet kan downloaden. Het lijkt erop dat verkeer verkeer op poort 80/443 nog geblokkeerd wordt door iptables op server A.

Ik ga weer verder zoeken:)

[ Voor 24% gewijzigd door biggydeen2 op 04-01-2016 22:12 . Reden: Probleem nog niet opgelost ]

[Kees]

Met -v -x bij iptables krijg je de counters te zien, dan is het gewoon een kwestie van dat commando te refreshen om te zien welke rules er getriggered worden.

Deze firewall config is echter vrij nutteloos, want alle chains (input, forward, output) zullen altijd alles accepteren (door de 2de regel), we zullen dus de output voor de nat table moeten zien (-t nat)

[biggydeen2]

Er staat inderdaad overal accept anywhere, dan heeft een firewall weinig nut

Ik heb inmiddels het probleem opgelost .Het is mij niet helemaal duidelijk waarom het vanochtend opeens wel werkte. Het backup script werkte gisteravond niet en liep vast op HTTPS url's. Vanochtend weer een paar keer wget HTTPS geprobeerd en dat werkte wel. Vervolgens het backupscript gedraait en deze werkt ook.

Ik heb gisteravond een rule toegevoegd om 443 verkeer toe te laten/forwarden.

Het zat in ieder geval op de webserver. Ondanks dat het toch even geduurd heeft heb ik veel geleerd.

[ Voor 7% gewijzigd door biggydeen2 op 05-01-2016 11:16 . Reden: extra info ]