Bekijk Volledige Versie : Blokkeren van UDP requests
De afgelopen dagen leek er plotseling een netwerk probleem te zijn tussen een van onze servers en een server andere partij. De verbinding tussen de twee was prima, maar een traceroute stopte iedere keer op dezelfde plek. Leuk probleem om uit te leggen aan een klant, vooral als het buiten je eigen netwerk ligt.
In ieder geval, achteraf bleek dat in dit netwerk ergens UDP requests geblokkeerd werden. Als je de traceroute over ICMP liet lopen werkte het prima. Wij hebben geen direct contact met dit netwerk maar ik was eigenlijk wel nieuwsgierig of dit normaal is. Is er een reden te bedenken waarom dit bijvoorbeeld veiliger is?
systemdeveloper
14/09/11, 14:36
Hmm, heb ik toevallig gehad met een hp switch die plots geen udp traffic meer doorgaf. Dus het kan een technisch probleem zijn omdat het recent opgetreden is.
Van de andere kant... als je geen nfs/dns over udp in dat deel van het netwerk toestaat dan is er niks op tegen om udp te blokken. Kan een hoop ellende schelen in sommige gevallen zoals een udp flood.
Zijn wel meer dedi/colo boeren die UDP blokkeren, of je IP automatisch blokkeren als je meer dan een paar UDP pakketjes per seconde stuurt.
We gebruiken SNMP (UDP) voor het monitoren van onze servers, omdat je daar niet alleen mee kan zien dat een host "up" is, maar ook mooie grafiekjes van CPU en HDD gebruik kan maken.
En het is wel eens voorgekomen dat het IP van onze monitor bak geblokkeerd is. ->|
SebastiaanStok
14/09/11, 20:08
DNS gebruikt ook UDP.
ICMP is een informatie protocol, geen data laag.
http://nl.wikipedia.org/wiki/Internet_Control_Message_Protocol
Je kan dus niet iets over ICMP laten lopen, alleen over UDP of TCP.
Wel is het mogelijk om bepaalde ICMP pakketten zoals ping (echo) te blokkeren.
Dit word soms gedaan om aanvallen te voorkomen, een ping geeft niets terug.
Dus weet je niet of de host nog werkt.
MediaServe
14/09/11, 20:56
Bovendien loopt Voip verkeer (RTP) over UDP, dat is niet erg handig om te blokkeren.
Zelfde verhaal, maar nog niet opgelost. De problemen zijn er nog steeds.
De situatie is als volgt:
server A -> NAT -> groep van 8 servers, laten we deze server 1 t/m 8 noemen.
De 8 servers draaien niet bij ons. Vanuit deze 8 servers worden of tegelijk of om de zoveel tijd een request verzonden naar de server. Dit is de test case:
* server 1 -> poort 80 naar server A -> test OK
* server 2 -> poort 443 naar server A -> test FAILED
Server A krijgt beide requests binnen volgens tcpdump maar stuurt op de tweede gewoon geen reply. Ik zie alleen 3 SYN requests vanuit het NAT IP adres. Geen flauw idee waar ik het moet zoeken eerlijk gezegd. Als ik de test vanuit een andere NAT lokatie verstuur (ons kantoor) van verschillende machines heb ik geen enkel probleem. Ik neig dus naar een probleem in de NAT van de groep van 8 servers, maar hoe of wat precies, geen idee.
Zelfde verhaal, maar nog niet opgelost. De problemen zijn er nog steeds.
De situatie is als volgt:
server A -> NAT -> groep van 8 servers, laten we deze server 1 t/m 8 noemen.
De 8 servers draaien niet bij ons. Vanuit deze 8 servers worden of tegelijk of om de zoveel tijd een request verzonden naar de server. Dit is de test case:
* server 1 -> poort 80 naar server A -> test OK
* server 2 -> poort 443 naar server A -> test FAILED
Server A krijgt beide requests binnen volgens tcpdump maar stuurt op de tweede gewoon geen reply. Ik zie alleen 3 SYN requests vanuit het NAT IP adres. Geen flauw idee waar ik het moet zoeken eerlijk gezegd. Als ik de test vanuit een andere NAT lokatie verstuur (ons kantoor) van verschillende machines heb ik geen enkel probleem. Ik neig dus naar een probleem in de NAT van de groep van 8 servers, maar hoe of wat precies, geen idee.
Huh ?
Klopt je omschrijving wel ?
Je zegt "server A krijgt een pakket binnen maar stuurt geen antwoord", en dan denk je dat de oorzaak buiten server A ligt ?
Zoeken op server A lijkt me, wat er is met die tweede SYN dat er geen antwoord op komt ...
firewall rules op poort 443 op server A?
Nee, geen firewall rules. Er draait CSF op de server maar disabled met dezelfde resultaten.
Je zegt "server A krijgt een pakket binnen maar stuurt geen antwoord", en dan denk je dat de oorzaak buiten server A ligt ?
Nouja, ik neig die richting op. Als ik dezelfde test van een andere NAT lokatie uitvoer krijg ik wel gewoon antwoord. Vanuit iedere lokatie waar ik vandaan test gaat het goed, behalve bij de groep 1 t/m 8.
Nee, geen firewall rules. Er draait CSF op de server maar disabled met dezelfde resultaten.
Nouja, ik neig die richting op. Als ik dezelfde test van een andere NAT lokatie uitvoer krijg ik wel gewoon antwoord. Vanuit iedere lokatie waar ik vandaan test gaat het goed, behalve bij de groep 1 t/m 8.
Tsja, maar het blijft die server die wel een syn binnenkrijgt maar niets terugstuurt.
Dan moet je toch eerst uitzoeken wat voor excuus die server gebruikt om geen antwoord te geven.
corrupte checksum, eigen nat rules, echt heel zeker geen firewall .
Maak een capture file , en bekijk die met wireshark, dan zie je vrij makkelijk of er iets mis is met de pakketten.
Pas als je weet waarom die server op die pakketten geen antwoord wil geven, kun je je gaan afvragen of dat elders veroorzaakt wordt.
Eigenlijk kan ik alleen corruptie van het pakket verzinnen als echt externe oorzaak.