Kleiner IPv6-Workshop

[Rooby]

Wenn Du nix dergleichen im LAN hast, kannst Du einen Raspberry Pi für diesen Zweck umrüsten.

Lässt sich dieser Tunnel nicht gleich auf dem Router per script einrichten.

[SpaceRat]

Wenn Du nix dergleichen im LAN hast, kannst Du einen Raspberry Pi für diesen Zweck umrüsten.

Lässt sich dieser Tunnel nicht gleich auf dem Router per script einrichten.

Je nach Router schon.

OpenWrt z.B. bringt dazu ab Chaos Calmer "tcpproxy" mit, zuvor 6tunnel.

[Conan179]

@SpaceRat
SUPER, so was suche ich shcon seid ich bei kabelbw bin.

Eine frage noch, was ist ein A-Recort und ein AAAA-Recort?
Der server hat kein debian drauf, dafür aber Ubuntu

Edit:
Verstehe ich das so richtig.
Meinem server verpasse ich die dyndns addresse:
oserver.conan.dyndns.de
und dan für den server eine reine ipv4 addresse:
ipv4.oserver.conan.dyndns.de
mit der ipv4 addresse des Servers und eine reine ipv6 addresse:
ipv6.oserver.conan.dyndns.de

verstehe ich das bis dahin richtig?

[SpaceRat]

Eine frage noch, was ist ein A-Recort und ein AAAA-Recort?

Im DNS-System
- ist ein A-Record die Zuordnung einer IPv4-Adresse zu einem (Host-)Name und
- ein AAAA-Record die Zuordnung einer IPv6-Adresse zu einem (Host-)Name.

Um das zu komplettieren:
- Ein CNAME ist die Zuordnung eines alternativen Namens (Alias) für einen anderen (Host-)Name.

Vor diesem Hintergrund meldet uns ein Aufruf von host oder nslookup genau dies zurück:

C:\>nslookup http://www.facebook.com
...
Name: star.c10r.facebook.com
Addresses: 2a03:2880:f01c:2:face:b00c:0:1
31.13.93.3
Aliases: www.facebook.com

= (Eigentlicher) Host-Name, AAAA-Record, A-Record, Alias(se) bzw. CNAME(s)

Der server hat kein debian drauf, dafür aber Ubuntu

Bäh.
Kommt aber bzgl.

Code: Alles auswählen

apt-get install 6tunnel

für die Installation von 6tunnel auf's Selbe raus.

Meinem server verpasse ich die dyndns addresse:
oserver.conan.dyndns.de
und dan für den server eine reine ipv4 addresse:
ipv4.oserver.conan.dyndns.de
mit der ipv4 addresse des Servers und eine reine ipv6 addresse:
ipv6.oserver.conan.dyndns.de

verstehe ich das bis dahin richtig?

Das hast Du richtig verstanden.
Pflicht ist das so natürlich nicht, nur ein (sinnvoller) Vorschlag.

Ziel ist ja ...

• Ein Hostname ohne Angabe des Protokolls drin, z.B. oserver.conan.dyndns.de (Mit A- und AAAA-Records)
  ... wäre dabei der "everyday use"-Hostname für Deinen Server.
  Unter dieser Adresse erreicht jeder korrekt konfigurierte Client diesen Server, egal ob er auch IPv6 oder nur IPv4 hat:
  Ein IPv6-Client nutzt bevorzugt den AAAA-Record und ein IPv4-Client nur den A-Record.

... also genau wie bei Facebook (s.o.).

Die anderen beiden braucht man nicht zwingend, aber ich halte sie für sinnvoll:

• Ein Hostname nur für IPv6, z.B. ipv6.oserver.conan.dyndns.de (Nur mit AAAA-Record)
  Dieser Hostname stellt z.B. - wenn Du ihn nutzt - sicher, daß es zu keiner Schleife beim Proxien von IPv4 auf IPv6 kommt.
  
  Ein Beispiel:

  Code: Alles auswählen

  6tunnel 443 oserver.conan.dyndns.de 443

  würde genauso als 4-to-6 Proxy funktionieren, aber es führt zumindest vom Bild her zu einer möglichen Schleife, da ja unter oserver.conan.dyndns.de auch die IPv4 des Systems hinterlegt ist, auf dem dieser 6tunnel läuft.
  Ich weiß nicht, ob es bei Ausfall der IPv6-Verbindung auf dem Proxy sogar tatsächlich zu einer solchen Schleife käme, spätestens aber bei Verwendung des Schalters -4 hast Du sie.
  
  Schreibst Du hingegen

  Code: Alles auswählen

  6tunnel 443 ipv6.oserver.conan.dyndns.de 443

  , dann ist schon beim ersten Blick klar, wohin dieser Tunnel führen soll.
  Bei Verwendung des Schalters -4 funktioniert dieser 6tunnel dann gar nicht mehr und ein klares Fehlerbild ist immer besser als diffuses Fehlverhalten.
• Ein Hostname nur für IPv4, z.B. ipv4.oserver.conan.dyndns.de (Nur mit A-Record)
  Wie oben beschrieben täte es für korrekt konfigurierte IPv4-only-Clients eigentlich auch der allgemeine Hostname oserver.conan.dyndns.de.
  
  Es gibt aber Fälle von fehlkonfigurierten Clients und Client-Netzen. So ist z.B. in OpenWrt werksseitig ein ULA-Präfix vorkonfiguriert, d.h. innerhalb des LAN hast Du hinter einem OpenWrt-Router immer IPv6, selbst wenn keine IPv6-fähige Internetverbindung eingerichtet ist.
  Je nachdem wie ein Client-Programm nun damit umgeht (Betrachtet es ULAs überhaupt als funktionierende IPv6-Anbindung? Fällt er auch bei "no route to host"/"Zielnetzwerk nicht erreichbar" auf IPv4 zurück?) kann es in diesem Fall zu Verzögerungen oder gar dem kompletten Scheitern des Verbindungsaufbaus kommen, wenn für den Server auch eine IPv6/AAAA-Record hinterlegt ist.
  Da ist es praktisch, wenn man durch einfaches Voranstellen von "ipv4." einen Verbindungsaufbau über IPv4 erzwingen kann.
  
  Den umgekehrten Fall gibt es dank Unitymedia übrigens auch:
  Die Schrottrouter TC7200 und Co. können auch mal die Verbindung zum AFTR-Gateway verlieren, dann ist das LAN dahinter "IPv6-only". Da die Clients aber weiterhin ihre privaten IPv4-Adressen kriegen, merken sie davon nix.
  Normal fällt das nicht weiter auf, da IPv6-fähige Clients eh IPv6 bevorzugen, aber wenn z.B. ausgerechnet zu diesem Zeitpunkt das Präfix des Servers wechselt, zeigt der AAAA-Record ja kurzfristig noch auf die alte Adresse, womit der Server für den Moment auch per IPv6 unerreichbar wird. Ein fehlerhafter Client könnte sich in dieser Situation auf die IPv4-Adresse des Servers einschießen ...

Aus den vorgenannten Gründen halte ich das zusätzliche Anlegen von protokollspezifischen DynDNSen für sinnvoll und sei es nur, um im Zweifelsfall einen gezielten Versuch damit machen zu können.

[SpaceRat]

Nachtrag

Warum ich die CNAMEs ins Spiel gebracht habe:
Je nach DynDNS-Anbieter kann man auch CNAMEs definieren (Nicht mit Webhop Redirects zu verwechseln!), z.B. bei FreeDNS.

Anstatt die IPs direkt zu hinterlegen, kann man dann auch mit CNAMEs arbeiten:

• ipv4.oserver.conan.dyndns.de wäre dann z.B. ein CNAME für den Hostname, den man bei feste-ip.net erhält, z.B. conan.feste-ip.net
  Da ipv4.oserver.conan.dyndns.de dann nur ein Alias für conan.feste-ip.net ist, wird im Endeffekt conan.feste-ip.net nachgeschlagen, so daß dieser Eintrag immer paßt, selbst wenn conan.feste-ip.net mal den Server wechseln sollte.
• Bei Verwendung einer Fritz!Box am DS-lite-Anschluß kann man ipv6.oserver.conan.dyndns.de als CNAME für den kryptischen MyFritz-Namen nehmen, den eine MyFritz-Freigabe erzeugt, also z.B. oserver.rghdiohndiufhndifubn.myfritz.net
  Da Fritz!Boxen diese kryptischen Hostname selber mit der aktuellen IPv6 pflegen (Daß die Fritz!Box keine öffentliche IPv4 hat merkt sie selber und macht dann keine A-Record-Updates!) und der merkbarere Hostname ipv6.oserver.conan.dyndns.de ja nur ein Alias dafür ist, braucht man in diesem Fall nicht mehr selber für DynDNS-Updates des IPv6-Hosts sorgen.
