Posts by Der_Imperator

    Quote from boandlkramer pid=9679 dateline=1365239452

    Das ist mir alles bekannt, aber die virtuellen Netzwerkschnittstellen welche du zum Beispiel mit eth0:1 einrichtest arbeiten auf der Schicht 3. Diese haben nichts mit dem Layer 2 zu tun in welchem zum Beispiel die WLAN-Verbindung aufgebaut wird.

    Du wirfst da was durcheinander.
    eth0 = wlan0
    eth0:1 = wlan0:1

    eth0 / wlan0 gibt die MAC -> Layer 2
    eth0:1 / wlan0:1 die IP -> Layer 3

    Kein Unterschied.

    Beim Wlan ist es einzig der Layer 1 welcher ein anderes Medium zum Transport hat.
    Hier werden die Bits über die Luft übertragen, nicht im Kabel und es wird ein Protokoll nach IEEE 802.1x verwendet.
    Im Ethernet ( Kabelgebunden ) nutzt man IEEE 802.3 und IEEE 802.1q


    Quote from boandlkramer pid=9679 dateline=1365239452


    Dann kram mal raus. Bin gespannt ob du dort zwei unterschiedliche Kanäle einstellen kannst.

    Von 2 unterschiedlichen Kanälen war doch nirgendwo die Rede.
    Oder habe ich das überlesen ? Dann entschuldige ich mich.
    Das geht nur mit MiMo 802.1a und 802.1b/g, da hast du recht.

    Gruß
    Peter

    Quote from boandlkramer pid=9629 dateline=1365188814


    Hallo Der_Imperator,


    Sehen wir uns das ganze mal anhand des OSI-Schichtenmodells an. Die IP-Adressen bei deinen virtuellen Schnittstellen befinden sich auf dem Layer 3 (Vermittlungsschicht). Darunter liegt die Sicherungsschicht (Layer 2) und die Bitübertragung (Layer 1). Die WLAN-Verbindung über IEEE 802.11 erfolgt auf der Sicherungsschicht. Eine virtuelle Netzwerkschnittstelle liegt also eine Ebene höher als die WLAN-Verbindung.


    Auch das "normale" Netzwerk arbeitet auf Layer 2.
    Für eine Verbindung von Hop zu Hop ist die MAC entscheidend, nicht die IP.
    Die Virtuellen Schnittstellen haben die gleiche MAC, sie werden quasi zu einem Switchport, den Rest übernimmt dann der Treiber.

    Quote

    Das mag vielleicht stimmen, aber ein normaler WLAN-Adapter kann immer nur auf einem Frequenzband senden und empfangen. Was du vorschlägst wäre das gleiche als würdest du in eine Netzwerkkarte mehrere Kabel einstecken.


    Dein Wlan Router sendet auch nur auf einer Freuenz oder ?

    Quote

    Wenn du was findest würde mich das interessieren.


    Hast du einen Linksys mit DD-WRT ? dann schau da mal drauf.
    Ich müsste meinen jetzt erst rauskramen.

    Quote

    Was soll das dann bringen? So wie ich das verstanden habe will der Thread Ersteller zwei WLAN-Verbindungen zum bzw. vom Raspberry Pi aufbauen.

    Gruß Georg


    OK, das habe ich falsch verstanden.

    Er möchte vom Handy auf den PI und der Pi soll mit dem Router verbunden werden ?

    Dazu müsste der PI als Repeater nicht als Bridge konfiguriert werden.
    Wie das dann mit den Services aussieht weis ich aber auch nicht.

    Ein WLAN Gerät kann man in folgenden Modi betreiben :
    1.Client -> Verbindet mit einem der unteren 3
    2.Accesspoint -> Stellt eine SSID für Clienten zur Verfügung
    3.Repeater -> Ein Hybrid aus 1 +2 Empfängt als Client sendet als Accesspoint
    4.Bridge -> Empfängt als Client und gibt die Daten ans Kabelgebundene Netzwerk


    Quote from orb pid=9662 dateline=1365230407


    Wie verbindest Du denn den Pi mit dem Netz? Hast Du einen Internetrouter mit WLan dafür?
    Dann kannst Du auch Dein Handy mit dem Netz verbinden und über die Verbindung alles machen was Du willst.
    Poste doch mal Deine Netzwerkeinstellungen.



    Subinterfaces ja, mehrere Netze nein.


    Ja, auch mehrere Netze, ein Gäste WLAN z.B.
    Ohne Zugriff auf das LAN, aber Zugriff auf das WAN.
    Kann heute jeder bessere Router.

    Quote


    Du hast aber mitbekommen, daß der TE nicht den HostAPd benutzen will im mehrere Netze aufzuspannen sondern Client in zwei Netzen sein will?



    Nein, falsch verstanden, siehe oben, sorry

    Quote


    Dann ist mein Google kaputt, gib doch mal nen Beispiel.

    Du würfelst Client und AP, das ist wenig hilfreich.
    btw: welchen Sinn macht es, drei verschiedenen Interfaces IPs aus einem Netz zu geben?


    Das z.B die Adressen unterschiedlich geroutet werden.
    Eine Firewall läuft......
    Drop Interfaces, die IP ist vom Routing ausfeschlossen.
    Verschiedene Anwendungen ein und den selben Port brauchen.
    Da gibt es viele Gründe für

    Quote from boandlkramer pid=9604 dateline=1365177771


    Hallo henneoderei,


    Gleichzeitig kann man immer nur eine WLAN-Verbindung aufbauen. Also wenn du gleichzeitig mit deinem WLAN und mit deinem Handy verbunden sein willst, brauchst du einen zweiten WLAN-Adapter.

    Gruß Georg

    Das ist so nicht ganz richtig.
    Du kannst Subinterfaces (Virtuelle Netzwerk Interfaces) einrichten.

    Auf die Schnelle für eth0 ein Beispiel:

    Das geht auch so mit wlan0, dabei können sogar unterschiedliche SSID propagiert werden.
    Wie das genau aussieht kann ich jetzt nicht sagen, mal googlen nach wlan0 subinterface.

    Auch ist es möglich den PI als Wlan Bridge zu betreiben,
    ob dann jedoch Zugriff auf Services die auf dem PI laufen möglich sind müsste ich jetzt auch testen.

    Quote from aplaceformyhead pid=9589 dateline=1365157296


    Um den Zugriff auf PhpMyAdmin von extern zu sperren muss folgende Änderung vorgenommen werden:

    1. sudo nano /etc/lighttpd/phpmyadmin.conf
    2.Folgendes ergänzen. Bei der IP Adresse wird die komplette Range 192.168.178.0 - 192.168.178.255 erlaubt.

    Code
    $HTTP["remoteip"] !~ "192.168.178." {
    $HTTP["url"] =~ "^/phpsysinfo" {
    url.access-deny = ( "" )
     }
    }


    3. STRG + O zum speichern, STRG + X zum Nano beenden
    4. sudo /etc/init.d/lighttpd restart

    Code
    [ ok ] Stopping web server: lighttpd.
    [ ok ] Starting web server: lighttpd.


    5. Testen

    Man hätte ja noch erwähnen können von wem das kam.....

    Hier lese ich immer wieder das User den PI zum Internet öffnen.
    In der Default Konfiguration des OS und der Programme besteht ein nicht zu Unterschätzendes Risiko das
    der PI gehackt und missbraucht wird.

    Ich werde hier nach und nach ein paar Tips schreiben welche den PI härten.
    Einiges ist hier schon geschrieben worden, ich werde darauf verweisen und evtl die Elementaren Schritte noch einmal verdeutlichen.

    Ich möchte noch darauf hinweisen das ich kein sudo benutze.
    Administrative Aufgaben erledige ich als root. Warum erkläre ich unten.
    Auch ist der MTA des PI so eingerichtet das der PI in der Lage ist Emails zu versenden.


    1. System aktuell halten
    2. Portforwarding am Router
    3. sudo vs su
    4. SSH sicher machen


    1. System aktuell halten

    EDIT: Besser informieren lassen als Updates automatisch installieren,

    Informieren lassen wenn Updates vorliegen.
    Das geht ganz einfach über ein Script und mittels Cron
    Zuerst legen wir eine Datei an und machen sie ausführbar.


    Code
    touch /root/scripts/update.sh
    chmod +x
    /root/scripts/update.sh
    nano /root/scripts/update.sh

    in die Datei kommt nun folgendes :

    Bash
    #!/bin/sh
    apt-get update
    apt-get upgrade -s | mail -s "Subject" emailadresse

    Dann öffnen wir den Crontab

    Code
    crontab -e

    und fügen folgende Zeile ein :

    Code
    12 0 * * *  root /root/scripts/update.sh

    Alternativ können wir anstelle von crontab einen Symbolischen Link nach /etc/cron.daily anlegen

    Code
    ln -s /root/scripts/update.sh /etc/cron.daily/update.sh

    Nun sollte der PI jeden Tag nach Updates suchen und euch eine Mail zusenden .


    2. Portforwarding am Router

    Es sollten immer nur die Ports am Router weitergeleitet werden welche man wirklich benötigt.
    Den PI als "Exposed Host" einutragen ist keine gute Idee da er dort vollkommen offen im Internet steht.

    3. sudo vs su

    Hat jemand das Passwort des User PI bekommen kann er als root mittels sudo befehle ausführen.
    Dem kann man entgegenwirken indem man su anstelle von sudo benutzt.

    Code
    sudo <befehl>


    fragt das Passwort des Benutzer ab welcher den Befehl abgesetzt hat.

    Code
    su
    <befehl>

    Lässt uns erst zu root werden indem das root Passwort gefragt wird
    Anschliessend können wir als Root befehle eingeben.

    su hat also den Vorteil das neben dem Userpasswort auch das root Passwort im Besitz des Angreifers sein muss.

    Zuerst müssen wir root ein Passwort geben.

    Code
    sudo su
    passwd

    jetzt nehmen wir den user PI aus der Sudoers.

    Code
    visudo

    Nun ändern wir folgende Zeile :

    Code
    pi ALL=(ALL) NOPASSWD: ALL


    in

    Code
    #pi ALL=(ALL) NOPASSWD: ALL

    Ab sofort kann man sudo nicht mehr nutzen
    Man muß sich mittels su erst explizit zum root machen.


    4. SSH sicher machen

    Zu dem Thema werde ich die Tage ein eigenes Tutorial schreiben und dann hier verlinken.

    Quote from ps915 pid=8961 dateline=1364491520


    Der_Imperator
    Darf ich das in das Tutorial einfügen wenn ich dich zitiere! ;)

    Selbstverständlich, dafür habe ich es hier gepostet.

    Noch ein Tip :
    Von der Firma aus, wenn diese eine feste IP für ihren Proxyserver hat, zugreifen möchte kann man explizit diese Adresse erlauben.
    Z.B. hat der Firmenproxy die IP 200.100.99.88.
    Dann folgenden Eintrag hinzufügen :

    Allow from 200.100.99.88/32

    Damit erlaubt man den Zugriff auf Phpmyadmin von der Adresse aus.

    Die /32 ist eine andere Schreibweise für das Subnet (Subnetmask).
    Hier werden alle 32 Bit der Netzmaske verwendet, das erlaubt nur diese eine IP.

    PhpMyAdmin nur aus dem lokalen Netz erreichbar machen.
    Diese Schritte sollte man unbedingt machen ansonsten ist die Phpmyadmin Oberfläche aus dem Internet erreichbar.

    1. Anmelden per SSH am PI
    2. sudo nano /etc/apache2/conf.d/phpmyadmin.conf ( Symlink auf /etc/phpmyadmin/apache.conf)
    3. Datei folgendermaßen anpassen :

    Code
    <Directory /usr/share/phpmyadmin>
            Options FollowSymLinks
            DirectoryIndex index.php
            Order Deny,Allow
            Deny from all
            Allow from 192.168.2.0/24  <- Hier natürlich euer Netzwerk rein
            <IfModule mod_php5.c>


    4. Datei speichern
    5. Apache restarten ( /etc/init.d/apache2 restart )

    Jetzt ist die Phpmyadmin Oberfläche nur noch aus dem Lokalen Netzwerk erreichbar.

    Der Apache incl PHP und MySQL läuft ohne Probleme.
    Die Frage sollte sein ob der Speicherplatz der SD Karte für dein Vorhaben ausreicht.
    Wenn du den Webserver offen ans Internet hängst dann solltest du sich vorher mal in die Apache Doku einlesen.
    Out of the Box taugt der nicht als Webserver im Internet.
    Ansonsten kann man böse Überraschungen erleben.
    (Ich bin eh immer wieder erstaunt wie Blauäugig manche Leute ihren Krempel ins Internet hängen)

    Jahrelange Erfahrung ;)

    Mach es mal so :

    danach
    sudo /etc/init.d/networking restart

    dann sollte es klappen mit dem DNS.


    Kurze Erklärung :
    Adressen außerhalb des eigenen Subnet kennt das Netzwerk nicht.
    Die Broadcasts die gesendet werden gehen nicht über die Grenzen des eigenen Subnet hinaus ( Broadcastdomains)
    Damit das Internet nicht gefloodet wird. ( WIKI: Flooding )
    Also kann für die IP keine MAC Adresse bestimmt werden (ARP Request).

    Damit jetzt die Pakete aber doch irgendwie zum Ziel kommen gibt es das Default Gateway.
    Dorthin wird mal alles gesendet was nicht im eigenen Netz ist.
    Der Router(Default Gateway) schaut jetzt nach ob er das Ziel-Netzwerk kennt.
    Hat er keine default route oder keinen nächsten Hop wird das Paket verworfen (dein WLAN Router)
    Hat er eine default route oder kennt er das Netzwerk dann leitet er das Paket auf dem entsprechenden Port ( WAN Port deines DSL Router ) weiter.

    So geht das bis zum Ziel.
    Ein Traceroute zeigt dir jeden Router an der bis zum Ziel dein Paket weiterleitet.

    Hat dein PC jetzt zwei Default Gateways dann weis er nicht wohin mit dem Paket wenn er das Ziel nicht kennt.
    Wenn du Glück hast schickt er das an deinen DSL Router und alles geht,
    Wenn du Pech hast dann schickt er es zum WLAN Router und nix geht.

    DNS macht folgendes :
    Er schickt eine Anfrage an einen DNS Server werlche IP die domain xxx.yyyy.de hat.
    Der DNS antwortet, wenn er die Domain kennt mit z.B. 1.2.3.4
    Und dann geht das Routing wieder los :)

    Wenn du jetzt den "richtigen" DNS Server eingetragen hast, aber dein Default Gateway falsch ist passiert folgendes :
    Der Pi fragt den DNS nach ptbtime1.ptb.de, DNS Server ist dein DSL Router.
    Er bekommt die richtige Antwort, ptbtime1.ptb.de hat die IP 1.2.3.4. ( Der DSL Router fragt den DNS deines Providers)
    Jetzt wird das Paket, weil die IP nicht in deinem Netzwerk ist,an das Default Gateway ( WLAN Router ) gesendet.
    Der Kennt aber nix anderes außer dem lokalen Netz, verwirft das Paket also.

    DNS geht aber das Routing nicht.

    Auch hier hilft traceroute, da siehst du wo dein Paket lang geht.

    Sehr Einfach erklärt aber kommt hin.


    Ich hoffe das war so verständlich.
    Routing und Switching ist schon ein wenig Gaga.

    Quote from orb pid=8639 dateline=1364219235



    Nein, in die resolv.conf gehört der Nameserver, nicht das Gateway und daß der fehlt hatten wir imho in https://www.forum-raspberrypi.de/Thread-mehrere…id=8615#pid8615 schon festgestellt


    Du würfelst Gateway und Nameserver. Der Fehler ist 'name server cannot be used' nicht 'name server not reachable'
    Als Nameserver ist zwar meist der Router eingetragen aber nur weil er DNS-Proxy spielt. Du kannst da auch 8.8.8.8 eintragen wenn Du lieber den Google-DNS benutzen willst oder 127.0.0.1 wenn Du auf dem Pi einen Bind konfiguriert hast.

    Als Nameserver musst du in dem Fall den Router eintragen weil die route zur 8.8.8.8 auf den WLAN Router läuft und somit keine DNS Auflösung möglich ist.
    Wenn du einen BIND installiert hast löst er nur die Zonen auf die du Konfiguriert hast.
    Selbst wenn du im Bind einen Eintrag hast : ptbtime1.ptb.de -> 192.53.103.108 wird das nicht gehen weil die Default Route und somit der nächste Hop zur 192.53.103.108 wieder der WLAN Router ist, und nicht der Internetrouter. Somit läuft das hier wieder aus dem Lot bzw. ins Nirvana.

    DNS Auflösung klappt nur mit funktionierendem Netzwerk.
    Und ich Verwechsel da mit Sicherheit nichts.

    Und in 99,99% aller Fälle ist der Internet-Router zu Hause auch der DNS Server und der gehört in die resolve.conf

    Ein Routingproblem...