Netwerk tips

Hier staan netwerk tips.

1. debug smtp

Soms lukt het niet om mail te versturen naar een bepaald adres of domein. Het kan dan zin hebben om de mail via losse commando's direct bij de tegenpartij af te leveren om zo misschien te kunnen zien wat er mis gaat.
Via het commando "dig mx domain.nl" of "nslookup -type=mx domain.nl" krijgen we de mailserver(2) te zien.
telnet [mailserver.ext] 25

helo sjaak
MAIL FROM: 
RCPT TO: 
DATA
Subject: testbericht via telnet

Dit is een testbericht via telnet om te zien of de mail werkt en zo nee waarom niet.
.
quit
[boven]

2. cisco acl tbv windows domain member in DMZ

Om een windows domain member server in een DMZ te laten praten met zijn domein moet er een reeks poorten opengezet worden naar de servers. In onderstaand voorveeld heeft de DMZ server ip adres 192.168.4.5 en de servers zitten in de reeks 10.10.10.0/24.
Hier moet wel eventueel verkeer naar buiten aan toegevoegd worden als dat nodig is.
In dit geval gaat het niet zozeer om de cisco acl als wel om de poorten die open moeten. Vergeet niet te letten op udp of tcp.
access-list DMZ_access_in permit udp host 192.168.4.5 10.10.10.0 255.255.255.0 eq nameserver
access-list DMZ_access_in permit tcp host 192.168.4.5 10.10.10.0 255.255.255.0 eq domain 
access-list DMZ_access_in permit udp host 192.168.4.5 10.10.10.0 255.255.255.0 eq domain 
access-list DMZ_access_in permit udp host 192.168.4.5 10.10.10.0 255.255.255.0 eq 88 
access-list DMZ_access_in permit tcp host 192.168.4.5 10.10.10.0 255.255.255.0 eq 88 
access-list DMZ_access_in permit udp host 192.168.4.5 10.10.10.0 255.255.255.0 eq ntp
access-list DMZ_access_in permit udp host 192.168.4.5 10.10.10.0 255.255.255.0 eq 135 
access-list DMZ_access_in permit tcp host 192.168.4.5 10.10.10.0 255.255.255.0 eq 135 
access-list DMZ_access_in permit tcp host 192.168.4.5 10.10.10.0 255.255.255.0 eq 137 
access-list DMZ_access_in permit udp host 192.168.4.5 10.10.10.0 255.255.255.0 eq netbios-ns 
access-list DMZ_access_in permit udp host 192.168.4.5 10.10.10.0 255.255.255.0 eq netbios-dgm 
access-list DMZ_access_in permit tcp host 192.168.4.5 10.10.10.0 255.255.255.0 eq netbios-ssn 
access-list DMZ_access_in permit tcp host 192.168.4.5 10.10.10.0 255.255.255.0 eq imap4
access-list DMZ_access_in permit udp host 192.168.4.5 10.10.10.0 255.255.255.0 eq 389 
access-list DMZ_access_in permit tcp host 192.168.4.5 10.10.10.0 255.255.255.0 eq ldap
access-list DMZ_access_in permit tcp host 192.168.4.5 10.10.10.0 255.255.255.0 eq https
access-list DMZ_access_in permit tcp host 192.168.4.5 10.10.10.0 255.255.255.0 eq 445 
access-list DMZ_access_in permit udp host 192.168.4.5 10.10.10.0 255.255.255.0 eq 445 
access-list DMZ_access_in permit tcp host 192.168.4.5 10.10.10.0 255.255.255.0 eq 686 
access-list DMZ_access_in permit tcp host 192.168.4.5 10.10.10.0 255.255.255.0 eq 691 
access-list DMZ_access_in permit tcp host 192.168.4.5 10.10.10.0 255.255.255.0 eq 993 
access-list DMZ_access_in permit tcp host 192.168.4.5 10.10.10.0 255.255.255.0 eq 1025
access-list DMZ_access_in permit tcp host 192.168.4.5 10.10.10.0 255.255.255.0 eq 1026
access-list DMZ_access_in permit tcp host 192.168.4.5 10.10.10.0 255.255.255.0 eq 1027
access-list DMZ_access_in permit tcp host 192.168.4.5 10.10.10.0 255.255.255.0 eq 1028
access-list DMZ_access_in permit tcp host 192.168.4.5 10.10.10.0 255.255.255.0 eq 3050
access-list DMZ_access_in permit tcp host 192.168.4.5 10.10.10.0 255.255.255.0 eq 3268
access-list DMZ_access_in permit tcp host 192.168.4.5 10.10.10.0 255.255.255.0 eq 5632
access-list DMZ_access_in permit tcp host 192.168.4.5 10.10.10.0 255.255.255.0 eq 8085
access-list DMZ_access_in permit tcp host 192.168.4.5 10.10.10.0 255.255.255.0 eq 8192
access-list DMZ_access_in permit tcp host 192.168.4.5 10.10.10.0 255.255.255.0 eq 8194
[boven]

