RFCE017: The Boring Episode – VPN

Wieder einmal habe ich mit Clemens Schrimpe gesprochen. In der Boring Episode, dem schlechten Wortspiel im Namen, bohren wir Tunnel per Virtual Private Networks.

Nach einem allgemeinen Teil zur Einführung, geht Clemens auch auf einzelne Tunnelvarianten ein. Zum Ende geht es noch um ein paar private Themen mit Bezug zum Podcast. Leider gab es technisch anfänglich ein paar Schwierigkeiten – das Knacksen lässt aber nach.
avatar
Anna-Lena
AnnLe Icon Paypal Icon Flattr Icon Amazon Wishlist Icon
avatar
Clemens Schrimpe
Twitter Icon

Shownotes

Podcast unterstützen:

30 Gedanken zu „RFCE017: The Boring Episode – VPN“

  3. Hi,

    Wie immer eine super Folge. Erst Mal herzlichen Glückwunsch. Der Nachwuchs müsste ja mittlerweile da sein.

    Und jetzt mein Wunsch. Es wäre cool wenn der Podcast Kapitel Marken unterstützen würde. Gerade bei so vielen kleinen Dingen die zwar doch alle zusammen gehören wäre es für das nachhören echt hilfreich nicht alles noch Mal hören zu müssen.

    Grüße,

    Mike

    Antworten ↓

  4. Habe einen Typo Fehler gefunden .. der Link zu tinc-vpn.org ist richtig.. in der Liste steht es aber als Tinc.org…. wenn das einer (wie ich jetzt grade) nur schnell im Browser tippt..wird er fehlgeleitet…

    Antworten ↓

  6. Mein Arbeitgeber, die Hochschule RheinMain, hat sich erst vor kurzem dazu entschlossen, dass doch so ein WebVPN eine tolle Sache ist.
    Auf die Frage WARUM?!? und wie man es auf iOS ohne Java nutzen soll die Antwort: Wir nutzen kein iOS und es ist schon in den Routern implementiert. Mussten es nur einschalten.

    Antworten ↓

  9. Wie immer eine klasse Folge. Ich habe wieder viel gelernt!
    Ich freue mich auf die neue Podcast-Taktung.

    @Anna-Lena
    Beste Wünsche fürs “Private Drumherum” :-)

    Antworten ↓

  10. Top Druckbetankung an guten Infos und interessanten Anekdoten :-) weiter so!

    Ich wünsche mir noch mehr Anekdoten und ISP-Interna. Immer wieder interessant und erleuchtend.

    Antworten ↓

  11. Schön, dass es euch wieder mal zu hören gibt und auch schönes Thema.

    Ihr hatte über mangelnde Hardwareimplementation von Wireguard geredet. Dazu wollte ich anmerken, dass es wohl Designziel von dem Protokoll war, das ohne Hardwareimplementation schnell zu bekommen. Der Handshake ist minimal, weil quasi nichts verhandelt wird und quasi alles hard coded ist und die verwendeten Cipher sind hauptsächlich ChaCha20 und Poly1305, die beide auf modernen CPU ohne dedizierte Hardware deutlich besser performen, als AES und RSA zum Beispiel. Wie das jetzt im Detail auf Plasteroutern funktioniert habe ich aber nicht getestet.

    Noch was zu Tor als VPN: Meine Firma hat ein paar Kisten in der Welt verteilt bei Kunden mit hohem Admin-Nazi-Koeffizienten. Wir packen dann immer noch nen TOR-Hidden-Service als Notlösung für SSH dazu. Bisher ist uns noch keine Firewall unter gekommen, die schlau genug war, das von normalen HTTPS Traffic zu unterscheiden.

    Antworten ↓

  12. @Clemens: ich hab mal die Freakshow (bzw. damals noch Mobile Macs-Folge) rausgesucht, in der du die Layer2-SSH-Tunnel erwähnt hast, dein Dropbox-Link aus den Kommentaren wirft leider einen 404: https://freakshow.fm/mm103-plattform-mit-migrationshintergrund#comment-80629

    Könntest du die Anleitung nochmal veröffentlichen?

    Ich hätte noch eine Frage zu IPSec:

    Theoretisch müsste es mit dem Transportmodus doch möglich sein, sich die ganze Routing-Probleme zu sparen, und IPSec quasi als „Schlüssel“ für die Firewall zu benutzen. Da ja alle Geräte hinter der Firewall heutzutage global gültige IP-Adressen haben sollten gibt es ja keine Adressierungsprobleme mehr, sondern alleine Authentifizierung und evt. Verschlüsselung sind nötig, wenn man bspw. auf Geräte hinter der Firewall zugreifen möchte.

    Die Idee wäre, dass der Absender oder der Router im anderen site-to-site-Netzwerk einfach alle Pakete an das Netzwerk per IPSec-Transport-Mode verpackt und der Router des Zielnetzwerkes die Pakete authentifiziert, auspackt und durch die Firewall lässt. Gibt es da funktionierende Lösungen für?

    Gerade das Routing bot mir gefühlt bisher immer die größten Fallstricke beim Tunnel buddeln. Auch aus dem Grund, dass ich gerne die Geräte innerhalb des Netzwerkes mit den gleichen IP-Adressen (bzw. DNS-Namen, ich bin dazu übergegangen einfach die globalen SLAAC-Adressen ins DNS zu hämmern) ansprechen würde, und dann plötzlich innen und außen des Tunnels die gleichen IP-Netze benutze.

    Ich hoffe, ich habe meine Idee und mein Problem verständlich machen können.^^

    Antworten ↓

  13. Erstmal danke, dass ihr zwei weitermacht und herzlichen Glückwunsch.

    Nochwas zu Wireguard, da die Doku immer nur auf “dann kloppst du da ne 10.0.0.foo – Adresse in die config” eingeht (ich krig ja immer die Kriese, wenn ich sowas sehe):

    Radvd (SLAAC-daemon unter Linux) kann seine RA-Pakete auch an ff02::1 addressieren. WG hat (trotz L3 only) mit IP-multicast keine Probleme. Damit muss nur noch ne link-local Adresse in die WG-config und der Rest läuft schön dynamisch.
    (Und wer noch jammert, dass da kein DHCPv4 geht…. Mir doch egal, bin Admin und kein IT-Historiker ;) ).

    Antworten ↓

    • ..und OSPF läuft über WG auch ohne Probleme. Für das Routen von Fremdadressen aber nicht vergessen, 0.0.0.0/0 als allowed-ips einzugeben..

      Antworten ↓

  14. Herrlich! Anfang der Woche mit einem Kollegen noch ein Problem gelöst, welches früher hier im Podcast angesprochen wurde. Wir haben dann noch kurz darüber gesprochen, dass es leider schon lange keine neue Folge gegeben hat – und dann kommt doch grad eine raus!
    Und das schönste: unser Problem waren kaputte Pakete über WAN wegen reduzierer MTU und blockiertem ICMP!

    Antworten ↓

  16. @Clemens: bei WIA-Gate L3-BSA Varainten ist das aktuell noch L2TP Standard… PPP über Internet Getunnelt. Nur bei den neuen L2BSA Produkten übergibt die DTAG die APs direkt über Ethernet Dot1Q S-Tags, dann aber auf 990 Übergabepunkten in DE und nicht zentral im Internet.

    Antworten ↓

  17. Super, Klasse dass die neue Episode draußen ist!
    Ich hatte schon fast die Hoffnung aufgegeben! :-D

    Ein Tip zu Wireguard:
    Wireguard für die EdgeRouter gibt es als fertige Pakete unter
    https://github.com/Lochnair/vyatta-wireguard/releases
    für alle gängigen Bauformen, vom EdgeRouter X bis hin zum EdgeRouter Infinity. Sie werden immer an die aktuellen Releases angepasst und mittlerweile auch auch auf der Homepage von Wireguard aufgeführt!
    Das Paket ist schön in das EdgeOS integriert und erweitert die Konfigurationssprache entsprechend.

    Antworten ↓

  18. Schön das dieser podcast fortgesetzt wird :) bis jetzt nichts besseres gefunden um sich mit all den Themen tiefer zu befassen und vieles zu lernen :) gerade wegen den kleinen story’s und lustigen Geschichten :)

    Antworten ↓

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert