Das klappt auch, es geht ums Broadcast (der Effekt ist hier der gleiche wie beim fehlenden nmbd von der 7390), die Dinger tauchen nicht in der Netzwerkübersicht auf (über eine PPTP Verbindung klappt es übrigens, so dass die Geräte sicher den Namen aussenden).
Das geht beim Windows-Netzwerk mit AVM-IPSec nur dann, wenn Du die FRITZ!Box am anderen Ende als WINS-Server im VPN-Client konfigurierst. Diese Namensauflösung arbeitet mit einer Mischung aus Broadcasts und Abfragen eines Master-Browsers (eben des WINS-Servers), die Reihenfolge der Abfragen wird über den NetBIOS-Node-Type festgelegt. Broadcasts werden über ein IPSec-VPN unter Linux normalerweise überhaupt nicht übertragen, da das Verpacken des Traffics in ESP-Pakete auf der Basis von "Selektoren" erfolgt ... matcht ein Paket so einen Selektor, wird es verpackt und an die im "Selektor" (eigentlich eine Transformationsregel) angegebene öffentliche Adresse gesendet, anstatt den "normalen Weg" zu nehmen.
Beim AVM-VPN kommt dann noch hinzu, daß alle Pakete für die Transformation unbedingt an "dev dsl" gehen müssen, das ist auch der Grund, warum es nicht funktioniert, eine VPN-Verbindung mit derselben Adresse zu betreiben (bzw. eigentlich ist das nur dann ein Problem, wenn diese VPN-Verbindung aktiviert ist - nicht "aufgebaut", das ist etwas anderes), weil für solche Host-LAN-Verbindungen eine Route der Form "192.168.188.xxx/32 dev dsl" eingerichtet wird, damit der Traffic für dieses Ziel auch am "dev dsl" vorbeikommt und nicht über "dev lan" im lokalen Netz landet (was der Maske nach ja der Fall wäre). Parallel richtet die FRITZ!Box dann für solche Adressen noch einen ARP-Proxy ein, damit jeder andere Client, der im Netz nach dieser Adresse sucht, die dorthin zu sendenden Pakete an die FRITZ!Box schickt, die sich dann um die Weiterleitung kümmert.
Für Broadcasts müßte man also eine weitere Route der Form "192.168.188.255/32 dev dsl" einrichten, die sich aber erkennbar nicht mit dem Rest des LANs verträgt, denn jetzt würden ja sämtliche Broadcasts nur noch in den Tunnel (bzw. erst einmal zum "dev dsl") wandern. An dieser Stelle helfen auch keine Zaubereien mit der "accesslist" einer VPN-Verbindung, denn die greift erst dann (das sind auf der FRITZ!Box die "Selektoren"), wenn die Pakete schon an "dev dsl" angekommen sind und das machen die Broadcasts ja nie. Eine denkbare Alternative wäre das Duplizieren solcher Broadcasts mit iptables (da das kein conntrack braucht, könnte das funktionieren) und der Versand der Duplikate über "dev dsl" in Kombination mit einem passenden Selektor, aber dann kann man auch gleich aus den Broadcast-Paketen Unicast-Traffic machen und sich den zusätzlichen Selektor sparen.
Richtig, jetzt kommt das interessante. Wenn ich die WINS Auflösung im Client deaktiviere oder auf automatisch beziehen stelle findet bei mir nbtstat -a <ip> nichts. Aktiviere ich es und gebe als Server die IP der Fritzbox an führt wenigstens der Befehl zu einem Ergebnis und auch NetBIOS over TCPIP ist "enabled".
Aus dem Bauch heraus würde ich dann sagen, daß der Shrewsoft-Client anhand des Vorhandenseins eines WINS-Servers (für den vnet-Adapter, so heißt der lt. Wireshark) entscheidet, ob der Windows-Netzwerkclient an dieses Interface gebunden wird oder nicht. Solange die FRITZ!Box das aber nicht setzt, bleibt Dir wieder nur die manuelle Auswahl, wobei das ja eigentlich pro Verbindung erfolgt und so sehe ich den Punkt "suboptimal" ohnehin nicht so kritisch und halte das Einstellen der richtigen Parameter für eine bestimmte Verbindung für ausreichend und zumutbar. Wer das komfortabler haben will, braucht einen DHCP-Server abseits der FRITZ!Box und einige Kopfstände, um einen DHCP-Request durch den IPSec-Tunnel zu befördern ... wobei das in Richtung FRITZ!Box ja der Shrewsoft-Client selbst macht und die Antwort des DHCP-Servers ja eigentlich Unicast (halt auf MAC-Ebene, denn es gibt ja noch keine IP-Adresse des Clients) ist. Das dann wieder durch den Tunnel zurück zum Client zu befördern, ist beim AVM-VPN nicht so einfach (wenn es überhaupt geht).
Ein Nebeneffekt der mir auch noch aufgefallen ist:
Wie oben erläutert, sollte das unproblematisch sein, solange Du die Verbindung für den Nutzer in der Liste der VPN-Verbindungen über die Checkbox in der ersten Spalte deaktivierst. Dann wird die Route nicht gesetzt und diese Adresse verhält sich wie eine ganz normale lokale auch.
Eine Zielsetzung ist eben, dass der Laptop von anderen Teilnehmern auch erreichbar ist wenn er nicht im lokalen Netz aber per VPN angemeldet ist. Das klappt wohl weder per Broadcast, DNS Name noch mit einer IP.
Das verstehe ich jetzt nicht ... der Laptop sollte bei
aktiveraufgebauter VPN-Verbindung von den Geräten aus dem LAN auch über diese VPN-Verbindung mit seiner IP-Adresse problemlos zu erreichen sein - auch über seinen DNS-Namen, wenn der (bei identischer lokaler und entfernter IP) richtig gesetzt ist.
Wenn er selbst die Geräte im LAN per Windows-Network erreichen soll, muß eben die FRITZ!Box als WINS-Server eingetragen werden. Allerdings gilt auch das natürlich nur dann, wenn die FRITZ!Box auch der oben erwähnte Master-Browser ist ... wenn jemand irgendeinen Windows-Server in seinem Netz hat oder die Einstellungen eines Windows-Clients geändert hat, kann es auch sein, daß ein anderes Gerät die Wahl zum Master-Browser gewinnt (das ist wirklich eine "election") und dann ist natürlich dieses Gerät der WINS-Server. Die FRITZ!Box ist kein WINS-Proxy, sie gibt meines Wissens ihre eigene "Weltsicht" auf das LAN nur dann in vollem Umfang weiter, wenn sie auch der Master-Browser ist. Ansonsten antwortet der nmbd auch auf Unicast-Abfragen nur mit den eigenen lokalen Angaben ... der nmbd ist ja genau der Teil des Samba-Paketes, der einerseits als Master-Browser fungieren kann (wenn die FRITZ!Box die Wahl gewinnt) und auf der anderen Seite auf Broadcast-Abfragen anderer Windows-Clients nach verfügbaren Windows-Dateiservern (auch nach Druckservern, nur der Vollständigkeit halber) dann mit den Angaben zum Samba-Server der FRITZ!Box antwortet. Fehlt der und bleibt damit die Antwort auf Broadcasts aus, ist die FRITZ!Box "unsichtbar" im Windows-Netzwerk.
EDIT: Was man vielleicht auch noch erwähnen sollte ... ein Windows-Client meldet sich selbst auch bei einem WINS-Server an. Somit sollte eigentlich (das teste ich jetzt aber nicht) die Angabe der FRITZ!Box als WINS-Servers sogar dafür sorgen, daß der entfernte Windows-Rechner sich beim WINS-Server registriert und lokale Windows-Clients, die die FRITZ!Box als WINS-Server abfragen (das muß UC sein und kein BC, also wirklich ein gesetzter WINS-Server in diesen Clients), den dann auch auflisten können. Ende EDIT
Ich weiß, daß Du den letzten Absatz selbst kennst, es ist mehr für spätere Leser, die ihrerseits zwei getrennte Broadcast-Domains mit einem Windows-Netzwerk verbinden wollen.
