[gelöst] Angeblicher Ladefehler iptable rules beim Start

[Piepnase]

Hallo zusammen,
nachdem ich ein paar Regeln definiert und mit iptables-save gespeichert habe, wollte ich ausprobieren, ob diese nach dem Neustart noch aktiv sind. Beim Booten kommt aber folgende Meldung:
[FAIL] Loading Iptable rules...IPv4...[failed]

Gebe ich nach dem Start in der Shell iptables -L ein, werden mir aber alle meine Regeln angezeigt.Was hat es mit der obigen Meldung auf sich, wenn doch augenscheinlich die Regeln nach dem Neustart geladen sind? Wo liegt da der Hase im Pfeffer?

Vielen Dank im Voraus für Eure Antworten

[eggy]

Poste Dein Regelwerk bzw verwendetes Script (wo/wie lädst Du die Regeln wieder ein? iptables-restore? benutzt Du noch was anderes?), dann kann vielleicht jemand erkennen, woran es liegen könnte.

[Piepnase]

Hallo,
ich hatte zwischenzeitlich iptables-persistent deinstalliert und es dann versucht mit

Code: Alles auswählen

apt-get install iptables-persistent

wieder zu installieren. Dabei tart dann die nachstehende Meldung auf:

Code: Alles auswählen

Entpacken von iptables-persistent (aus .../iptables-persistent_0.5.7_all.deb) ...
iptables-persistent (0.5.7) wird eingerichtet ...
[FAIL] Loading iptables rules... IPv4...failed.
invoke-rc.d: initscript iptables-persistent, action "start" failed.
dpkg: Fehler beim Bearbeiten von iptables-persistent (--configure):
 Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück
Fehler traten auf beim Bearbeiten von:
 iptables-persistent
E: Sub-process /usr/bin/dpkg returned an error code (1)

Und hier die Standard-Regeln, die nach dem Start gelten, da ich meine aufgrund des Fehlers erst einmal "zur Seite gepackt", aber zwecks Fehlersuche nicht aktiv habe.

Code: Alles auswählen

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination  

Bisher habe ich die Regeln entsprechend ergänzt und dann mit

Code: Alles auswählen

iptables-save > /etc/iptables/regeln.v4

gesichert und mit

Code: Alles auswählen

iptables-restore < /etc/iptables/regeln.v4

wieder geladen.

[eggy]

Halb installierte Pakete bringen nur Ärger, versuch erstmal das Paket vollständig loszuwerden oder neu zu installieren (so dass es keine Fehler wirft) (apt-get purge bzw apt-get install --reinstall)
Evtl solltest Du Deine Regeln solange mal wegschieben, denn möglicherweise versucht er die Dateien zu löschen/überschreiben und sieht dass da was ist, was nicht von ihm war.

[Piepnase]

Okay, das hat funktioniert! Vielen Dank!

Noch eine Frage: soweit ich weiß und so wird es überall beschrieben, greifen die Policies erst, wenn keine der definierten Regeln zutrifft, also am Ende der jeweiligen Kette.Stelle ich nun

Code: Alles auswählen

iptables -P OUTPUT DROP

, ist kein Internetzugriff mehr möglich, obwohl dieser

Code: Alles auswählen

-A INPUT -p tcp --dport 80 -j ACCEPT

freigegeben ist. Natürlich habe ich auch den Port 443 freigeschaltet.

Auch der Fernzugriff funktioniert nicht, wenn ich

Code: Alles auswählen

iptables -P INPUT DROP

setze, obwohl der SSH-Port via

Code: Alles auswählen

-A INPUT -p tcp --dport 22 -j ACCEPT

freigegeben ist.

Hat sich an diesen grundsätzlichen Regelungen, dass die Policies erst gelten, wenn keine der zuvor definierten Regeln zutrifft, etwas geändert? Oder was mache ich falsch?

[dufty2]

Du machst was falsch

filter:
This is the default table (if no -t option is passed). It contains the built-in chains INPUT (for packets destined to local sockets), FORWARD (for packets being routed through the box), and OUTPUT (for locally-generated packets).

TCP ist bi-direktional, d. h. wenn Du zwar Port 22 reinwärts (zu Dir) erlaubst, aber rauswärts alles per Policy verwirfst, bekommt der externen ssh-client nie eine Antwort von Deinem ssh-server zu sehen.
Ditto Internetzugriff.

