Archive for the ‘IPv4’ Category

Zugewiesene IP-Adressen von unbekannten Netzwerkgeräten mittels MAC-Adresse ausfindig machen

2 Oktober 2019

Bei aktuellen Betriebssystemen gibt es zig Protokolle, wie man die IP-Adresse von Netzwerkgeräten ausfindig machen kann. da wäre mDNS, Bonjour, LLMNR, SSDP, NDP, UPNP usw. usf. Alle bewegen sich auf unterschiedlichen Schichten. Der Klassiker der Zuordnung zwischen IP-Adresse und Gerät ist aber die MAC-Adresse. Jedes Netzwerkgerät hat eine MAC-Adresse. Wenn man also die MAC-Adresse eines Geräts kennt, wie kann man die zugehörige IP-Adresse rausfinden, wenn keines der obigen Discovery Protokolle aktiv ist bzw. unterstützt wird?

Gehen wir davon aus, dass das zu ermittelnde Gerät auf den DHCP-Modus eingestellt ist und somit seine IPv4-Adresse von einem DHCP-Server im Netz bekommt. Nun könnte man auf diesem Server nachschauen, wie die IP-Adresse lautet. In der Praxis hat man aber nicht immer diese Möglichkeit wegen verschlampter Passwörter und dergleichen. Gehen wir weiter davon aus, dass wir uns in einem üblichen privaten IPv4 Netz mit dem Adressraum 192.168.0.x bewegen.

In diesem Fall könnte man alle Adressen von 192.168.0.0 bis 255 anpingen, falls keine Firewall die Pakete filtert. Das betreffende Gerät würde ein Antwort ICMP-Paket schicken und würde sich damit verraten, bzw. bekannt machen.

Ping.exe 192.168.0.0

Dieser Vorgang kann aber recht mühsam werden, wenn man alle Adressen von Hand eintippen würde. Außerdem schickt Ping 4 Pakete (unter Windows) ab und wartet jeweils eine Sekunde auf eine Antwort.

Für das erste Problem kann man Powershell bemühen und einfach das anpingen automatisieren:

0..255 | % {Ping.exe 192.168.0.$_}

Damit würde man vom gesuchten Gerät irgendwann eine Pingantwort bekommen. Die Vorgehensweise hat allerdings zwei Haken, weil jede Anfrage immer ca. 4 Sekunden dauert. Bei 256 Adressen *4 hat man eine Wartezeit von 1024 Sekunden, also über 17 Minuten. Diese Zeit gilt aber auch nur, wenn ein Gerät auf der Gegenseite antwortet. Wenn das Paket ins Leere läuft, dann dauert es pro Paket 4 Sekunden, also im schlimmsten Fall über eine Stunde! Das ist unpraktikabel. Zum Glück kann aber die Anzahl der Pakete von Ping mittels Parameter N eingestellt werden, also optimiert:

0..255 | % {Ping.exe 192.168.0.$_ –n 1}

Damit bekommt man eine deutliche Geschwindigkeitssteigerung hin.

Aber es gibt noch eine weitere Optimierungsmöglichkeit. Man kann den sogenannten Timeoutwert als Parameter W angeben. Setzt man diesen auf einen sehr kleinen Wert wie z. B. 1ms, dann hat man den kompletten Bereich in ca. zwei Minuten durchforstet.

0..255 | % {Ping.exe 192.168.0.$_ –n 1 –w 1}

Jetzt bleibt noch ein Problem, dass die Ausgabe mehr als unübersichtlich ist. Im Grunde muss man sowieso nicht sehen, ob eine Antwort von einem Ping zurückkommt. Denn sobald eine IP-Adresse mittels Ping erreichbar ist, wird in der ARP-Tabelle, welche mittels ARP.EXE einsehbar ist, ein Eintrag mit der zugehörigen IP- und MAC-Adresse generiert. Hier haben wir nun auch die Verbindung zwischen beiden. Dies sieht z. B. so aus:

arp.exe -a