• Bei Verwendung einer Fritz!Box am Dual-Stack-Anschluß kann man oserver.conan.dyndns.de als CNAME für den kryptischen MyFritz-Namen nehmen, den eine MyFritz-Freigabe erzeugt, also z.B. oserver.rghdiohndiufhndifubn.myfritz.net
  Da Fritz!Boxen diese kryptischen Hostname selber mit den aktuellen IPv4- und IPv6-Adressen pflegen und der merkbarere Hostname oserver.conan.dyndns.de ja nur ein Alias dafür ist, braucht man in diesem Fall nicht mehr selber für DynDNS-Updates des Dual-Stack-Hosts sorgen.

[Conan179]

@SpaceRat
DAfür die erklärung der a-record und aaaa-record.

Darauf wollte ich hinaus, das der befhel unter ubuntu auch geht

Jetzt stellt sich mir nur noch die frage, wie vom server, zu mir nach hause komme, wo ich die dynamische ipv6 habe.

[SpaceRat]

Jetzt stellt sich mir nur noch die frage, wie vom server, zu mir nach hause komme, wo ich die dynamische ipv6 habe.

Das habe ich doch oben implizit mit erwähnt.

Für einen https-Server auf ipv6.oserver.conan.dyndns.de würdest Du z.B. auf Deinem Root-Server (Wenn da nicht auch ein https-Server läuft) eingeben:

Code: Alles auswählen

6tunnel 443 ipv6.oserver.conan.dyndns.de 443

Dem DynDNS-Host ipv4.oserver.conan.dyndns.de weist Du dauerhaft die IPv4 Deines Root-Servers zu, dem A-Record für oserver.conan.dyndns.de ebenfalls.
Die DynDNS-Hosts ipv6.oserver.conan.dyndns.de und den AAAA-Record für oserver.conan.dyndns.de aktualisierst Du vom eigentlichen Server aus mit der jeweils aktuellen IPv6.

Folge:
Zugriffe per IPv4 gehen auf Deinen Root-Server von wo sie mittels 6tunnel per IPv6 an Deinen Server zuhause 'proxied' werden.
Zugriffe per IPv6 hingegen gehen direkt auf Deinen Server zuhause.

[Conan179]

ich glaube ich vrestehe was falsch.

ich hab momentan im kopf das alle drei
*.oserver.conan.dyndns.de
addresse auf meinen server zeigen.

ich sag mal zuhause hab ich momentan
oserver.zuhause.dyndns.de
also
ipv4.oserver.conan.dyndns.de
bekommt nur die ipv4 des servers.
und der server legt den ipv4 port per 6tunnel auf den ipv6 port vom
oserver.zuhause.dyndns.de

endschuldigung, das ich dich damit so nerve

[Conan179]

wen ich den port per 6tunnel weite gebe, horcht der server auf dem port nur noch auf die ipv6 oder auch wen ich per ipv4 drauf zugreife?

[SpaceRat]

ich hab momentan im kopf das alle drei
*.oserver.conan.dyndns.de
addresse auf meinen server zeigen.

Tun sie ja auch ... für IPv4 halt indirekt.

ich sag mal zuhause hab ich momentan
oserver.zuhause.dyndns.de
also
ipv4.oserver.conan.dyndns.de
bekommt nur die ipv4 des servers.

Richtig.
Eine andere (öffentlich erreichbare) IPv4 hast Du ja nicht ...

und der server legt den ipv4 port per 6tunnel auf den ipv6 port vom
oserver.zuhause.dyndns.de

Genau.

wen ich den port per 6tunnel weite gebe, horcht der server auf dem port nur noch auf die ipv6 oder auch wen ich per ipv4 drauf zugreife?

???
Dein Server zuhause lauscht auf was auch immer Du ihn einrichtest. Nur kommt ja von außen nix per IPv4 bei ihm an.
Dein Server im Netz/vServer lauscht per IPv4 und leitet per IPv6 an den Server zuhause weiter.

[Conan179]

mit "dem server", meine ich nicht, zuhause der dslite anschluss sondern, der root server, wo den 6tunnel aufbaut.

[SpaceRat]

mit "dem server", meine ich nicht, zuhause der dslite anschluss sondern, der root server, wo den 6tunnel aufbaut.

Ich habe "Server zuhause" und Root-Server/vServer in meinen Erklärungen jeweils eindeutig benannt, da mir die Verwechselbarkeit schon bewußt ist.

[Conan179]