[Piepnase]

Sorry, war ein Verständigungsfehler meinerseits. Die Ports 80, 443 und 22 sind bereits für INPUT und OUTPUT geöffnet. Setze ich die Policies dann auf DROP, ist Schluss mit Internet- und SSH-Zugriff.

[4A4B]

Die Ports 80, 443 und 22 sind bereits für INPUT und OUTPUT geöffnet.

... dabei die jeweils passende Option --dport bzw. --sport verwendet?

[dufty2]

Sorry, war ein Verständigungsfehler meinerseits. Die Ports 80, 443 und 22 sind bereits für INPUT und OUTPUT geöffnet. Setze ich die Policies dann auf DROP, ist Schluss mit Internet- und SSH-Zugriff.

Bi-direktional heisst nicht "symmetrisch in Ports", denn:
Normalerweise baut der Client eine Verbindung von seinem sog. High-port (port > 1023) auf, also
Client-IP:>1023 => Server-IP:22
Die Rückantwort des SSH-Servers ist dann
Server-IP:22 => Client-IP:>1023
D.h., Port 22 in OUTPUT zu Öffnen bringt somit nix.

Code: Alles auswählen

# iptables -F
# iptables -P INPUT   DROP
# iptables -P FORWARD DROP
# iptables -P OUTPUT  DROP
# iptables -A INPUT   -i eth0 -p tcp              --dport  22     -m conntrack --ctstate NEW,ESTABLISHED     -j ACCEPT
# iptables -A INPUT   -i eth0 -p tcp -m multiport --sports 80,443 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# iptables -A OUTPUT  -o eth0 -p tcp              --sport  22     -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# iptables -A OUTPUT  -o eth0 -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED     -j ACCEPT

Oder so ähnlich

[Piepnase]

Tja, was soll ich sagen...
Sobald die Policies auf DROP stehen kann ich keinerlei Verbindung mehr zum Internet aufbauen:

Code: Alles auswählen

Chain INPUT (policy DROP 6 packets, 296 bytes)
target     prot opt in     out     source               destination         
ACCEPT     all  --  lo     any     anywhere             anywhere            
ACCEPT     tcp  --  eth0   any     anywhere             anywhere             tcp dpt:22 ctstate NEW,ESTABLISHED
ACCEPT     tcp  --  eth0   any     anywhere             anywhere             multiport sports http,https ctstate RELATED,ESTABLISHED

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy DROP 54 packets, 3310 bytes)
target     prot opt in     out     source               destination         
ACCEPT     all  --  any    lo      anywhere             anywhere            
ACCEPT     tcp  --  any    eth0    anywhere             anywhere             tcp spt:22 ctstate RELATED,ESTABLISHED
ACCEPT     tcp  --  any    eth0    anywhere             anywhere             multiport dports http,https ctstate NEW,ESTABLISHED

Diese Variante funktioniert, aber dann kann ich die ganzen Regeln auch gleich weglassen, denn ein offenes Scheunentor ist nix dagegen. Langsam aber sicher habe ich echt die Faxen dicke.

Code: Alles auswählen

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:22 ctstate NEW,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere             multiport sports http,https ctstate RELATED,ESTABLISHED

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     tcp  --  anywhere             anywhere             tcp spt:22 ctstate RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere             multiport dports http,https ctstate NEW,ESTABLISHED

[4A4B]

Ich würde bei iptables noch die Option -v verwenden, dann wird auch bei den einzelnen Regeln ein Counter (pkts, bytes) angezeigt, und du siehst dann leichter welche Regeln greifen, und welche nicht

Dann würde ich zur Fehlereingrenzung erstmal nur von OUTPUT und dann nur von INPUT die Policy auf ACCEPT setzen

[Piepnase]

Inkl. -v und --line-number sieht es so aus:

Code: Alles auswählen

