O
ooo
Enthusiast
- 3.449
- Themenstarter
- #41
Neue Postings kann man als Thread-Ersteller oder Beitrags-Ersteller nicht einfügen, um z. B. ein Posting in mehrere aufeinander folgende aufzusplitten. - Nur neue am Ende des Threads anhängen.
Evtl. werde ich die Abschnitte in Spoiler-Buttons packen. - Besonders für die Smartphone-/Tapatalk-Freunde.
Man kann z. B. Tabs im Browser und/oder mehrere Browser-Fenster mit unterschiedlichen Text-Positionen im Start-Posting öffnen, die man dann auch neben- oder untereinander am Monitor plazieren kann.
Hat man z. B. 2 oder 3 (identische) Monitore nebeneinander, die eine einzige Arbeitsfläche bilden (Dokumentation/Recherche, Monitoring/Kommuniktion, Entwicklung/Administration), kann man so noch effektiver an Themen arbeiten. - Das löst das Problem an sich aber auch nicht, okay.
Das mit OpenDNS kläre ich mal versuchsweise:
Es gibt das Protokoll TCP und das Protokoll UDP.
DNS-Anfragen können sowohl über TCP als auch UDP gemacht werden.
Die Regel ist, dies über UDP zu tun.
Für jedes dieser Protokolle wurden (maximal) 65.535 Ports definiert (0 bis 65.535; 0 ist reseviert). - Portliste zum Nachsehen
Nur nebenbei:
Es gibt also grundsätzliche 2 x 65.535 offene Türen raus und ebenso viele rein ... die macht man besser größtenteils zu.
(Die rein gehen, sind bei Android bereits von außen zu = Die Hälfte ist "abgeräumt".)
OpenDNS ist ein Dienst (DNS) der auf Port 53 (UDP) erreichbar ist.
Jede App, die irgendwohin will (IP), um einen bestimmten Server zu erreichen (Port), wird erst bei OpenDNS nachfragen, wie die IP-Adresse ist.
Den Port kennt die App bereits (im Code fix einprogrammiert), weil er standardisiert ist oder in den Einstellungen der App eingetragen/geändert werden kann.
Alle Anfragen "Wie ist die IP zur Domain <beliebige-domain.xyz>?" werden vom Phone (bei unseren Einstellungen) zu OpenDNS gemacht.
Das erledigt bei uns "0: root" (Der Mechanismus dazu heißt "DNS Resolver)", wie man im Protokoll der App "Netzwerk Log" feststellen kann (208.67.222.222:53 (UDP)).
Das sind nur die Anfragen der Apps (Mail, Browser, WhatsApp, Facebook, Tapatalk, YouTube etc.), wohin sie müssen.
Sonst nichts.
Erst der "echte" Traffic der App mit dem Ziel ("GMail holt/sendet Mails beim/zum Google-Server") wird dann unter der App im Netzwerk Log Protokoll selbst vermerkt.
Metapher "Telefonauskunft" (zu DNS-Anfragen):
Eine IP ist die Haupt-Telefon-Nummer (OpenDNS-Server: IP 208.67.222.222)
Ein Port ist dann die "Nebenstelle" (Dienst DNS: Port 53)
Die komplette "Telefon-Nummer" ("Durchwahl"), um den "Typ" (den DNS-Server-Dienst) am anderen Ende der Leitung zu fragen, welche IP die Domäne android-hilfe.de hat, wäre dann:
208.67.222.222:53
(das geht über das UDP-Protokoll und/oder TCP, je nachdem, was angeboten wird)
Das Phone kennt aber die benötigte Telefon-Nummer nicht, sondern erstmal nur den "Teilnehmer-Namen". - Das ist eine Domain ("youtube.com").
Beispiel 1: Eine Seite im Web-Browser des Phones öffnen:
Beispiel 2: Google-Mails synchronisieren:
___
ist bei deinem Script nicht nötig, da alle deine Regeln nur mit IPTABLES verwendet werden. - Auch hast du in den Einstellungen von AFWall+ bei "IPv6-Unterstützung" den Haken nicht gesetzt, was die gesamten ip6tables rule sets deaktiviert - also die Verwaltung der IPv6-Regeln. - (Wenn es nicht geht und die AFWall+ dabei Fehler ausgibt, dann kann die ROM kein IPv6 = gut; Wenn es ginge, dann müsste man alle eigenen Regeln im Script verdoppeln für IPTABLES = ... und IP6TABLES = ... und man müsste IPv6-IP-Adressen benutzen - die sind viel länger und anders aufgebaut.).
IPTABLES ist eine Variable im Script, die einfach nur den physikalischen Pfad zum iptables Programm (binary) enthält. - Diese binary ist für IPv4 zuständig (/system/bin/iptables).
IP6TABLES (bzw. der Inhalt der Shell-Script-Variablen) ist das entsprechende Programm für IPv6 (/system/bin/ip6tables; Nachschauen: ist es dort in der ROM?). - Aktuell wird IPv6 kaum eingesetzt. - Deswegen sieht man auf der Entwicklerseite auch fast keine Regeln für IPv6 in den Beispielen.
(Dann ist auch die Frage, ob ein Smartphone - also die ROM - überhaupt IPv6 "spricht" bzw., ob IPv6 nicht sowieso deaktiviert/geblockt ist.)
SSH Verbindung auf ein Motorola Defy (MB525) und Suche nach Spuren von IPv6:
Beide binaries sind vorhanden ...
which fragt, wo das Programm <X> im Dateisystem liegt, wenn es nicht gefunden wird, wird nichts ausgegeben.:
... aber IPv6 ist komplett deaktiviert (= gut)
Mit grep durchsuchen wir alle Dateien (*) im aktuellen Verzeichnis (/system/etc/) nach dem Text "ipv6" - Groß-/Kleinschreibung egal (-i).
Am Anfang der Ergebnis-Liste steht für jede Zeile, in der etwas gefunden wurde, der Dateiname der Fundstelle.
___
Die Zeile(n) in den AFWall+ Einstellungen in den Feldern für die Start- und Stop-Scripte werden von AFWall+ gesourcet (source oder dot "." command, siehe Dokumentation Shell Scripting; z. B. zu Linux man bash).
Deswegen ist die Shebang-Zeile (#!/system/bin/sh), die auf die auszuführende Shell verweist, hier eher unnötig.
Wenn man ein solches Script als eigene Datei im Terminal (Android Terminal Emulator oder einer adb shell oder über ssh) manuell ausführen möchte, dann macht die Shebang-Zeile wieder Sinn. - Innerhalb von AFWall+ eher nicht.
_
Auszug Linux man bash
Evtl. werde ich die Abschnitte in Spoiler-Buttons packen. - Besonders für die Smartphone-/Tapatalk-Freunde.
Man kann z. B. Tabs im Browser und/oder mehrere Browser-Fenster mit unterschiedlichen Text-Positionen im Start-Posting öffnen, die man dann auch neben- oder untereinander am Monitor plazieren kann.
Hat man z. B. 2 oder 3 (identische) Monitore nebeneinander, die eine einzige Arbeitsfläche bilden (Dokumentation/Recherche, Monitoring/Kommuniktion, Entwicklung/Administration), kann man so noch effektiver an Themen arbeiten. - Das löst das Problem an sich aber auch nicht, okay.
___zcover schrieb:[...] Wer es nicht schöner für jeden Abschnitt eine eigenes Posting im Anfangspost zu erstellen? [...]
Das mit OpenDNS kläre ich mal versuchsweise:
Es gibt das Protokoll TCP und das Protokoll UDP.
DNS-Anfragen können sowohl über TCP als auch UDP gemacht werden.
Die Regel ist, dies über UDP zu tun.
Für jedes dieser Protokolle wurden (maximal) 65.535 Ports definiert (0 bis 65.535; 0 ist reseviert). - Portliste zum Nachsehen
Nur nebenbei:
Es gibt also grundsätzliche 2 x 65.535 offene Türen raus und ebenso viele rein ... die macht man besser größtenteils zu.
(Die rein gehen, sind bei Android bereits von außen zu = Die Hälfte ist "abgeräumt".)
OpenDNS ist ein Dienst (DNS) der auf Port 53 (UDP) erreichbar ist.
Jede App, die irgendwohin will (IP), um einen bestimmten Server zu erreichen (Port), wird erst bei OpenDNS nachfragen, wie die IP-Adresse ist.
Den Port kennt die App bereits (im Code fix einprogrammiert), weil er standardisiert ist oder in den Einstellungen der App eingetragen/geändert werden kann.
Alle Anfragen "Wie ist die IP zur Domain <beliebige-domain.xyz>?" werden vom Phone (bei unseren Einstellungen) zu OpenDNS gemacht.
Das erledigt bei uns "0: root" (Der Mechanismus dazu heißt "DNS Resolver)", wie man im Protokoll der App "Netzwerk Log" feststellen kann (208.67.222.222:53 (UDP)).
Das sind nur die Anfragen der Apps (Mail, Browser, WhatsApp, Facebook, Tapatalk, YouTube etc.), wohin sie müssen.
Sonst nichts.
Erst der "echte" Traffic der App mit dem Ziel ("GMail holt/sendet Mails beim/zum Google-Server") wird dann unter der App im Netzwerk Log Protokoll selbst vermerkt.
Metapher "Telefonauskunft" (zu DNS-Anfragen):
Eine IP ist die Haupt-Telefon-Nummer (OpenDNS-Server: IP 208.67.222.222)
Ein Port ist dann die "Nebenstelle" (Dienst DNS: Port 53)
Die komplette "Telefon-Nummer" ("Durchwahl"), um den "Typ" (den DNS-Server-Dienst) am anderen Ende der Leitung zu fragen, welche IP die Domäne android-hilfe.de hat, wäre dann:
208.67.222.222:53
(das geht über das UDP-Protokoll und/oder TCP, je nachdem, was angeboten wird)
Das Phone kennt aber die benötigte Telefon-Nummer nicht, sondern erstmal nur den "Teilnehmer-Namen". - Das ist eine Domain ("youtube.com").
Beispiel 1: Eine Seite im Web-Browser des Phones öffnen:
Android-Hilfe hat einen Web-Server mit diesem Forum hier auf TCP-Port 80 (http) am Laufen.
Wenn ihr jetzt die Domäne android-hilfe.de im Browser eintippt, dann wird das Phone bei 208.67.222.222:53 eine DNS-Anfrage machen (Telefonauskunft: Wie ist die Nr. des Teilnehmers android-hilfe.de?)
Antwort für den Browser 212.72.171.241:80 (Port 80 TCP = HTTP - Web-Server)
Das, was das Phone dabei tut, kann man nachstellen (z. B. Linux-Rechner):
Mit dem Befehl dig
fragt man den DNS-Server bei OpenDNS @208.67.222.222
nach der (einer) IP von android-hilfe.de (Wir wollen im Browser die Webseite von android-hilfe.de öffnen)
Antwort: Erreichbar unter 212.72.171.241
Diese Anfragen sind alle in der App "Netzwerk Log" mit Port 53 Protokoll udp zu sehen.
Das Phone benutzt dann die vollständige "Telefon-Nummer" 212.72.171.241:80 (Port 80 = HTTP-Protokoll = Web-Server von Android-Hilfe), um die Webseite im Browser zu öffnen (Der Browser benutzt dabei das TCP-Protokoll, wie man in der App "Netzwerk Log" im Log zur App Browser feststellen kann).
Das Phone macht also nichts anderes, als dauernd bei der "Auskunft" OpenDNS ins Internet-"Telefonbuch" zu sehen (die Auskunft anzurufen), um nach Telefon-Nummern (IPs) für Teilnehmer (Domänen) zu fragen, damit es diese erreichen kann. - Die Ports "weiß" das Phone, weil diese standardisiert (Liste) sind (bzw. die Apps das wissen, die die Verbindungen machen möchten.).
Beispiele (kann man sich merken, muss es aber nicht ...):
80 (HTTP - Webserver)
443 (HTTPS - Webserver, verschlüsselt)
53 (DNS - Anfragen zur Domänen-Auflösung in IPs, unverschlüsselt)
143 (IMAP - Mails holen, unverschlüsslet)
993 (IMAPS - Mails holen, verschlüsselt)
25 (SMTP - Mails senden, unverschlüsselt)
465 (SMTPS - Mails senden, verschlüsselt)
587 (SMTPS - Mails senden, verschlüsselt)
Wenn ihr jetzt die Domäne android-hilfe.de im Browser eintippt, dann wird das Phone bei 208.67.222.222:53 eine DNS-Anfrage machen (Telefonauskunft: Wie ist die Nr. des Teilnehmers android-hilfe.de?)
Antwort für den Browser 212.72.171.241:80 (Port 80 TCP = HTTP - Web-Server)
Das, was das Phone dabei tut, kann man nachstellen (z. B. Linux-Rechner):
Mit dem Befehl dig
fragt man den DNS-Server bei OpenDNS @208.67.222.222
nach der (einer) IP von android-hilfe.de (Wir wollen im Browser die Webseite von android-hilfe.de öffnen)
Antwort: Erreichbar unter 212.72.171.241
Diese Anfragen sind alle in der App "Netzwerk Log" mit Port 53 Protokoll udp zu sehen.
Das Phone benutzt dann die vollständige "Telefon-Nummer" 212.72.171.241:80 (Port 80 = HTTP-Protokoll = Web-Server von Android-Hilfe), um die Webseite im Browser zu öffnen (Der Browser benutzt dabei das TCP-Protokoll, wie man in der App "Netzwerk Log" im Log zur App Browser feststellen kann).
Code:
terminal@linux # your command? [B] dig @208.67.222.222 [COLOR=SeaGreen]android-hilfe.de[/COLOR] any[/B]
dig @208.67.222.222 android-hilfe.de any
; <<>> DiG 9.8.1-P1 <<>> @208.67.222.222 android-hilfe.de any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20675
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;android-hilfe.de. IN ANY
;; ANSWER SECTION:
[COLOR=Green][B]android-hilfe.de[/B][/COLOR]. 27 IN A [COLOR=Red][B]212.72.171.241[/B][/COLOR]
android-hilfe.de. 1535 IN MX 10 mail.android-hilfe.de.
android-hilfe.de. 81637 IN NS dns.dns1.de.
android-hilfe.de. 81637 IN NS dns.dns2.de.
android-hilfe.de. 81637 IN NS dns.dns3.de.
android-hilfe.de. 27 IN SOA dns.dns1.de. hostmaster.internetwire.de. 2012111903 28800 7200 604800 300
;; Query time: 37 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Sun Nov 9 01:54:38 2014
;; MSG SIZE rcvd: 63
Beispiele (kann man sich merken, muss es aber nicht ...):
80 (HTTP - Webserver)
443 (HTTPS - Webserver, verschlüsselt)
53 (DNS - Anfragen zur Domänen-Auflösung in IPs, unverschlüsselt)
143 (IMAP - Mails holen, unverschlüsslet)
993 (IMAPS - Mails holen, verschlüsselt)
25 (SMTP - Mails senden, unverschlüsselt)
465 (SMTPS - Mails senden, verschlüsselt)
587 (SMTPS - Mails senden, verschlüsselt)
Beispiel 2: Google-Mails synchronisieren:
Das selbe passiert, wenn man seine Mails senden oder lesen möchte:
Schritt 1: Bei OpenDNS ("Telefon-Auskunft") nach einer IP-Adresse für gmail.com fragen:
Das Phone kennt die IP von gmail.com nicht (wenn man Google-Mail benutzt), weiß aber, das es bei OpenDNS ("Telefon-Auskunft") fragen kann:
Wir machen das, was das Phone im Hintergrund tut mal wieder mit einer Linux Box nach:
Mit dem Befehl dig
fragt man den DNS-Server bei OpenDNS @208.67.222.222
nach der (einer) IP von gmail.com
nach allen Einträgen any
Antwort: Erreichbar unter den Domänen die ein MX (das sind die Einträge für Google's Mail-Server) in der Zeile haben:
Schritt 2: IP-Adresse eines Google Mail-Servers zum VERSENDEN von Mails finden
Jetzt sucht sich das Phone der Reihe nach die MX-Domains (der verfügbaren Mail-Server) aus der ersten Anfrage und fragt wieder OpenDNS nach einer IP-Adresse.
(Die mit dem kleinsten Zahlen-Wert hinter MX wird als erstes probiert. = höchste Priorität.)
Wir machen das, was das Phone im Hintergrund tut, wieder mit einer Linux Box nach:
Der "Typ" (der Mail-Server), der für für das Versenden unserer Mails verantwortlich ist, kann unter einer der "Nebenstellen-Nummer" 587 (Port) oder 465 (Port) oder 25 (Port) für das SMTP/SMTPS-Protokoll erreicht werden.
Das Phone wird dann 74.125.136.26:587 (Port 587 = SMTP-Protokoll, verschlüsselt) "anrufen", um die Mails zu senden (alternativ Ports 25, 465).
Benutzt man (Google's) Web-Mail läuft das immer über Port 443 (HTTPS) verschlüsselt ab, wie im Browser auch, klar.
(Das läuft wieder unter TCP, siehe "Netzwerk Log" App.)
Schritt 3: IP-Adresse eines Google Mail-Servers zum EMPFANGEN von Mails finden
Jetzt sucht sich das Phone einen IMAP-Server fragt wieder OpenDNS nach einer IP-Adresse.
(Das Phone kennt die Domäne des IMAP-Servers, z. B. imap.gmail.com, weil die in der Mail-App eingetragen ist. - Das gleiche kann man auch für den SMTP-Server sagen, über den Mails versendet werden.)
Wir machen es wieder mit einer Linux Box nach:
Der "Typ", der dort für das Empfangen von Mails verantwortlich ist, kann unter der "Nebenstellen-Nummer" 993 (Port des Mail-Servers für den Empfang von Mails) erreicht werden.
Das Phone wird dann 173.194.65.108:993 (Port 993 = IMAP-Protokoll, verschlüsselt) "anrufen", um die Mails zu senden.
Benutzt man (Google's) Web-Mail läuft das immer über Port 443 (HTTPS) verschlüsselt ab, wie im Browser auch, klar.
(Das läuft wieder unter TCP, siehe "Netzwerk Log" App.)
Schritt 1: Bei OpenDNS ("Telefon-Auskunft") nach einer IP-Adresse für gmail.com fragen:
Das Phone kennt die IP von gmail.com nicht (wenn man Google-Mail benutzt), weiß aber, das es bei OpenDNS ("Telefon-Auskunft") fragen kann:
Wir machen das, was das Phone im Hintergrund tut mal wieder mit einer Linux Box nach:
Mit dem Befehl dig
fragt man den DNS-Server bei OpenDNS @208.67.222.222
nach der (einer) IP von gmail.com
nach allen Einträgen any
Antwort: Erreichbar unter den Domänen die ein MX (das sind die Einträge für Google's Mail-Server) in der Zeile haben:
Code:
terminal@linux # your command?[B] dig @208.67.222.222 [COLOR=Green]gmail.com[/COLOR] any[/B]
; <<>> DiG 9.8.1-P1 <<>> @208.67.222.222 gmail.com any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58323
;; flags: qr rd ra; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;gmail.com. IN ANY
;; ANSWER SECTION:
gmail.com. 300 IN A [B]173.194.116.214[/B]
gmail.com. 300 IN A [B]173.194.116.213[/B]
gmail.com. 300 IN AAAA 2a00:1450:4001:80f::1016
gmail.com. 86400 IN SOA ns1.google.com. dns-admin.google.com. 2012061200 21600 3600 1209600 300
gmail.com. 345600 IN NS ns1.google.com.
gmail.com. 345600 IN NS ns2.google.com.
[COLOR=SeaGreen][COLOR=Black]gmail.com. 345600 IN NS ns4.google.com.
gmail.com. 345600 IN NS ns3.google.com.
[/COLOR][/COLOR][B][COLOR=SeaGreen][COLOR=Black][B][B][B][B]gmail.com. 3600 IN MX 40 alt4.gmail-smtp-in.l.google.com.[/B]
gmail.com. 3600 IN MX 30 alt3.gmail-smtp-in.l.google.com.[/B]
gmail.com. 3600 IN MX 20 alt2.gmail-smtp-in.l.google.com.[/B]
gmail.com. 3600 IN MX 10 alt1.gmail-smtp-in.l.google.com.[/B]
[/COLOR]gmail.com. 3600 IN [COLOR=Red]MX 5[/COLOR] gmail-smtp-in.l.google.com[/COLOR].[/B]
gmail.com. 300 IN TXT "v=spf1 redirect=_spf.google.com"
;; Query time: 38 msec
;; [B]SERVER: 208.67.222.222#53(208.67.222.222)[/B]
;; WHEN: Sun Nov 9 01:48:00 2014
;; MSG SIZE rcvd: 92
Jetzt sucht sich das Phone der Reihe nach die MX-Domains (der verfügbaren Mail-Server) aus der ersten Anfrage und fragt wieder OpenDNS nach einer IP-Adresse.
(Die mit dem kleinsten Zahlen-Wert hinter MX wird als erstes probiert. = höchste Priorität.)
Wir machen das, was das Phone im Hintergrund tut, wieder mit einer Linux Box nach:
Code:
terminal@linux # your command?[B] dig @208.67.222.222 [COLOR=SeaGreen]gmail-smtp-in.l.google.com[/COLOR][/B]
; <<>> DiG 9.8.1-P1 <<>> @208.67.222.222 gmail-smtp-in.l.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51946
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;gmail-smtp-in.l.google.com. IN A
;; ANSWER SECTION:
[COLOR=SeaGreen][B]gmail-smtp-in.l.google.com[/B][/COLOR]. 300 IN A [COLOR=Red][B]74.125.136.26[/B][/COLOR]
;; Query time: 41 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Sun Nov 9 05:07:06 2014
;; MSG SIZE rcvd: 60
Das Phone wird dann 74.125.136.26:587 (Port 587 = SMTP-Protokoll, verschlüsselt) "anrufen", um die Mails zu senden (alternativ Ports 25, 465).
Benutzt man (Google's) Web-Mail läuft das immer über Port 443 (HTTPS) verschlüsselt ab, wie im Browser auch, klar.
(Das läuft wieder unter TCP, siehe "Netzwerk Log" App.)
Schritt 3: IP-Adresse eines Google Mail-Servers zum EMPFANGEN von Mails finden
Jetzt sucht sich das Phone einen IMAP-Server fragt wieder OpenDNS nach einer IP-Adresse.
(Das Phone kennt die Domäne des IMAP-Servers, z. B. imap.gmail.com, weil die in der Mail-App eingetragen ist. - Das gleiche kann man auch für den SMTP-Server sagen, über den Mails versendet werden.)
Wir machen es wieder mit einer Linux Box nach:
Code:
terminal@linux # your command?[B] dig @208.67.222.222 [COLOR=SeaGreen]imap.gmail.com[/COLOR][/B]
; <<>> DiG 9.8.1-P1 <<>> @208.67.222.222 imap.gmail.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30620
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;imap.gmail.com. IN A
;; ANSWER SECTION:
imap.gmail.com. 300 IN CNAME gmail-imap.l.google.com.
[COLOR=SeaGreen][B]gmail-imap.l.google.com[/B][/COLOR]. 300 IN A [COLOR=Red][B]173.194.65.108[/B][/COLOR]
gmail-imap.l.google.com. 300 IN A [B]173.194.65.109[/B]
;; Query time: 88 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Sun Nov 9 05:24:39 2014
;; MSG SIZE rcvd: 98
Das Phone wird dann 173.194.65.108:993 (Port 993 = IMAP-Protokoll, verschlüsselt) "anrufen", um die Mails zu senden.
Benutzt man (Google's) Web-Mail läuft das immer über Port 443 (HTTPS) verschlüsselt ab, wie im Browser auch, klar.
(Das läuft wieder unter TCP, siehe "Netzwerk Log" App.)
___
Code:
IP6TABLES=/system/bin/ip6tables
IPTABLES ist eine Variable im Script, die einfach nur den physikalischen Pfad zum iptables Programm (binary) enthält. - Diese binary ist für IPv4 zuständig (/system/bin/iptables).
IP6TABLES (bzw. der Inhalt der Shell-Script-Variablen) ist das entsprechende Programm für IPv6 (/system/bin/ip6tables; Nachschauen: ist es dort in der ROM?). - Aktuell wird IPv6 kaum eingesetzt. - Deswegen sieht man auf der Entwicklerseite auch fast keine Regeln für IPv6 in den Beispielen.
(Dann ist auch die Frage, ob ein Smartphone - also die ROM - überhaupt IPv6 "spricht" bzw., ob IPv6 nicht sowieso deaktiviert/geblockt ist.)
SSH Verbindung auf ein Motorola Defy (MB525) und Suche nach Spuren von IPv6:
Beide binaries sind vorhanden ...
which fragt, wo das Programm <X> im Dateisystem liegt, wenn es nicht gefunden wird, wird nichts ausgegeben.:
Code:
root@mb526 /system/etc # [B]which iptables[/B]
/system/bin/iptables
root@mb526 /system/etc # [B]which ip6tables[/B]
/system/bin/ip6tables
root@mb526 /system/etc #
Mit grep durchsuchen wir alle Dateien (*) im aktuellen Verzeichnis (/system/etc/) nach dem Text "ipv6" - Groß-/Kleinschreibung egal (-i).
Am Anfang der Ergebnis-Liste steht für jede Zeile, in der etwas gefunden wurde, der Dateiname der Fundstelle.
Code:
root@mb526 [COLOR=Red][B]/system/etc[/B][/COLOR] # [I][B]grep -i ipv6 *[/B][/I]
[B]apns-conf.xml[/B]: <apn carrier="Telenor" mcc="242" mnc="01" apn="telenor.mobil" mmsc="http://mmsc/" mmsproxy="10.10.10.11" mmsport="8080" type="default,supl,mms" protocol="IPV6" roaming_protocol="IPV6" />
apns-conf.xml: <apn carrier="T-Mobile US LTE IPv6" mcc="310" mnc="260" apn="fast.t-mobile.com" user="none" password="none" server="*" mmsc="http://mms.msg.eng.t-mobile.com/mms/wapenc" type="default,supl,mms" protocol="IPV6" />
[...]
[B]clatd.conf[/B]:ipv6_host_id ::464
clatd.conf:# ipv6 extra link local address for the ip6 iface.
clatd.conf:ipv6_local_address fe80::c000:0004
[...]
[COLOR=Red][B]sysctl.conf[/B][/COLOR]:net.ipv6.conf.all.accept_dad=0
sysctl.conf:net.ipv6.conf.all.dad_transmits=0
sysctl.conf:net.ipv6.conf.all.use_tempaddr=0
sysctl.conf:net.ipv6.conf.default.accept_dad=0
sysctl.conf:net.ipv6.conf.default.dad_transmits=0
sysctl.conf:net.ipv6.conf.default.use_tempaddr=0
sysctl.conf:net.ipv6.conf.[B]default.[COLOR=Red]disable_ipv6[/COLOR]=1[/B]
sysctl.conf:net.ipv6.conf.[B]all.disable_ipv6=1[/B]
sysctl.conf:net.ipv6.conf.[B]lo.disable_ipv6=1[/B]
root@mb526 [B]/system/etc[/B] #
Die Zeile(n) in den AFWall+ Einstellungen in den Feldern für die Start- und Stop-Scripte werden von AFWall+ gesourcet (source oder dot "." command, siehe Dokumentation Shell Scripting; z. B. zu Linux man bash).
Deswegen ist die Shebang-Zeile (#!/system/bin/sh), die auf die auszuführende Shell verweist, hier eher unnötig.
Wenn man ein solches Script als eigene Datei im Terminal (Android Terminal Emulator oder einer adb shell oder über ssh) manuell ausführen möchte, dann macht die Shebang-Zeile wieder Sinn. - Innerhalb von AFWall+ eher nicht.
_
Auszug Linux man bash
Syntax:
. filename [arguments]
source filename [arguments]
Description:
Read and execute commands from filename in the current shell environment and return the exit status of used to find the directory containing filename. The file searched for in PATH need not be executable. Tthe last command executed from filename. If filename does not contain a slash, file names in PATH are. When bash is not in posix mode, the current directory is searched if no file is found in PATH. If the sourcepath option to the shopt builtin command is turned off, the PATH is not searched. If any arguments are supplied, they become the positional parameters when filename is executed. Otherwise the positional parameters are unchanged. The return status is the status of the last command exited within the script (0 if no commands are executed), and false if filename is not found or cannot be read.
an0n schrieb:[...] wahrscheinlich ist es aber nicht nötig für OpenDNS, vom Afwall-Entwickler wird es aber empfohlen, das immer bei einem Script anzugeben:
[...] Alle UDP-Verbindungen gehen über OpenDNS.Code:IP6TABLES=/system/bin/ip6tables IPTABLES=/system/bin/iptables
Mir ist jedoch aufgefallen, dass die meisten TCP-Verbindungen nicht über OpenDNS gehen. Eben hab ich gelesen, dass es für TCP-Verbindungen unterschiedliche Ports gibt. Bin mir nicht sicher ob ich die auch über OpenDNS einstellen kann.
Zuletzt bearbeitet: