Re: Nameservice klemmt

From: Tom Beer <mailings(at)analogon.com>
Date: Wed, 14 Nov 2001 09:22:47 +0100

Hi,

also die informationslage ist äußerst nebulös.
Dass mit ipf, was du anscheinend benutzt
keine packets geblockt werden kann ja daran liegen,
dass du keine matching rule hast oder dass gar keine
durchgehen. ein paar dumps wären nicht verkehrt.
Wieso läuft denn auf beiden kisten nat? wie sind
die kisten miteinander verbunden. wie ist das
interne routing geregelt, insbes. default route?
fang aber vielleicht selber erst mal mit einem tcpdump
auf allen interfaces gleichzeitig an wenn dir das möglich ist.

> On Tue, Nov 13, 2001 at 04:19:21PM +0100, Oliver Fromme wrote:
>
> > > Wie kann ich sowas debuggen?
> >
> > Schau erstmal Deine /etc/host.conf und /etc/resolv.conf an.
> > Man kann ja nie wissen.
>
> Vielen Dank fuer die vielen Antworten. Vielleicht muss ich das Netz noch
> etwas genauer beschreiben. Das Netzwerk soll in einigen Wochen an eine
> feste Verbindung an das Internet angeschlossen werden und wir
> konstruieren gerade eine DMZ mit einem inneren und einem aeusseren
> Router. Da die Leitung und der Bastion Host noch nicht da sind, haben wir
> den aeusseren Router via ISDN mit unserem Provider verbunden. Auf diesem
> Router (aktuelles BSD) laeuft im Moment auch ein Paketfilter. Auf dem
> inneren Router, der spaeter die Paketfilterung uebernehmen soll, laeuft
> ein Filter mit Regeln, aehnlich denen auf dem aeusseren Router. An den
> inneren Router sind mehrere interne Subnetze angeschlossen. Das DNS
> Problem haben alle.
>
> Da, wie schon gesagt, der Bastion Host noch fehlt, sind die beiden Router
> direkt miteinander verbunden. Aus dem gleichen Grund laeuft im Moment
> noch ein transparenter http Cache auf dem inneren Router.
>
> In der DMZ laeuft noch kein Nameservice. Deshalb sind auf beiden
> Routern in der resolv.conf die Nameserver unseres Providers
> eingetragen. Die beiden Router kennen sich und die wichtigsten
> Server der internen Netze aber via /etc/hosts. Die resolv.conf
> beider Router ist so eingestellt, dass zuerst in /etc/hosts und
> dann erst im bind nachgesehen wird. Im internen Netz laeuft dagegen
> der Nameserver schon. Hier sind die Nameserver des Providers als
> "forwarders" eingetragen.
>
> Um das Ganze abzurunden, laeuft auch auf beiden Routern nat. Alle
> Anfragen aus dem internen Netz werden am inneren Router auf IP Adressen
> aus der DMZ und auf aeusseren Router auf die oeffentliche Adresse
> umgesetzt.
>
> Wir bieten noch keine Dienste nach aussen an und waehlen nur zu
> Testzwecken raus.
>
> Was die Filterregeln auf den Routern angeht so ist dort nicht viel Voodoo
> dabei. Das "gefaehrlichste" sind einige keep state statements. Ich habe
> gerade nochmal auf dem aeusseren Router nachgesehen und noch nicht ein
> Paket in einer block rule. Das Problem mit dem wackligen DNS hatten wir
> aber noch bevor der innere Router stand. Mit meinem Provider stehe ich
> natuerlich auch in Kontakt. Vielleicht liegt das Problem auch dort. Man
> kann ja nie wissen.
>
> Hoffentlich habe ich jetzt genuegend Informationen fuer potentielle
> Angreifen geliefert. ;-) Eventuelle hat aber doch noch jemand einen "Bug"
> in dieser Konstruktion gefunden. Ansonsten bleibt wohl wirklich nur noch
> tcpdump.
>
> Vielen Dank fuer das Interesse
> Matthias
>
>
> To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
> with "unsubscribe de-bsd-questions" in the body of the message
>
>

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Wed 14 Nov 2001 - 09:23:01 CET

search this site