Chain INPUT (policy ACCEPT 22 packets, 1492 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        2   156 ACCEPT     all  --  lo     any     anywhere             anywhere            
2        0     0 ACCEPT     tcp  --  eth0   any     anywhere             anywhere             tcp dpt:76543 ctstate NEW,ESTABLISHED
3       93 43450 ACCEPT     tcp  --  eth0   any     anywhere             anywhere             multiport sports http,https ctstate RELATED,ESTABLISHED

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 23 packets, 1328 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        2   156 ACCEPT     all  --  any    lo      anywhere             anywhere            
2        0     0 ACCEPT     tcp  --  any    eth0    anywhere             anywhere             tcp spt:76543 ctstate RELATED,ESTABLISHED
3      104 28951 ACCEPT     tcp  --  any    eth0    anywhere             anywhere             multiport dports http,https ctstate NEW,ESTABLISHED

Da ich für SSH nicht den Standardport, sondern einen abweichenden Port nutze (natürlich nich den oben eingetragenen ), steht anstelle der 22 die 76543.
Schalte ich nur INPUT auf DROP und FORWARD und OUTPUT auf ACCEPT, nudelt sich der Browser nen Wolf. Schalte ich INPUT auf ACCEPT und OUTPUT auf DROP, bekomme ich sofort die Info, dass keine Netzwerkverbindung möglich ist.

[dufty2]

DNS (Namensauflösung) wirst Du natürlich auch noch zulassen müssen.

Code: Alles auswählen

# iptables -A INPUT -i eth0 -p udp --sport 53 -j ACCEPT
# iptables -A OUTPUT -o eth0 -p udp --dport 53 -j ACCEPT

[Piepnase]

Hallo, nein, auch nachdem ich noch, was ich zugegebenermaßen vergessen hatte, Port 53 hinzugefügt habe, funktioniert kein Internetzugang, wenn ich die Policies auf DROP stelle. Meine Regeln sehen jetzt so aus:

Code: Alles auswählen

Chain INPUT (policy ACCEPT 583 packets, 656K bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        4   312 ACCEPT     all  --  lo     any     anywhere             anywhere            
2        0     0 ACCEPT     udp  --  eth0   any     anywhere             anywhere             udp spt:domain
3        0     0 ACCEPT     tcp  --  eth0   any     anywhere             anywhere             tcp dpt:76543 ctstate NEW,ESTABLISHED
4        0     0 ACCEPT     tcp  --  eth0   any     anywhere             anywhere             multiport sports http,https ctstate RELATED,ESTABLISHED

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 435 packets, 38284 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        4   312 ACCEPT     all  --  any    lo      anywhere             anywhere            
2        0     0 ACCEPT     udp  --  any    eth0    anywhere             anywhere             udp dpt:domain
3        0     0 ACCEPT     tcp  --  any    eth0    anywhere             anywhere             tcp spt:76543 ctstate RELATED,ESTABLISHED
4        0     0 ACCEPT     tcp  --  any    eth0    anywhere             anywhere             multiport dports http,https ctstate NEW,ESTABLISHED

Damit habe ich Zugriff auf das Internet, nur wie schon mal gesagt, solange die Policies auf ACCEPT stehen, kann ich mir alles andere auch sparen. Ich verstehe das langsam aber sicher nicht mehr. Hat noch irgendwer eine Idee, wie ich die Regeln ans laufen bekomme mit den Policies auf DROP? Ich verzweifle da ein bisschen.

[4A4B]

Die Counter von Regel 2 bis 4 stehen jeweils auf 0. Wann hast du iptables -L aufgerufen, nach oder vor deinem Versuch, eine Webseite abzurufen?

Ist eth0 das Interface, über welches du ins Internet gehst?

[dufty2]

Also hier mein Testballon:
Man sieht, ich habe wlan0 statt eth0, sollte aber egal sein.
Weiterhin hab' ich nicht mal das Loopback-Interface "lo" freigestellt und sogar noch "related" rausgeworfen.
Die /etc/resolv.conf enthält nur die Zeile
nameserver 8.8.8.8

=> Damit kann ich surfen!

Code: Alles auswählen

# iptables -L -n -v
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     tcp  --  wlan0  *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22 ctstate NEW,ESTABLISHED
 3245 3525K ACCEPT     tcp  --  wlan0  *       0.0.0.0/0            0.0.0.0/0            multiport sports 80,443 ctstate ESTABLISHED
   28  2285 ACCEPT     udp  --  wlan0  *       0.0.0.0/0            0.0.0.0/0            udp spt:53 ctstate ESTABLISHED

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy DROP 60 packets, 4560 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     tcp  --  *      wlan0   0.0.0.0/0            0.0.0.0/0            tcp spt:22 ctstate ESTABLISHED
 2674  234K ACCEPT     tcp  --  *      wlan0   0.0.0.0/0            0.0.0.0/0            multiport dports 80,443 ctstate NEW,ESTABLISHED
   28  1685 ACCEPT     udp  --  *      wlan0   0.0.0.0/0            0.0.0.0/0            udp dpt:53 ctstate NEW,ESTABLISHED

[Piepnase]

@4A4B
Ja, eth0 ist die Netzwerkkarte, hatte dafür sogar extra das LAN-Kabel eingesteckt, um es zu testen. Ich werde es noch mal mit wlan0 probieren. Wenn die Regeln nicht funktionieren, müsse es mit wlan0 ja genauso in die Hose gehen. Dass die Counter auf 0 stehen hat mich auch stutzig gemacht. Zeigt es ja, dass bei diesen Regeln nix passiert. Gut, bei SSH ist das klar, da habe ich mit diesen Regeln noch keinen Verbindungsaufbau ausprobiert.
Ähm, ich weiß jetzt gerade leider nicht mehr so genau, ob ich die Zeilen vor oder nach dem Internetzugriffsversuch kopiert habe. Ich mache nachher noch mal einen vor und einen nach dem Versuch und probiere auch SSH bzw. SFTP aus. Dann sollten dort die Counter Einträge bekommen, oder eben nicht.

@dufty2
Sperrst Du Dich im schlechtesten Fall ohne Loopback nicht selber aus? Ich meine ich hätte bei meinen ganzen Recherchen zu iptables sowas gelesen. Dein Regelwerk werde ich nachher auch mal testen, vielleicht klappt es ja auch bei mir.

Ich probiere jetzt schon solange und habe so viel recherchiert, dass ich echt nicht mehr weiß, was ich noch anstellen kann, zumal die Regeln anstandslos von iptables-persistent beim Start geladen werden.

[Piepnase]

Zu allererst möchte ich mich bei allen hier bedanken, die mir so unkompliziert und sehr hilfreich auf die Sprünge geholfen haben! DANKE!!!

So, nun zum Ergebnis:
Ich habe 3 Schnittstellen, eth0, wlan0 und lo. Jetzt habe ich einfach mal bei den Regeln eth0 durch wlan0 ersetzt und man glaubt es kaum, jetzt habe ich tatsächlich bei allen Regeln (bis auf SSH, das habe ich immer noch nicht probiert ) Einträge:

Code: Alles auswählen

Chain INPUT (policy DROP 185 packets, 9910 bytes)                                                                                                                                                                                            
num   pkts bytes target     prot opt in     out     source               destination                                                                                                                                                         
1      111  8804 ACCEPT     all  --  lo     any     anywhere             anywhere                                                                                                                                                            
2      697 78780 ACCEPT     udp  --  wlan0  any     anywhere             anywhere             udp spt:domain                                                                                                                                 
3        0     0 ACCEPT     tcp  --  wlan0  any     anywhere             anywhere             tcp dpt:76543 ctstate NEW,ESTABLISHED                                                                                                          
4      352  199K ACCEPT     tcp  --  wlan0  any     anywhere             anywhere             multiport sports http,https ctstate RELATED,ESTABLISHED                                                                                        
                                                                                                                                                                                                                                             
Chain FORWARD (policy DROP 0 packets, 0 bytes)                                                                                                                                                                                               
num   pkts bytes target     prot opt in     out     source               destination                                                                                                                                                         
                                                                                                                                                                                                                                             
Chain OUTPUT (policy DROP 5395 packets, 324K bytes)                                                                                                                                                                                          
num   pkts bytes target     prot opt in     out     source               destination                                                                                                                                                         
1      111  8804 ACCEPT     all  --  any    lo      anywhere             anywhere                                                                                                                                                            
2      697 46938 ACCEPT     udp  --  any    wlan0   anywhere             anywhere             udp dpt:domain                                                                                                                                 
3        0     0 ACCEPT     tcp  --  any    wlan0   anywhere             anywhere             tcp spt:76543 ctstate RELATED,ESTABLISHED                                                                                                      
4      364 47106 ACCEPT     tcp  --  any    wlan0   anywhere             anywhere             multiport dports http,https ctstate NEW,ESTABLISHED  

Jetzt stellt sich mir natürlich die Frage, warum alles im grünen Bereich ist, wenn ich wlan0 anstelle von eth0 nutze. Obwohl der Internetzugriff über eth0 möglich ist, solange die Policies auf ACCEPT stehen? Habt Ihr soetwas schon einmal erlebt?
Bin für jede Info, jede Idee dankbar, da der Server, auf dem IPTABLES letztlich laufen soll, die eth0-Schnittstelle für den Internetzugriff nutzt.

Vielen Dank im Voraus

[dufty2]

Deine Internetverbindung geht über wlan0 (Hättest aber das gleich sagen können )

Wenn Du nun - wie anfangs geschehen - für eth0 die Regeln auf ACCEPT einstellt,
passiert gar nichts (d. h. das Internet geht nach wie vor), da ja überhaupt kein Traffic/Paket über eth0 geht.

Stellst Du die POLICY auf DROP, gilt dies aber für alle Deine Interfaces (auch wenn sie nicht explicit aufgeführt werden), also für wlan0, eth0 und lo (und falls es noch weitere gäbe, z. B. eth1, eth2, würde es auch noch für diese gelten).
Daher hat nach "POLICY DROP"-Aktivierung nichts mehr funktioniert.

Am Schluß hast Du das richtige Interface (wlan0) erwischt und nun werden selbst bei der "POLICY DROP" durch die ACCEPT-rules für wlan0 das Surfen wieder ermöglicht.

[Piepnase]

Nee, die Internetverbindung hatte ich bei der Installation von Debian über eth0 eingerichtet. Ich habe also die ganze Zeit über LAN auf das Internet zugegriffen. Als die Regeln aber partout nicht funktionierten und der User 4A4B seine Regeln gepostet hat, wo der Zugriff über wlan0 läuft, habe ich zu Testzwecken die WLAN Schnittstelle eingerichtet. Dann habe ich die Regeln alle von eth0 auf wlan0 umgestellt und seit dem läuft es.

[eggy]

"/sbin/route -nv "
Und noch ne Frage: betreibst Du einen Webserver auf der Kiste, und soll per ssh auf Deine Kiste zugegriffen werden, oder willst Du per ssh auf andere Rechner zugreifen?

[Piepnase]

@eggy:
Nachdem ich die wlan0-Schnittstelle eingerichtet habe, kommt folgendes Ergebnis bei "/sbin/route .nv"

Code: Alles auswählen

Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         ***.***.**.**   0.0.0.0         UG    0      0        0 wlan0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0
192.***.***.0   0.0.0.0         255.255.255.0   U     0      0        0 wlan0

Schließe ich das LAN-Kabel an die Netzwerkkarte (eth0) an, kommt folgendes Ergebnis:

Code: Alles auswählen

Ziel            Router          Genmask         Flags Metric Ref    Use Iface                                        
0.0.0.0       ***.***.**.**     0.0.0.0         UG    0      0        0 eth0                                         
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0                                        
192.+++.+++.+   0.0.0.0         255.255.255.0   U     0      0        0 wlan0                                        
192.+++.+++.+   0.0.0.0         255.255.255.0   U     0      0        0 eth0  

Die * und + sind natürlich richtige Zahlen. Beim 2. Code-Schnipsel verstehe ich nicht, wieso neben wlan0 nun auch eth0 auftaucht. Die ZIEL-IPs sind identisch, was ich mit den + ausdrücken möchte. Mit der Ziel-IP 169.254.0.0 kann ich nicht viel anfangen, da muss ich noch Mr. Google befragen.

Nein, auf dieser Kiste hier teste ich das System erst einmal nur inkl. Webserver, PHP, MySQL, PHPMyAdmin. Später soll das dann auf einem anderen System produktiv laufen. Von meiner Kiste hier will ich dann per SSH auf das Produktivsystem zugreifen. Vom Produktivsystem ausgehend soll aber keine SSH-Verbindung aufgebaut werden.

Mit den nachstehenden Regeln, die ansonsten soweit funktionieren, kann ich von meinem Rechner aus keine SSH-Verbindung aufbauen.

Code: Alles auswählen

Chain INPUT (policy DROP 22 packets, 1311 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        6   468 ACCEPT     all  --  lo     any     anywhere             anywhere            
2        3   240 ACCEPT     udp  --  wlan0  any     anywhere             anywhere             udp spt:domain
3        0     0 ACCEPT     tcp  --  wlan0  any     anywhere             anywhere             tcp dpt:76543 ctstate NEW,ESTABLISHED
4       29 15876 ACCEPT     tcp  --  wlan0  any     anywhere             anywhere             multiport sports http,https ctstate RELATED,ESTABLISHED

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        6   468 ACCEPT     all  --  any    lo      anywhere             anywhere            
2        3   180 ACCEPT     udp  --  any    wlan0   anywhere             anywhere             udp dpt:domain
3        0     0 ACCEPT     tcp  --  any    wlan0   anywhere             anywhere             tcp spt:76543 ctstate RELATED,ESTABLISHED
4       31  2804 ACCEPT     tcp  --  any    wlan0   anywhere             anywhere             multiport dports http,https ctstate NEW,ESTABLISHED

Ich muss an meiner Kiste und auf dem Server, auf den ich zugreifen, zwingend die INPUT- und OUPUT Policies auf ACCEPT stellen, damit ich per SSH zugreifen kann. Auf dem Server gibt es nur die eth0 und die lo-Schnittstelle und die obigen Regeln habe ich dort natürlich mit eth0 anstelle von wlan0 eingerichtet. Was muss ich an meinem Regelwerk ändern, damit ich mit INPUT und OUTPUT Policy auf DROP auf Client und Server trotzdem eine SSH-Verbindung aufbauen kann?

Bin für jeden Hinweis dankbar.

[dufty2]

Die 169.254.0.0/16 sind harmlos, link local oder - bei M$ - besser als APIPA bekannt.
Welches Debian verwendest Du und wie werden die Schnittstellen konfiguriert?
NetworkManger? /etc/network/interfaces?

[Piepnase]

Ich nutze Debian 7.8 Wheezy. Die eth0-Schnittstelle wurde automatisch bei der Installation eingerichtet. Die wlan0 habe ich über die Netzwerkverwaltung eingerichtet. Mit dem veränderten Port für SSH kann das m. E. nicht zusammenhängen, da ich den ja mehrfach schon getestet und ihn in meinen Regeln ja auch eingetragen habe.

[dufty2]

Mit den nachstehenden Regeln, die ansonsten soweit funktionieren, kann ich von meinem Rechner aus keine SSH-Verbindung aufbauen.

Code: Alles auswählen

Chain INPUT (policy DROP 22 packets, 1311 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        6   468 ACCEPT     all  --  lo     any     anywhere             anywhere            
2        3   240 ACCEPT     udp  --  wlan0  any     anywhere             anywhere             udp spt:domain
3        0     0 ACCEPT     tcp  --  wlan0  any     anywhere             anywhere             tcp dpt:76543 ctstate NEW,ESTABLISHED
4       29 15876 ACCEPT     tcp  --  wlan0  any     anywhere             anywhere             multiport sports http,https ctstate RELATED,ESTABLISHED

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        6   468 ACCEPT     all  --  any    lo      anywhere             anywhere            
2        3   180 ACCEPT     udp  --  any    wlan0   anywhere             anywhere             udp dpt:domain
3        0     0 ACCEPT     tcp  --  any    wlan0   anywhere             anywhere             tcp spt:76543 ctstate RELATED,ESTABLISHED
4       31  2804 ACCEPT     tcp  --  any    wlan0   anywhere             anywhere             multiport dports http,https ctstate NEW,ESTABLISHED

Ja, das ist klar, dass ausgehende ssh nicht geht, da Du keine established-rule in der INPUT-Chain hast bei Policy drop, denn das "normale" 'ssh irgendwas' verwendet natürlich Port 22 und nicht "76543".

Abgesehen davon poste mal Deine /etc/network/interfaces, vermute mal ein Mischmasch mit dem Network-Manager (/etc/NetworkManager/system-connections/*) auf Deinen Test-PC.

Auf Deinen zukünftigen Server (mit nur einer Schnittstelle - eth0 -) sollten die Regel so wie von mir beschrieben funktionen.