3. Snelle mailtest

Om, bijvoorbeeld na wat akties of een storing, snel de mailfunctionaliteit te testen kun je natuurlijk een email sturen naar een los mailaccount en dat via de webmail checken en weer terugsturen maar er is een handig en zeer snel alernatief.
Stuur een email naar echo@tu-berlin.de en je krijgt een antwoord terug. Zet wel de prioriteit hoog dan heb je binnen een minuut het antwoord terug.

[boven]

4. Lookup outgoing IP adres

Hieronder enkele voorbeelden van websites waar je snel even je uitgaande ip adres kunt opzoeken. Dit geldt dan alleen voor poort 80; het kan zijn als policy based routing is toegepast dat andere protocollen op een ander uitgaand ip adres of zelfs reeks naar buiten gaan.

www.myipaddress.com werkt ook goed met elinks textbrowser. myip.dnsomatic.com geeft alleen ip adres als uitvoer www.watismijnip.nl nederlandse site met tevens overzicht van browser en plugins
Met name de middelste is handig als je je outside ip adres wilt gebruiken in shell scripts. Deze heeft namelijk al als enige uitvoer het ip adres zodat je dat niet zelf hoeft te filteren.
wget myip.dnsomatic.com -q -O -
[boven]

5. arp-scan

Onder linux is er het programma arp-scan, te vinden in de meeste repositories. Het scant een subnet door arp requests te sturen en te zien wat er terug komt. Het voordeel hiervan is dat er geen poorten hoeven open te staan en de host niet hoeft te reageren op ping. Het nadeel is dat het alleen op aangesloten subnetten werkt en niet over een router omdat arp alleen voor de lokale link is.
Installeren gebeurt, afhankelijk van de distributie, bijvoorbeeld met: "sudo apt-get install arp-scan".
Het programma moet gedraaid worden als root (sudo).
$ sudo arp-scan 192.168.2.0/24
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.8.1 with 256 hosts (http://www.nta-monitor.com/tools/arp-scan/)
192.168.2.105	00:24:81:f6:b4:da	Hewlett Packard
192.168.2.151	00:c0:3d:02:2f:db	WIESEMANN & THEIS GMBH
192.168.2.200	00:80:f0:8b:53:ff	Panasonic Communications Co., Ltd.
192.168.2.251	c0:c1:c0:2b:56:6c	Cisco-Linksys, LLC
192.168.2.254	00:13:c4:16:9e:27	Cisco Systems
[boven]

6. unix shell op internet

Vaak is het handig om een nieuwe nat translatie van buitenaf te kunnen testen of de werking van binnenkomende mail om maar wat te noemen.
Dds is een van de weinige providers die een shell account leveren bij een basis account (30 euro per jaar) en geen poorten blokkeren vanaf hier, zelfs poort 25 niet.
Verder is gebruik te maken van o.a. ping, traceroute en nmap.
[boven]

7. google dns is slecht

Google heeft jaren geleden de overbekende google publieke dns servers opgezet te weten 8.8.8.8 en 8.8.4.4. Ideaal als veel mensen deze dns gebruiken want google weet dan waar mensen naartoe surfen en hoe vaak. Dus google adverteerde met deze dns want die zou sneller zijn dan die van de eigen provider. Echter na zoveel jaren gebruikt de halve wereld deze dns servers en toen heeft google besloten om het verkeer te throthlen bij meer dan zoveel requests. Op internet zijn metingen te vinden dat gogole nu eenderde langzamer is dan de gemiddelde isp dns. Dat is een goede reden om die dns niet meer te gebruiken.

Enige tijd geleden liep ik tegen een issue aan dat mail van bepaalde partijen werd afgeleverd op hogere MX records en soms kreeg de afzender een delayed melding en kwam de mail een uur of 2 uur later aan terwijl er 7 prima werkende MX records zijn om de mail af te leveren. Beide zaken zijn mijns inziens alleen te verklaren door een leeg antwoord bij een dns request. Afleveren bij een hogere MX als de lagere een leeg antwoord geeft bij de host resolving en een delayed als er een leeg antwoord komt op een mx resolving.
Ik heb hier met een van de partijen lang naar gezocht en het bleek dat ze google dns gebruikten. Ik herinnerde me het artikel dat ze gingen throthlen maar had geen idee hoe dat zich precies uitte. Hierop een simpel script geschreven dat achter elkaar (niet parallel) flink wat requests deed en gekeken naar de response en inderdaad kwam een deel van de antwoorden steeds trager, soms echt seconden later, en soms kwam er een leeg antwoord terug. Wat me wel verbaasde toen ik dat script op verschillende plekken ging draaien is dat ik via de ene provider nooit een leeg antwoord kreeg en bij andere regelmatig; dit kan ook aan de firewall liggen natuurlijk.

De bewuste partij heeft toen de google dns servers vervangen door die van de isp en de problemen met vertraagde mail en mail op hogere MX-en waren weg. Ik heb later nog drie keer gezien dat er veel mail op hogere MX-en binnenkwam en bij navraag bleek dat die partijen steeds gebruik maakten van google dns. Een beheerder deed toen handmatig wat mx lookups op hun mailserver en zag inderdaad soms een leeg antwoord terug komen.
Bij een partner zagen we een tijdje later dat een leverancier de google dns servers op de publieke wifi had gezet zonder een interne dns server ertussen. Met gemiddeld 20 gebruikers op de publieke wifi kwam dat toch uit op 210.000 requests per werkdag (2200 per 5 minuten, google zegt dat 500 per 5 minuten het maximum is sinds het throthlen). Omzetten gaf een merkbare snelheidswinst.

Bovenstaande zaken zijn niet van extreem belang maar zijn wel prettig om te weten. Vorige week hebben we spf/dkim en dmarc geinstalleerd en wederom liepen we tegen vaagheden aan die terug te herleiden waren tot lege dns antwoorden. Zo gaf een dmarc report van een bepaald domein 32x pass op een ip adres en 2x een fail op datzelfde ip adres bij spf, de fail bij policy dus dan zou het txt record voor spf een leeg antwoord gegeven hebben. Ook dkim geeft een fail bij de results soms dus dan is de mail wel gesigned (policy) maar de publieke key niet gelezen. Voor spf is dat geen drama behalve dat spf niet werkt maar alle mail komt wel aan. Wat betreft dkim en dmarc zijn er dus geen consequenties te hangen aan fails want dan wordt mail soms ten onrechte gedropt.

Mijn conclusie is toch wel dat voldoende is aangetoond dat het gebruik van de google publieke dns servers soms lege antwoorden oplevert en dat dat soms vervelende gevolgen heeft. Gebruikers van die dns servers blijken zich daar totaal niet van bewust te zijn.
[boven]

Website door Wouter Barendsen, 2005-2016