das glaub ich dir, aber irgendwo habe ich noch einen knoten im gehirn.

diese 3 addressen
ipv4.oserver.conan.dyndns.de (ipv4 des root servers)
ipv6.oserver.conan.dyndns.de (ipv6 des root servers)
oserver.conan.dyndns.de (ipc4&ipv6 des root servers)

gehen auf den root server.
die fritzbox zuhause hat:
ofritzbox.conan.dyndns.de

hab ich an dieser stelle einen denkfehler?

[SpaceRat]

das glaub ich dir, aber irgendwo habe ich noch einen knoten im gehirn.

Alle A-Records zeigen auf den vServer (bzw. feste-ip.net), da der Server zuhause keine eigene öffentliche IPv4 hat.
Alle AAAA-Records zeigen direkt auf den Server zuhause, da er per IPv6 erreichbar ist, ist ein Umweg für IPv6-Zugriffe unnötig.

[Conan179]

achso, jetzt verstehe ich das, endschuldigung.

jetzt kümmere ich mich um den openvpn server, der auf meinem raspberry ist, wen das nicht geht muss meine 7390 herhalten.

[Rooby]

So ich habe mal experimentiert und versucht zwei router hintereinander zu schalten.
So als ob ein TC7200 im router mode läuft und dahinter mein Asus Router auch im routing mode um die IPV6 firewall zu nutzen (d.h mit WAN port am Router1 LAN port angeschlossen).
Der Router1 ist mit ppoe angebunden und bekommt auch eine IPV6, auch die clients werden mit IPV6 Adressen versorgt, das prefix advertisement scheint zu funktionieren.
So weit so gut. Ich habe Router2 den WAN port auf dynamic IP gestellt. Er bekommt auch von Router1 eine IPV6 aber er macht nicht das advertisement bzw gibt den prefix zu seinen clients nicht weiter.
D.h. es gibt keine IPV6 an den clients von Router2. Gibts da eine Lösung für? Beide router sind mit Asus merlin SW.
Gibt es eventuell was, was ich in der shell aktivieren bzw konfigurieren könnte.
Ich möchte den Router2 nich als AP laufen lassen um den Router1 oder TC7220 bzw evw3226 zu isolieren.

[SpaceRat]

So weit so gut. Ich habe Router2 den WAN port auf dynamic IP gestellt. Er bekommt auch von Router1 eine IPV6 aber er macht nicht das advertisement bzw gibt den prefix zu seinen clients nicht weiter.

Moment ...

Wie ist der Aufbau?

TC7200 -> Asus 1 -> Asus 2
oder
TC7200 -> Asus 1
plus
TC7200 -> Asus 2
?

Bei ersterem muß auch der Asus 1 wiederum Präfixe delegieren.
Schau doch mal, ob Du in der Merlin-Firmware was dazu findest: DHCPv6 Prefix Delegation oder auch kurz PD.

[Rooby]

Hi

das zukünftige setup

TC7200 -> Router2

wollte ich damit mal vorab testen

Modem/PPOE -> Router1 -> Router2

D.h. Router1 deligiert aktive die prefixe?
Ich hatte gedacht dass Router2 ein WAN IPV6 bekommt und selber das prefix an seine clients weitergibt und sonst auch alles über diese IPV6 routet.
Folgen IPV6 settings im Router1 habe ich eingestellt:

DHCP-PD: enabled
Enable Router Advertisement: activated
Enable DHCPv6 Server: enabled
Connect to DNS Server automatically: enabled

Then WAN port von Router2 habe ich als dynamic IP gesetzt anstatt auf PPPOE wie Router1, ist ja kein modem dran.

[SpaceRat]

D.h. Router1 deligiert aktive die prefixe?

Ja.
Sofern er welche übrig hat.

Ich hatte gedacht dass Router2 ein WAN IPV6 bekommt und selber das prefix an seine clients weitergibt und sonst auch alles über diese IPV6 routet.

Nein.
Er bezieht per DHCPv6 oder SLAAC eine eigene WAN-IPv6 und fordert ein Präfix an.
Der vorgeschaltete Router delegiert ihm dann dieses Präfix, sofern er es kann (Er muß dafür PD an sich beherrschen und noch mindestens ein /64 übrig haben, um es dem nachgeschalteten Router zu überlassen).

Folgen IPV6 settings im Router1 habe ich eingestellt:
DHCP-PD: enabled
Enable Router Advertisement: activated
Enable DHCPv6 Server: enabled
Connect to DNS Server automatically: enabled