Schnittstelle: 192.168.0.2 — 0xc
  Internetadresse       Physische Adresse     Typ
  192.168.0.1           00-a4-6c-ee-11-f2     dynamisch
  192.168.0.5           00-03-05-63-12-d9     dynamisch
  192.168.0.255         ff-ff-ff-ff-ff-ff     statisch
  224.0.0.22            01-00-5e-00-00-16     statisch
  224.0.0.252           01-00-5e-00-00-fc     statisch
  239.255.255.250       01-00-5e-7f-ff-fa     statisch

Wir können also die Rückgabe des Ping-Befehls ignorieren und statt dessen die Ausgabe des ARP-Befehls interpretieren.

Damit könnte man so etwas bauen:

0..255|% {$ip="192.168.0.$_"; ping.exe -4 -n 1 -w 1 $ip | out-null; $arp=arp.exe -a | select-string "$ip(?s)(.*)dynam"; If ($arp) {$ip} }

Hier werden einfach nacheinander die IP-Adressen ausgegeben. Natürlich kann man auch die Ausgabe der ARP.EXE direkt verwenden.

arp.exe -a| select -Skip 3

Problem sind hier die weiteren Angaben für die Broadcastadressen.

Um die Sache nun etwas einfacher zu gestalten wäre es toll, wenn man den IP-Adressbereich (hier: 192.158.0.x) automatisch ermitteln könnte, dies könnte man z. B. durch:

Get-NetIPAddress -AddressFamily IPv4 -PrefixOrigin dhcp

IPAddress         : 192.168.0.2
InterfaceIndex    : 12
InterfaceAlias    : Ethernet
AddressFamily     : IPv4
Type              : Unicast
PrefixLength      : 24
PrefixOrigin      : Dhcp
SuffixOrigin      : Dhcp
AddressState      : Preferred
ValidLifetime     : 22:17:34
PreferredLifetime : 22:17:34
SkipAsSource      : False
PolicyStore       : ActiveStore

Damit hat man die lokale IP-Adresse seines Rechners. So könnte man den Adressbereich ermitteln:

$iprange=((Get-NetIPAddress -AddressFamily IPv4 -PrefixOrigin dhcp).IPAddress)
$iprange=$iprange.Substring(0,$iprange.LastIndexOf(".")+1)
$iprange

Dadurch kann man nun

arp.exe -a| select -Skip 3 |  Select-String $iprange

  192.168.0.1           00-a4-6c-ee-11-f2     dynamisch
  192.168.0.5           00-03-05-63-12-d9     dynamisch
  192.168.0.255         ff-ff-ff-ff-ff-ff     statisch

aufrufen, besser noch:

arp.exe -a| select -Skip 3 |  Select-String $iprange | Select-String -NotMatch "ff-ff-ff-ff-ff-ff"

Fast am Ziel! Jetzt noch alles in Objekte verpacken:

arp.exe -a| select -Skip 3 |  Select-String $iprange | Select-String -NotMatch "ff-ff-ff-ff-ff-ff"| %  { [PSCustomObject]@{IP=($_ -split "\s+")[1];MAC=($_ -split "\s+")[2] } }

IP          MAC
–          —
192.168.0.1 00-a4-6c-ee-11-f2
192.168.0.5 00-03-05-63-12-d9

Ach übrigens, seit Windows 8 gibt es auch ein Cmdlet welches ähnliche, ja sogar noch viel mehr Informationen liefert! Es nennt sich Get-NetNeighbor: https://technet.microsoft.com/en-us/library/hh826147. Bin ich aber auch jetzt erst am Ende des Artikel bei der Recherche drauf gestoßen. Bei Get-NetNeighbor gibt es eine State-Eigenschaft, die nach recht kurzer Zeit von Reachable nach Stale wechselt. Dazu gibt es einen Timeout, näheres ist hier beschrieben: https://support.microsoft.com/en-us/kb/949589. Offensichtlich gibt es auch noch ein Neighbor-Cache-Limit.

Zu obiger Arp-Ausgabe kann man also auch Get-NetNeighbor verwenden:

Get-NetNeighbor -AddressFamily IPv4 | where {$_.state -eq "stale" -or $_.state -eq "reachable"}

