Erfolgreiche SSH-Anmeldung über IPv6 bei Verwendung von IPv4 zum gleichen Host führt zu „Zugriff verweigert“

Question 1

Nachdem die Dinge immer seltsamer wurden (siehe den Kommentar-Thread in meiner Frage), habe ich es endlich herausgefunden. Das Wichtigste zuerst: Der AuthentifizierungsprozesstatFehler in pam_access.so, jedoch nicht aufgrund einer Fehlkonfiguration, /etc/security/access.confwie vermutet.

Um zu verstehen, warum, müssen wir uns insbesondere die Konfiguration dieser Box ansehen: Sie fungiert als Router für IPv4, das nativ über die PPP-Verbindung läuft, und für IPv6, das über einen 6in4-Tunnel läuft. Außerdem fungiert diese Box als rekursiver DNS-Resolver, und hier wird es interessant. Ich habe den Resolver so konfiguriert, dass IPv4-Reverse-Lookups rekursiv aufgelöst werden, beginnend mit den IPv4-Root-Servern, und IPv6-Reverse-Lookups beginnen mit den IPv6-Root-Servern. Diese Konfiguration funktionierte, als ich sie zum ersten Mal installierte.

Jetzt kommt mein ISP ins Spiel und Leute, die nicht verstehen, wie DNS-Amplification-Angriffe funktionieren. Um es kurz zu machen: Ich weiß mit Sicherheit, dass mein ISP eingehende DNS-Pakete willkürlich manipuliert, d. h. einige Dinge müssen seit einiger Zeit über ihre eigenen Resolver aufgelöst werden, während die Auflösung anderer DNS-Adressen rekursiv auf eigene Faust funktioniert – der offizielle Grund ist die Abschwächung von DNS-Amplification-Angriffen, aber sie machen es dann falsch^1.

Da ich mein Setup nicht grundlegend ändern wollte, habe ich die DNS-Resolver meines ISPs einfach als nicht rekursive Weiterleitung an das Ende meines lokalen DNS-Resolvers gesetzt, sodass, wenn der rekursive Auflösungsversuch abläuft, die Resolver meines ISPs ausprobiert werden. Das funktioniert soweit. Aber als ich das konfiguriert habe, habe ich einen kleinen Fehler gemacht: Ich habe die DNS-Resolver des ISPs so eingegeben, dass sie nur von Hosts innerhalb meines lokalen Bereichs funktionieren, also 192.168.0.0/16, habe aber localhost vergessen, auch bekannt als mein Router, also den Host, mit dem ich per SSH zu verbinden versuchte, für den der ResolvernichtBerücksichtigen Sie die Resolver des ISP.

pam_access.so versucht eine umgekehrte Suche nach der Adresse des Peers; und damit schließt sich der Kreis: Da für die umgekehrte Suche nach IPv6 auf die DNS-IPv6-Root-Server zugegriffen würde, würden die Pakete durch den 6in4-Tunnel gehen, ohne dass mein ISP sie stört und eine Antwort erhält. Die umgekehrte Suche nach IPv4 würde jedoch nicht von mir über die Resolver des ISPs durchgeführt, was keine Antwort erhalten und letztendlich einen NXHOST melden würde (oder es würde in einem Timeout laufen). Wie auch immer, pam_access.so sieht nichts, was ihm gefällt, und sagt einfach „Du kommst nicht durch“.

Nachdem ich die Resolver-Konfiguration repariert habe, funktioniert jetzt alles wieder wie am Schnürchen.Aber jetzt muss ich meinem ISP wirklich auf die Füße treten …

Und wie habe ich das Problem gelöst? Nun, indem ich die Ausführlichkeit der Protokollierung intensiv untersucht habe, /var/log/everythingum zu sehen, in welcher Reihenfolge sich die Dinge entwickelten. Als ich sah, dass mein Resolver die Reverse-Lookup-Versuche protokollierte, wusste ich, was los war.

1: Aus Sicht der DNS-Amplification-Minderung ist das völliger Unsinn, denn ich habe Tests durchgeführt und ausgehende DNS-Pakete kommen problemlos durch – aber das sind die Pakete, die sie filtern sollten. Tatsächlich sollte jeder Endkunden-ISP alle UDP-Pakete verwerfen, deren Absenderadresse nicht mit der seiner Kunden übereinstimmt.

Answer