Das sieht soweit korrekt aus.
Er muß nun natürlich auch selber ein größeres Präfix als /64 (Also einen kleineren Zahlenwert hinter dem /) haben, um mindestens ein /64 abtreten zu können.

Wenn Du bisher schon natives IPv6 hast, dann solltest Du auch mindestens ein /58 vom Provider bekommen, das reicht sogar noch locker aus, um dem nachgeschalteten Router ein /62 zu delegieren, damit der es dann in /64er aufteilen kann (z.B. für Haupt-LAN und Gastnetz).
Bei einer Tunnelanbindung kriegst Du hingegen standardmäßig erst einmal nur ein /64, also nicht genug für PD.
Hurricane Electric/Tunnelbroker gibt Dir aber auf Knopfdruck ein gigantisches /48, bei SixXS mußt Du es für 15 ISKs/Credits beantragen.

[Rooby]

Ok schon mal danke wieder was gelernt...

Also im Router1 steht unter system log-IPV6 bei der
WAN IPv6 Address /64 hinten
LAN IPV6 Address /56 hinten.

Im Router2 steht unter system log-IPV6 bei der
WAN IPv6 Address /64 hinten
LAN IPV6 Address steht nur /0

D.h. da sollte der Router2 der ja am LAN /56 des Routers1 hängt doch ein /64 prefix bekommen können?
Er bekommt wohl nur ein IPV6 Adresse und sonst nix. Vielleicht geht das so nicht mit dem Routern.
Wie ist das eigentlich mit dem TC7220 bzw dem EVW3226 können die den Prefix delegieren?

Mir ist noch aufgefallen, dass die WAN IPV6 und die LAN IPV6 nur die ersten beiden Blöcke gleich sind und der dritte nur teilweise.
D.h. deren prefixes sind nicht mal in den ersten 48bit gleich, ich vermute 40bit. Ist das normal?
Ich hätte jetzt gedacht, dass vielleicht die ersten 56 oder 48 bit gleich sind.

[SpaceRat]

Also im Router1 steht unter system log-IPV6 bei der
WAN IPv6 Address /64 hinten
LAN IPV6 Address /56 hinten.

Im Router2 steht unter system log-IPV6 bei der
WAN IPv6 Address /64 hinten
LAN IPV6 Address steht nur /0

Entweder delegiert Router 1 kein Präfix an Router 2
oder
Router 2 fordert erst gar keines bei Router 1 an
oder
beides.

D.h. da sollte der Router2 der ja am LAN /56 des Routers1 hängt doch ein /64 prefix bekommen können?

Ja. Minimum.

Es gibt bei IPv6 keinen Grund zum Knausern:
Router 2 sollte ein /62 bei Router 1 anfordern und Router 1 sollte dieses Router 2 dann auch gewähren.
Damit hätte Router 2 vier /64er Subnetze zur Verfügung, z.B. eines für LAN, eines für's Gastnetz und zwei in Reserve.

Wie ist das eigentlich mit dem TC7220 bzw dem EVW3226 können die den Prefix delegieren?

Ich habe schon einen TC7200 ein Präfix an einen OpenWrt-Router delegieren sehen, also ja.

Mir ist noch aufgefallen, dass die WAN IPV6 und die LAN IPV6 nur die ersten beiden Blöcke gleich sind und der dritte nur teilweise.
D.h. deren prefixes sind nicht mal in den ersten 48bit gleich, ich vermute 40bit. Ist das normal?
Ich hätte jetzt gedacht, dass vielleicht die ersten 56 oder 48 bit gleich sind.

Es gibt mehrere Varianten des Adressbezugs auch für den Router:
SLAAC, DHCPv6 und Ableitung aus dem ersten Subnet des gelernten Präfixes.

Wenn der Provider-Router ein Subnet advertised, dann bildet der Kundenrouter darin seine eigene WAN-IPv6 mittels SLAAC selbständig (SLAAC = Stateless Address Auto-Configuration, also zustandslose Adress-Auto-Konfiguration).
Zu erkennen ist das daran, daß die WAN-IPv6 mit der aus der MAC des Routers gebildeten modifizierten EUI-64 endet.
Dieser Adressbezug ist identisch zu dem von Clients im eigenen LAN, sofern dort SLAAC benutzt wird, was die Regel ist.
Das dabei verwendete Subnet ist logischerweise nicht Bestandteil des Präfixes welches der Provider-Router zusätzlich an den Kunden-Router delegiert, denn es ist ja schon in Benutzung.