Um nun nochmal alles in einen sinnvollen Zusammenhang zu bringen:

$iprange=((Get-NetIPAddress -AddressFamily IPv4 -PrefixOrigin dhcp).IPAddress)
$iprange=$iprange.Substring(0,$iprange.LastIndexOf(".")+1)
$iprange

0..255|% {$ip="$iprange$_"; ping.exe -4 -n 1 -w 1 $ip | out-null; $arp=arp.exe -a | select-string "$ip(?s)(.*)dynam"; If ($arp) {$ip} }

$arp=arp.exe -a| select -Skip 3 |  Select-String $iprange | Select-String -NotMatch "ff-ff-ff-ff-ff-ff"| %  { [PSCustomObject]@{IP=($_ -split "\s+")[1];MAC=($_ -split "\s+")[2] } }

$arp

An diesem Punkt vielleicht noch interessant: Manchmal hat man nur eine MAC-Adresse und möchte den zugehörigen Hersteller feststellen, dazu gibt es verschiedene Datenbanken im Internet. Z. B. www.coffer.com/mac_find. Man kann auch direkt eine Abfrage starten http://www.coffer.com/mac_find/?string=00-1b-00.

Noch eine interessante Variante mittel PingAsync: https://p0w3rsh3ll.wordpress.com/2018/04/18/fast-ping/

Arp für IPv6 bzw. wie kann ich zu einer IPv6-Adresse die zugehörige IPv4-Adresse unter Windows ermitteln?

20 März 2017

Wenn man unter aktuellen Windowsversionen z. B. Get-SmbOpenFile verwendet, um z. B. sehen zu können, welcher Benutzer auf welchem Rechner gerade welche Dateien geöffnet hat, so bekommt man dort einen ClientComputername angegeben. Leider wird dieser ClientComputername oft als IPv6-Adresse und nicht als IPv4-Adresse angegeben. Im Grunde ist es ja korrekt alles über IPv6 zu machen aber wir Menschen tun uns halt schwer mit den IPv6-Adressen.

Wie kann man nun aber zu einer IPv6-Adresse die zugehörige IPv4-Adresse im lokalen Netz ermitteln? Ein Aufruf von ARP.EXE zeigt gähnende Leere, denn es zeigt nur IPv4-Adressen an. Einen Parameter –6 oder ARP6.EXE gibt es nicht.

Nun könnte man NETSH.EXE das alte Universaltool rauskramen und mittels

netsh int ipv6 show neigh

die MAC-Adressen zu den MAC-Adressen von der ARP.EXE-Ausgabe in Beziehung setzen. Aber das artet schnell in Arbeit aus.

Hier hilft wie immer Powershell, denn dort gibt es das Get-NetNeighbor-Cmdlet und damit kommt man bei richtiger Anwendung ganz schnell zum Ziel:

PS> Get-NetNeighbor| Group-Object linklayeraddress | where count -eq 2 | select -ExpandProperty group

ifIndex IPAddress                 LinkLayerAddress 
——- ———                 —————- 
3       fe80::41dc:1d58:7d3b:c57b EC-A8-6B-D1-F5-46
3       192.168.100.72            EC-A8-6B-D1-F5-46
3       fe80::1e74:dff:feac:c8d0  1C-74-0D-AC-C8-D0
3       192.168.100.1             1C-74-0D-AC-C8-D0

Hier sieht man schön, dass die passenden IP-Adressen immer durch die MAC-Adresse beieinander gruppiert sind und so schön von der einen auf die andere geschlossen werden kann.

Da wir uns schon wieder bei Powershell befinden, ist es sicher sinnvoll daraus gleich eine Funktion zu machen, welche in Skripten verwendet werden kann.