DHCPv6 funktioniert annähernd genauso, nur daß der Kunden-Router die Adresse per DHCPv6 (also stateful) erhält.
Häufig endet die WAN-IPv6 des Kunden-Routers dabei auf ::2 und der Provider-Router agiert als ::1 im selben Subnet als Gateway.
Meines Wissens erfolgt die Adressvergabe auch bei Unitymedia so.
Auch hier gilt wieder: Das Subnet innerhalb dessen die DHCPv6-Adressvergabe erfolgt kann nicht gleichzeitig auch an den Kunden-Router delegiert werden.

Erhält der Router vom Provider weder ein advertisement noch eine IPv6 per DHCPv6 zugewiesen, wohl aber ein Präfix delegiert, dann konfiguriert er sich selbständig auf eine IPv6 innerhalb des ersten /64er Subnets des delegierten Präfixes.
Er wird dann i.d.R. für's LAN erst das zweite /64er Subnet verwenden.
Vermutlich ist das der Grund, wieso die Fritz!Boxen ein /62er anfordern: 1. Subnet für die WAN-IPv6 falls nötig, 2. Subnet für's LAN, 3. Subnet für's Gast-Netz.

Eigentlich müßtest Du alle drei Möglichkeiten mit Deinen zwei Routern nachstellen können, indem Du im ersten Router die Adressvergabe per DHCPv6 und/oder SLAAC ausstellst, aber PD aktiv läßt.

[Rooby]

ok danke für die ausführliche Beschreibung.
In meinem Fall denke ich Router 1 deligiert kein Präfix an Router 2.
Sonst würde ja Router 2 (mit WAN gesetzt auf automatic IP) generell mit IPV6 gar nicht funktionieren.
Ich habe mich mal mit dem Router config auseinander gesetzt und Merlin biete ja prima Möglichkeiten .conf files zu ersetzen oder zu ergänzen.
Ich vermute mal dass der Dienst dnsmasq für da RA zuständig ist.
Hier ist ein Auszug des dnsmasq.conf file von Router1:

...
ra-param=br0,10,600
enable-ra
quiet-ra
dhcp-range=lan,::,constructor:br0,ra-stateless,64,600
dhcp-option=lan,option6:23,[::]
dhcp-option=lan,option6:24,Absturz
dhcp-lease-max=253
dhcp-authoritative
read-ethers
addn-hosts=/etc/hosts.dnsmasq
interface=tun21

Ich vermute in der Zeile
dhcp-range=lan,::,constructor:br0,ra-stateless,64,600
heist die 64 das es nur /64 prefixe an die clients gibt .

[SpaceRat]

dnsmasq macht gar keine Prefix Delegation.
Als DHCPv6-Server muß also dhcpd o.ä. verwendet werden.

[Conan179]

@SpaceRat ich hab da noch eine frage zu "6tunnel" gibt es ein befehl wo mir anzeigt, welche 6tunnel momentan gibt und wie ich die den löschen kann?

[SpaceRat]

@SpaceRat ich hab da noch eine frage zu "6tunnel" gibt es ein befehl wo mir anzeigt, welche 6tunnel momentan gibt und wie ich die den löschen kann?

Nicht wirklich.

Du kannst so gesehen nur mittels

Code: Alles auswählen

ps | grep 6tunnel

bzw. ggf.

Code: Alles auswählen

ps -Af | grep 6tunnel

alle laufenden 6tunnel anzeigen lassen und hoffen, daß Du genug von den Start-Parametern siehst, um den richtigen Prozess zu erkennen.

Den kannst Du dann mit

Code: Alles auswählen

kill <soeben ermittelte PID>

abschießen.

Wenn Du das regelmäßiger machst, dann wäre es ggf. sinnvoll, die PID bereits beim Start zu erfassen.

Hier mal ein Beispiel für zwei 6tunnel-Instanzen:

Code: Alles auswählen

6tunnel 80 ipv6.meinserver.dyndns.org 80
echo $! >/var/run/4to6-http.pid
6tunnel 443 ipv6.meinserver.dyndns.org 443
echo $! >/var/run/4to6-https.pid

Dann könntest Du mit

Code: Alles auswählen

kill $(cat /var/run/4to6-http.pid)

gezielt den 6tunnel abschießen, der für den http-Port 80 gestartet wurde ...

Man kann das mit Sicherheit auch eleganter scripten, aber andererseits macht man das alles in der Regel sowieso nur ein einziges Mal.