Function Convert-IPAddress {
[CmdletBinding()]
Param(
  [IPAddress]$IPAdresse
)

$n=Get-NetNeighbor

# Alle IP-Adressen mit MAC-Adressen ermitteln:
$nip = $n|where linklayeraddress -ne ""| sort linklayeraddress

# MAC-Adresse zur gesuchten IP-Adresse ermitteln: 
$nMAC = $nip | where ipaddress -eq $IPAdresse.IPAddressToString
# alle IP-Adressen zur ermittelten MAC holen:
$rip = $nip | where linklayeraddress -eq $nmac.LinkLayerAddress

$rip = $rip| where ipaddress -ne $IPAdresse.IPAddressToString

If ([System.Net.Sockets.AddressFamily]::InterNetworkV6 -eq $IPAdresse.AddressFamily) {
  # von IPv6 nach IPv4, also nur IPv4 zurückgeben
  ($rip | where {([IPAddress]$_.IPAddress).AddressFamily -eq [System.Net.Sockets.AddressFamily]::InterNetwork}).IPAddress
} else {
  If ([System.Net.Sockets.AddressFamily]::InterNetwork -eq $IPAdresse.AddressFamily) {
   # von IPv4 nach IPv6, also nur IPv6 zurückgeben
   ($rip | where {([IPAddress]$_.IPAddress).AddressFamily -eq [System.Net.Sockets.AddressFamily]::InterNetworkV6}).IPAddress
  } 
}
}

Damit kann man nun ganz einfach die IP-Adresse konvertieren:

PS> Convert-IPAddress fe80::1e74:dff:feac:c8d0
192.168.100.1
PS> Convert-IPAddress 192.168.100.1
fe80::1e74:dff:feac:c8d0

Gibt man eine Adresse an, zu der es keine Entsprechung gibt, bekommt man einfach $Null zurück.

Öffentliche IP-Adresse bei LTE unter T-Mobile

16 September 2016

Wenn mal die Festnetz-Internetleitung ausfällt, dann kann man mit aktuellen Fritzboxen problemlos einen LTE-USB-Stick einstecken und die Einwahl über das LTE-Netz vollziehen. Soweit so gut. Man kann dadurch problemlos wieder ins Internet. Man hat zwar die Möglichkeit zu surfen aber ein Problem tritt auf, wenn man Serverdienste betreiben möchte, denn die T-Mobile vergibt nur Carrier Grade NAT (CGN) Adressen bei den Standardeinstellungen. Dadurch bekommt man zwar eine IPv4-Adresse wie z.B. 10.156.122.56 aber diese ist nur innerhalb des T-Mobile Netzes eindeutig. Dadurch kann man keine Serverdienste auf seinem Rechner betreiben, wie z. B. einen SMTP-Mailserver.

Zum Glück gibt es eine Lösung zum Problem. Man muss den APN was für Access Point Name steht abändern. Im Falle von T-Mobile ist dies:

T-Mobile öffentliche IP-Adresse APN

APN internet.t-d1.de
Benutzer t-mobile
Kennwort tm
Rufnummer (falls notwendig) *99#
Authentifizierungstyp PAP

Damit die Angaben eingetragen werden können muss man in der Regel den Eintrag “Anderer Provider” bei den Zugangsdaten auswählen.

Hier findet man noch viele andere Anregungen für weitere Provider: http://www.lte-anbieter.info/ratgeber/apn/uebersicht.php.

Wichtig, falls es nicht klappt: Es ist offenbar auch vom Tarif abhängig, ob man eine öffentliche IP-Adresse bekommen kann oder nicht!

Das interessante daran ist, dass man sich diesen Aufwand bei IPv6 sparen kann. Wer IPv6 aktiviert hat, bekommt von T-Mobile bereits beim Standard APN automatisch eine globale Unicast-Adresse zugeteilt. Damit ist das jeweilige Gerät bzw. Netz weltweit eindeutig erreichbar und für Server Dienste nutzbar! Man bekommt also eine private IPv4 und eine globale IPv6-Adresse in Kombination. D. h. die IPv4-Adresse lautete 10.156.122.56 und die IPv6-Adresse 2a01:598:90e2:1338:…

Globale Unicast Adressen bei IPv6 sind als 2000::/3 definiert, wobei für Europa (RIPE NCC) der Bereich 2a00::/12 vorgesehen ist, wovon wiederum 2a01:598::/29 für T-Mobile zugeordnet ist. https://stat.ripe.net/2a01%3A598%3A%3A%2F29#tabId=at-a-glance. Der Bereich /29 ist eine Menge Holz! Der Vollständigkeit halber hier noch der Einstieg zur Definition von 2000::/3 http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml und die Definition der IPv6 Global Unicast Adress Bereiche: http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml.

Um sich etwas besser vorstellen zu können, was sich hinter der Angabe von /29 verbirgt, der möchte diese Angabe betrachten:

/29
Start IP: 2a01:598:0:0:0:0:0:0
End IP: 2a01:59f:ffff:ffff:ffff:ffff:ffff:ffff
Addresses: 633825300114114700748351602688
Class: –
Netmask: 255.255.255.248.0.0.0.0.0.0.0.0.0.0.0.0.
Binary: 11111111 11111111 11111111 11111000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

Diese Info kann man erhalten, wenn man unter https://www.ultratools.com/tools/ipv6Info die IPv6-Adresse einträgt.

DHCP Dienst auf Windows SBS2003 startet mit DHCP/BINL-Dienst Fehlermeldung nicht

15 März 2013

Auf einem Windows Small Business Server 2003 mussten beide Netzwerkkarten ausgetauscht. Die eine war für das interne LAN und die andere für das Internet zuständig. Nach dem Zuordnen der fixen IP-Adressen kam es nach dem Neustart des Servers zu dieser Fehlermeldung mit Ereigniskennung 1053 in der Windows Ereignisanzeige unter System:

Der DHCP/BINL-Dienst auf diesem Computer mit Windows Server 2003 für Small Business Server hat einen anderen Server (mit IP-Adresse 192.168.100.2, der zur der Domäne  gehört) ermittelt.

Dabei war die Adresse 192.168.100.2 die Adresse des Gateways, welche im externen Netz auch einen DHCP Server betreibt. Der DHCP-Server konnte zwar manuell gestartet werden aber ging innerhalb ein paar Sekunden sofort mit obiger Fehlermeldung wieder aus. Wie lässt sich dieses Problem nun lösen?

Eigentlich ganz einfach, man schaltet den DHCP im Netz von 192.168.100.0 ab. Aber das ist nicht die Lösung, wenn man darauf keinen Einfluss hat.

Die Lösung brachte dann, als temporär der falsche DHCP-Server ausgeblendet war, also Kabel ziehen und der DHCP-Dienst  lief ohne Probleme an. DHCP Verwaltung geöffnet und nun konnte im betreffenden Server unter Eigenschaften das Register Erweitert geöffnet werden. Dort findet man den Punkt “Verbindungen der Serververbindung ändern”, wo man Bindungen anklickt. Es präsentieren sich die verfügbaren LAN-Verbindungen, wo im besagten Fall tatsächlich beide aktiv waren. Also beim richtigen Netz das Häkchen weg und alles war paletti.

Erklärungen und Erläuterungen zu DNS

2 März 2013

Ein wichtiges Thema, die Namensauflösung mittels DNS. Diese Seite bietet viele gute kurze Erklärungen zum Thema: http://support.simpledns.com/KB/browse.aspx.

Es dreht sich zwar vieles um deren Produkt “Simple DNS Plus”, allerdings werden viele allgemein wichtige Themen angesprochen, wie z. B. DynDNS, DNSSEC, SIP und richtige SPF Konfiguration bei E-Mailservern uvm.

Netzwerkstandort wird bei Windows Vista nicht aufgelöst

28 April 2011

Wenn es Probleme mit der Zuordnung des Netzwerkstandorts unter Windows Vista gibt. Vista kann da sich Stunden mit selber beschäftigen.

Dem hilft ein

NETSH INTERFACE IP RESET

Danach lässt sich der Standort nach einem Neustart problemlos setzen.

IPv4 Ports in Windows Server Systemen

18 Juni 2009

Ein relativ aktueller Knowledge Base Artikel von Microsoft beschreibt die einzelnen Ports und Protokolle wo von den jeweiligen Diensten die auf einem Windows Server laufen benötigt werden, vor allem auch aktuell mit Server 2008.

http://support.microsoft.com/kb/832017/en-us