• chevron_right

      Monkey Island creator Ron Gilbert “wasn’t even told” about Sea of Thieves DLC

      news.movim.eu / ArsTechnica · Tuesday, 13 June, 2023 - 16:35

    A 3D-animated Guybrush brandishing a sword with his pants down

    Enlarge / Guybrush Threepwood's enthusiasm to meet some character archetypes from Sea of Thieves does not seemingly match that of his creator. (credit: Rare/LucasFilm Games)

    If Microsoft's Rare studio and Disney's Lucasfilm Games (formerly LucasArts) want to make a Monkey Island crossover DLC for Sea of Thieves , they do not, in fact, have to ask the original game's creator, Ron Gilbert.

    In a Mastodon thread responding to a fan's question on Sunday, Gilbert wrote that, "nope," he wasn't involved with Sea of Thieves: The Legend of Monkey Island , an expansion to Rare Limited's multiplayer open-world pirate game themed around the iconic Monkey Island point-and-click adventure series. "Wasn't even told about it. Happened behind my back."

    Terrible Toybox, the firm with which Gilbert has recently worked to release games like Thimbleweed Park and Return to Monkey Island , attempted to clarify Gilbert's statement on Monday, telling Eurogamer that Disney "did give [Gilbert] a heads-up on the project as a courtesy, but the game was well into development at that point, and he wasn't given the opportunity to be meaningfully involved."

    Read 4 remaining paragraphs | Comments

    • chevron_right

      As COVID vaccine patent dispute drags on, Moderna forks over $400M to NIH

      news.movim.eu / ArsTechnica · Friday, 24 February, 2023 - 22:40 · 1 minute

    Image of a syringe in front of a Moderna company logo.

    Enlarge (credit: DeFodi Images )

    Vaccine maker Moderna has forked over $400 million to the National Institutes of Health for using a molecular stabilizing technique borrowed from government and academic researchers in its mRNA-based COVID-19 vaccine—which the company made roughly $36 billion selling amid the deadly pandemic, according to The New York Times .

    Moderna mentioned the payment in the company's latest earnings report , which described the sum as a "catch-up payment" negotiated with the NIH in December as part of a new royalty-bearing license agreement. The agreement will also grant the NIH "low single-digit royalties on future COVID-19 vaccine sales." The company expects to make around $5 billion in COVID-19 vaccine sales in 2023.

    The molecular technique at the center of the agreement is designed to stabilize the SARS-CoV-2 spike protein so that it can spur a strong immune response following vaccination. The mRNA-based vaccine delivers genetic code for the spike protein, which is then translated by human cells into protein. Researchers at the NIH's National Institute of Allergy and Infectious Diseases (NIAID)—as well as collaborators at Dartmouth and The Scripps Research Institute in La Jolla, California—came up with a method of tweaking the mRNA code so that, when translated, the spike protein would stay locked in a specific conformation best for generating an immune response. They had developed the technique years before the pandemic, publishing it in a 2017 study involving the spike protein from a SARS-CoV-2 relative, MERS-CoV, aka the Middle East respiratory syndrome coronavirus. Moderna began collaborating with the NIAID on a general design for mRNA-based vaccines in 2016, but none of its scientists were authors of the 2017 paper.

    Read 7 remaining paragraphs | Comments

    • Au chevron_right

      Free-Market Radical Leftism: Czech It Out

      Roderick · ancapism.marevalo.net / Austro-Athenian Empire · Tuesday, 29 June, 2021 - 20:16

    [cross-posted at POT ]

    The next best thing to giving a libertarian talk in Prague is giving a libertarian talk to Prague. Although if Aristotle is right about the locus of causal action being in the recipient rather than the agent, perhaps this counts as a talk in Prague after all.

    • Au chevron_right

      LHOOQ Books / Exrealism!

      Roderick · ancapism.marevalo.net / Austro-Athenian Empire · Sunday, 27 December, 2020 - 00:51

    Continuing the San Diego bookstore series, I chat with Sean Christopher, founder of LHOOQ Books / Exrealism, a unique bookstore with a once and future San Diego location (though currently located in a renovated armory in Astoria, Oregon). This episode in particular should appeal to anyone with an interest in bookstores, art, literature, etc., even if they have no special interest in San Diego (or Astoria).

    By the way, I stripped out the soundtrack from the five-minute video at the end (on renovating the Astoria Armory), in order to avoid a musical copyright claim – but still got hit by a copyright claim for the background music on the 15-second clip at the beginning. So that soundtrack is muted now too.

    • Au chevron_right

      Tuckered Out? Feeling Greene? Get a Spoonerful of de Cleyrification Here!

      Roderick · ancapism.marevalo.net / Austro-Athenian Empire · Saturday, 5 December, 2020 - 18:27

    [cross-posted at POT , RCL , and facebook ]

    Cory Massimino and I are organising a virtual reading group in January-February 2021 on the individualist anarchists of 19th-century America; details in the video. Join us, if you voluntarily choose to do so; the free-for-all is free for all:

    https://upload.movim.eu/files/7b4a27eed4cd52381dd25ae94920402e838b41d3/bgVmundRVWTEcWiIhAXk6Mx4jPa3R8bUGFWRshuG/a3c10bab55b3a3635ff94858b1496be9.jpg
    #Pologne : A Poznan et ailleurs, les travailleurs et travailleuses ne doivent pas payer pour la crise sanitaire du #Covid-19 !

    Des syndicats ont accepté un accord avec la municipalité qui entérine la suppression des augmentations salariales pour cause de #Coronavirus ! Ce n’est pas le cas du #syndicat #anarcho-syndicaliste Inicjatywa Pracownicza (Initiative des travailleurs), qui mène bataille pour que les augmentations prévues soient appliquées.

    http://www.laboursolidarity.org/Pologne-A-Poznan-et-ailleurs-les

    #IP #Internationalisme #syndicalisme #politique #social #lutte #CNT
    • chevron_right

      Contact publication

      CNT 31 · Friday, 17 April, 2020 - 10:06 edit

    https://upload.movim.eu/files/7b4a27eed4cd52381dd25ae94920402e838b41d3/2EokfCphZd1rctabwEXMsUGjdRVkapLytz0ueKFz/logo_red_and_black_coordination.jpg

    Europe : Déclaration de la coordination Rouge et noire à propos du Covid 19

    http://www.cnt-f.org/international/Europe-Declaration-de-la-coordination-Rouge-et-noire-a-propos-du-Covid-19.html

    Nous vivons ces jours-ci de difficiles et étranges moments, suite à la pandémie globale dans laquelle chaque pays sombre à sa manière. Malgré cela, et en prenant en compte de cette situation exceptionnelle, les syndicats de la coordination Rouge et Noire ne peuvent cesser de revendiquer une série de mesures.

    EZE(Grèce), I.P (Pologne), S.A.C (Suède), CGT (Etat Espagnol), S.O (Etat espagnol), U.S.I (Italie), CNT-F (France).

    #CNT #CNT31 #RedAndBlack #SAC #IP #EZE #SAC #CGT #SO #USI #Coronavirus #covid #NosViesPasLeursProfits #AnarchoSyndicalisme #Syndicalisme
    • Ha chevron_right

      Parcs informatiques (Partie 1 : LAN to LAN)

      raspbeguy · pubsub.gugod.fr / hashtagueule · Thursday, 29 October, 2015 - 23:00 · 10 minutes

    Salut à tous, Voici la première partie du tutoriel en temps réel que je vous avais présenté. Ici, on commence à mettre les mains dans le cambouis pour corrompre fertiliser notre machine pour qu'elle puisse router les IP comme une déesse. Schéma global de l'utilisation de notre passerelle Je vous ra...

    Salut à tous,

    Voici la première partie du tutoriel en temps réel que je vous avais présenté. Ici, on commence à mettre les mains dans le cambouis pour corrompre fertiliser notre machine pour qu'elle puisse router les IP comme une déesse.

    Schéma global de l'utilisation de notre passerelle

    Schéma global de l'utilisation de notre passerelle

    Je vous rappelle le problème. Afin que les clés SSH ne se baladent pas dans la nature, nous avons choisi d'utiliser un proxy SSH interne sur lequel se connecteront toutes les personnes qui on besoin de gérer une des machines distantes dont on a la charge. Ces machines distantes sont accessibles pour la plupart via un tunnel VPN. Et un VPN, par définition, est un moyen de créer un réseau (le N de VPN, pour network) privé (P pour private), c'est à dire inaccessible autrement sur les internets, et cela virtuellement (V pour virtual) car un "vrai" réseau se fait d'habitude physiquement, par le pouvoir et la sainte grâce du support physique brut, pur et candide (cuivre, fibre, onde électromagnétique, signaux de fumée, que sais-je encore) sans aucune intervention autre que celle d'équipements de niveau 2 dans le modèle OSI. Oui, le VPN ne sert pas qu'à télécharger illégalement des données de manière anonyme, chose qu'il fait d'ailleurs la plupart du temps très mal s'il n'est pas couplé avec d'autres techniques. Le tunnel VPN va alors se matérialiser sous la forme d'une interface spéciale sur la machine, de la forme tun ou tap, selon le protocole (pour les plus curieux, tap encapsule des frames Ethernet tandis que tun se limite à des frames IP, mais bon, on s'en tape).

    Et comme les réseaux privés ne sont pas sensés être accessible de l'extérieur, les IP de ces réseaux n'obéissent à aucune pression extérieure, tels les joyeux hippies défoncés qui ont agrémenté les années 70. Ces adresses hippies sont généralement de la forme 192.168.X.X, 172.X.X.X, ou encore 10.0.X.X, ce qui fait que ces adresses hippies, même si elles s'affranchissent des ordres extérieurs, on tendance à se ressembler quand même un peu, c'est pourquoi ces  tiennent également un peu du mouvement hipster.

    Hipster :)

    Un exemple d'adresse IP de réseau privé.

    On peut y voir tout ce que l'on veut, en bien ou en mal, mais une chose est sure, cette "hipsteritude" conduit souvent à des conflits lorsqu'il s'agit de s'y retrouver dans notre routage. En effet, imaginons, je veux envoyer un paquet à une certaine machine, je me débrouille donc pour obtenir son IP (disons l'adresse 192.168.0.2) et j'adresse ce paquet à cet IP. Seulement voilà, c'est tordant de rire, mais des IP comme ça, dans le monde, y en a des millions, et parmi mes connexions, comme j'ai pas mal de clients, il y a de fortes chances que ma machine incline là tête en arrière, me pointe du doigt et me raille méchamment. Ou alors il sera envoyé sur le premier chemin correspondant dans sa table de routage, ce qui n'est évidement pas la bonne solution. C'est ce qu'on appelle les conflits LAN to LAN.

    Alors comment s'extirper de cette situation gênante ? La réponse est assez simple (en fait pas du tout) : faisons appel aux NetNS !

    L'idée

    Le raisonnement est le suivant : Puisqu'on ne dispose d'aucun moyen pour différencier nos IP en court-circuitant l'étape de la table de routage, eh bien utilisons plusieurs tables de routage ! C'est le rôle des NetNS (abréviation de network namespaces, ou "espaces de nommage réseau" en français). Créer un NetNS, c'est créer un nouvel ensemble de réglages réseaux, parmi lesquels des interfaces virtuelles et une table de routage toute belle toute neuve.

    On peut donc ainsi cloisonner les différents réseaux virtuels qui peuvent mener des existences indépendantes, et tout ira bien dans le meilleur des mondes, pour peu que l'on exécute chaque processus dans le bon NetNS. Car oui, le beau côté de la chose, c'est que chaque processus est associé à un NetNS, par défaut au NetNS principal, c'est à dire celui qui contient les interfaces physiques.

    En pratique

    Les opérations suivantes s'effectuent en mode super-utilisateur ou avec la commande sudo. Soyez donc prudent, ne faites pas n'importe quoi, ne mangez pas vos enfants, la drogue c'est mal. Voilà.

    On souhaite cloisonner un tunnel VPN. Pour cela on crée un NetNS que l'on nomme vpn0 par exemple. On va donc effectuer la commande :

    ip netns add vpn0

    Ça y est, le NetNS est né ! Bon je vous avoue que tout nu comme ça, il ne va pas servir à grand chose, pour la simple et bonne raison qu'il ne contient encore aucune interface vers le monde extérieur (c'est embêtant quand on gère un réseau).

    On va donc créer une interface de loopbacklo (mandataire pour le bon fonctionnement de certains programmes, même si on ne s'en servira pas nous-même) et une interface main qui communiquera avec l'espace principal qui, je le rappelle, est le seul à contenir les interfaces physiques :

    ip netns exec vpn0 ip link set dev lo up
    ip link add nseth type veth peer netns vpn0 name main

    Explications :

    • La première ligne introduit la sous commande exec : elle permet d'exécuter dans le NetNS dont le nom est fourni en premier argument une commande fournie à la suite. on exécute donc la commande ip link set dev lo up dans le NetNS vpn0.
    • La deuxième ligne crée une paire d'interfaces : une dans l'espace principal (nommée nseth) liée à une autre dans le NetNS nouvellement créé. Il s'agit d'un portail inter-NetNS.

    On va maintenant assigner des adresse IP à ces interfaces. Eh oui, on fait comme si ces espaces étaient des machines séparées, du coup il faut mettre en place un routage IP...

    Il s'agit de créer un petit réseau privé (à deux membres) avec une IP que j'ai choisie bizarre pour être sûr que personne ne l'utilise pour son adressage VPN. En théorie, un /30 suffirait, mais je vois large, et j'ai laissé un simple /24.

    ip netns exec vpn0 ifconfig main 10.42.0.2/24
    ifconfig nseth 10.42.0.1/24

    J'avoue qu'il s'agit là de la partie que je n'aime guère, le fait de créer des réseaux pour des interfaces virtuelles ne m'enchante pas vraiment. Mais je suis sur qu'il y a pire dans la vie, d'ailleurs j'ai déjà fait pire, et je referai sûrement pire (le tutoriel ne fait que commencer)...

    Voilà, maintenant l'espace principal et le nouveau NetNS se connaissent mutuellement. Mais c'est pas fini. Parce que le nouveau NetNS, il ne sais pas qu'il faut passer par l'espace principal pour accéder à internet.

    ip netns exec vpn0 route add default gw 10.42.0.1

    On ne fait qu'ajouter une entrée  à la table de routage du nouveau NetNS pour lui dire "Quand tu ne sais pas ou tu vas, il faut y aller passe par l'espace principal".

    En l'état, toutes les requêtes sortantes provenant du nouveau NetNS arrivent à l'espace principal, mais lui n'en a cure. Il faut alors activer la redirection IP dans l'espace principal :

    sysctl -w net.ipv4.ip\_forward=1

    Et voilà vous pouvez taper sur n'importe quel serveur depuis votre nouveau NetNS !

    Mais mais mais (parce qu'il y a un mais) ce n'est pas fini, et c'est ça, la valeur ajoutée Hashtagueule, car je n'ai trouvé aucune ressource sur le net évoquant le problème suivant : les requètes montent, pour ça, aucun problème. Mais jamais elle ne redescendrons, en tout cas pas en l'état. Vous pouvez vérifier par vous même avec la commande :

    ip netns exec vpn0 ping 8.8.8.8

    Vous n'obtiendrez aucun écho ICMP. Pourquoi donc ?

    Voyez-vous, L'IP-forwarding est bien pratique, mais il ne réfléchit pas plus que ça (et il a bien raison, car en tant normal on lui demande pas de réfléchir). Quand il reçoit un paquet qui ne lui est pas destiné, le serveur regarde dans sa table de routage vers quelle passerelle il enverrait lui-même ce paquet, et il retransmet le paquet intact. J'ai bien dit intact, c'est à dire sans modifier l'adresse source. Et l'adresse source, ben en l’occurrence c'est 10.42.0.2, une adresse bizarre que nous avons nous même attribué, une adresse interne, une adresse hippie, bref, aucune chance de routage retour.

    Ce problème peut vous en rappeler un autre, enfin plus exactement le même problème mais dans un autre contexte. Si vous avez une box internet et plusieurs PC derrière, vous avez pu remarquer que vous n'avez qu'une seule IP publique, celle de votre box, et que vos PC ont chacun une IP interne. C'est exactement notre cas, sauf que nos PC ici sont virtuels (chaque NetNS auxilliaire représente l'équivalent d'un PC au point de vue réseau), et que les PC derrière une box arrivent à faire des ping à qui ça leur chante. Pourquoi ?

    Eh bien, la box utilise un NAT, c'est à dire un bidule qui permet, entre autres, d'altérer des paquets sortant et de bien diriger les paquets entrants. Saux que votre box fait ça toute seule. Vu que nous on a un Linux (ouais, liberté, pouvoir au peuple, et tout et tout) on va devoir faire un NAT dans notre espace principal, qui correspond par analogie à la box. L'outil Linux pour faire un NAT s'appelle iptables, et c'est un outil assez immonde à apprendre à maitriser. Mais ne craignez rien, Hashtagueule est là pour vous tenir la main et vous écouter pleurer la nuit quand personne d'autre ne vous prête attention.

    En fait, iptables est un parre-feu, c'est à dire qu'il va examiner tous les paquets venant de tous les côtés et va décider de leur sort : basiquement, les laisser passer ou les ignorer.

    Pour faire du NATing, déjà, il faut activer le mode masquerade, c'est à dire la réécriture des ports entrants et sortants :

    iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE

    (en admettant que vous vous connectez à internat par l'interface eth0).

    Vous pouvez définir des ensembles de règles (on les appelle des chaînes de règles), et il est recommandé de faire une chaîne spéciale pour vos NetNS, histoire de ne pas flinguer une configuration déjà existante, et dire à la chaîne principale dédiée à la redirection des paquets de prendre en considération cette nouvelle chaîne :

    iptables -N netns
    iptables -A FORWARD -j netns

    Puis vous allez dire à votre NAT d'accepter tous les paquets impliquant l'interface virtuelle vers notre nouveau NetNS :

    iptables -A netns -i nseth -j ACCEPT

    Voilà, vous êtes parés ! Maintenant votre NetNS peut pleinement communiquer avec Internet. Les paquets sortants seront modifiés afin de prendre l'IP publique, et les paquets entrants seront automatiquement restitués au bon NetNS.

    Maintenant, pour ouvrir un VPN sans risquer de troubler votre routage (c'était le but à la base), par exemple avec OpenVPN, et ouvrir une connexion SSH sur un serveur membre de ce VPN, vous n'avez qu'à effectuer les commandes :

    ip netns exec vpn0 openvpn fichier\_de\_conf.ovpn
    ip netns exec vpn0 ssh mon\_serveur\_distant

    Astuce : pour ne pas être obligé de retaper ip netns exec vpn0 à chaque commande, vous pouvez lancer un nouveau shell dans le NetNS et bénéficier ainsi de l'hérédité de l'environnement de travail :

    ip netns exec vpn0 bash

    Récapitulatif du finctionnement interne

    Récapitulatif du fonctionnement interne

    Voilà, c'est pas beau tout ça ?

    Eh bien non, ce n'est pas beau. Il y a plusieurs grands problèmes :

    • Il est nécessaire de passer en super-utilisateur pour passer des commandes dans les NetNS qui nous intéresse et pour lancer des tunnels VPN.
    • On ne veut pas être obligé de se rappeler d'utiliser tel ou tel protocole pour ouvrir un VPN. Il faut standardiser tout ça.

    Nous verrons la solution de la standardisation des accès VPN dans la partie 2.

    Restez connectés, à la prochaine.

    • At chevron_right

      Parcs informatiques (Partie 1 : LAN to LAN)

      raspbeguy · pubsub.gugod.fr / atomtest · Thursday, 29 October, 2015 - 23:00 · 10 minutes

    Salut à tous, Voici la première partie du tutoriel en temps réel que je vous avais présenté. Ici, on commence à mettre les mains dans le cambouis pour corrompre fertiliser notre machine pour qu'elle puisse router les IP comme une déesse. Schéma global de l'utilisation de notre passerelle Je vous ra...

    Salut à tous,

    Voici la première partie du tutoriel en temps réel que je vous avais présenté. Ici, on commence à mettre les mains dans le cambouis pour corrompre fertiliser notre machine pour qu'elle puisse router les IP comme une déesse.

    Schéma global de l'utilisation de notre passerelle

    Schéma global de l'utilisation de notre passerelle

    Je vous rappelle le problème. Afin que les clés SSH ne se baladent pas dans la nature, nous avons choisi d'utiliser un proxy SSH interne sur lequel se connecteront toutes les personnes qui on besoin de gérer une des machines distantes dont on a la charge. Ces machines distantes sont accessibles pour la plupart via un tunnel VPN. Et un VPN, par définition, est un moyen de créer un réseau (le N de VPN, pour network) privé (P pour private), c'est à dire inaccessible autrement sur les internets, et cela virtuellement (V pour virtual) car un "vrai" réseau se fait d'habitude physiquement, par le pouvoir et la sainte grâce du support physique brut, pur et candide (cuivre, fibre, onde électromagnétique, signaux de fumée, que sais-je encore) sans aucune intervention autre que celle d'équipements de niveau 2 dans le modèle OSI. Oui, le VPN ne sert pas qu'à télécharger illégalement des données de manière anonyme, chose qu'il fait d'ailleurs la plupart du temps très mal s'il n'est pas couplé avec d'autres techniques. Le tunnel VPN va alors se matérialiser sous la forme d'une interface spéciale sur la machine, de la forme tun ou tap, selon le protocole (pour les plus curieux, tap encapsule des frames Ethernet tandis que tun se limite à des frames IP, mais bon, on s'en tape).

    Et comme les réseaux privés ne sont pas sensés être accessible de l'extérieur, les IP de ces réseaux n'obéissent à aucune pression extérieure, tels les joyeux hippies défoncés qui ont agrémenté les années 70. Ces adresses hippies sont généralement de la forme 192.168.X.X, 172.X.X.X, ou encore 10.0.X.X, ce qui fait que ces adresses hippies, même si elles s'affranchissent des ordres extérieurs, on tendance à se ressembler quand même un peu, c'est pourquoi ces  tiennent également un peu du mouvement hipster.

    Hipster :)

    Un exemple d'adresse IP de réseau privé.

    On peut y voir tout ce que l'on veut, en bien ou en mal, mais une chose est sure, cette "hipsteritude" conduit souvent à des conflits lorsqu'il s'agit de s'y retrouver dans notre routage. En effet, imaginons, je veux envoyer un paquet à une certaine machine, je me débrouille donc pour obtenir son IP (disons l'adresse 192.168.0.2) et j'adresse ce paquet à cet IP. Seulement voilà, c'est tordant de rire, mais des IP comme ça, dans le monde, y en a des millions, et parmi mes connexions, comme j'ai pas mal de clients, il y a de fortes chances que ma machine incline là tête en arrière, me pointe du doigt et me raille méchamment. Ou alors il sera envoyé sur le premier chemin correspondant dans sa table de routage, ce qui n'est évidement pas la bonne solution. C'est ce qu'on appelle les conflits LAN to LAN.

    Alors comment s'extirper de cette situation gênante ? La réponse est assez simple (en fait pas du tout) : faisons appel aux NetNS !

    L'idée

    Le raisonnement est le suivant : Puisqu'on ne dispose d'aucun moyen pour différencier nos IP en court-circuitant l'étape de la table de routage, eh bien utilisons plusieurs tables de routage ! C'est le rôle des NetNS (abréviation de network namespaces, ou "espaces de nommage réseau" en français). Créer un NetNS, c'est créer un nouvel ensemble de réglages réseaux, parmi lesquels des interfaces virtuelles et une table de routage toute belle toute neuve.

    On peut donc ainsi cloisonner les différents réseaux virtuels qui peuvent mener des existences indépendantes, et tout ira bien dans le meilleur des mondes, pour peu que l'on exécute chaque processus dans le bon NetNS. Car oui, le beau côté de la chose, c'est que chaque processus est associé à un NetNS, par défaut au NetNS principal, c'est à dire celui qui contient les interfaces physiques.

    En pratique

    Les opérations suivantes s'effectuent en mode super-utilisateur ou avec la commande sudo. Soyez donc prudent, ne faites pas n'importe quoi, ne mangez pas vos enfants, la drogue c'est mal. Voilà.

    On souhaite cloisonner un tunnel VPN. Pour cela on crée un NetNS que l'on nomme vpn0 par exemple. On va donc effectuer la commande :

    ip netns add vpn0

    Ça y est, le NetNS est né ! Bon je vous avoue que tout nu comme ça, il ne va pas servir à grand chose, pour la simple et bonne raison qu'il ne contient encore aucune interface vers le monde extérieur (c'est embêtant quand on gère un réseau).

    On va donc créer une interface de loopbacklo (mandataire pour le bon fonctionnement de certains programmes, même si on ne s'en servira pas nous-même) et une interface main qui communiquera avec l'espace principal qui, je le rappelle, est le seul à contenir les interfaces physiques :

    ip netns exec vpn0 ip link set dev lo up
    ip link add nseth type veth peer netns vpn0 name main

    Explications :

    • La première ligne introduit la sous commande exec : elle permet d'exécuter dans le NetNS dont le nom est fourni en premier argument une commande fournie à la suite. on exécute donc la commande ip link set dev lo up dans le NetNS vpn0.
    • La deuxième ligne crée une paire d'interfaces : une dans l'espace principal (nommée nseth) liée à une autre dans le NetNS nouvellement créé. Il s'agit d'un portail inter-NetNS.

    On va maintenant assigner des adresse IP à ces interfaces. Eh oui, on fait comme si ces espaces étaient des machines séparées, du coup il faut mettre en place un routage IP...

    Il s'agit de créer un petit réseau privé (à deux membres) avec une IP que j'ai choisie bizarre pour être sûr que personne ne l'utilise pour son adressage VPN. En théorie, un /30 suffirait, mais je vois large, et j'ai laissé un simple /24.

    ip netns exec vpn0 ifconfig main 10.42.0.2/24
    ifconfig nseth 10.42.0.1/24

    J'avoue qu'il s'agit là de la partie que je n'aime guère, le fait de créer des réseaux pour des interfaces virtuelles ne m'enchante pas vraiment. Mais je suis sur qu'il y a pire dans la vie, d'ailleurs j'ai déjà fait pire, et je referai sûrement pire (le tutoriel ne fait que commencer)...

    Voilà, maintenant l'espace principal et le nouveau NetNS se connaissent mutuellement. Mais c'est pas fini. Parce que le nouveau NetNS, il ne sais pas qu'il faut passer par l'espace principal pour accéder à internet.

    ip netns exec vpn0 route add default gw 10.42.0.1

    On ne fait qu'ajouter une entrée  à la table de routage du nouveau NetNS pour lui dire "Quand tu ne sais pas ou tu vas, il faut y aller passe par l'espace principal".

    En l'état, toutes les requêtes sortantes provenant du nouveau NetNS arrivent à l'espace principal, mais lui n'en a cure. Il faut alors activer la redirection IP dans l'espace principal :

    sysctl -w net.ipv4.ip\_forward=1

    Et voilà vous pouvez taper sur n'importe quel serveur depuis votre nouveau NetNS !

    Mais mais mais (parce qu'il y a un mais) ce n'est pas fini, et c'est ça, la valeur ajoutée Hashtagueule, car je n'ai trouvé aucune ressource sur le net évoquant le problème suivant : les requètes montent, pour ça, aucun problème. Mais jamais elle ne redescendrons, en tout cas pas en l'état. Vous pouvez vérifier par vous même avec la commande :

    ip netns exec vpn0 ping 8.8.8.8

    Vous n'obtiendrez aucun écho ICMP. Pourquoi donc ?

    Voyez-vous, L'IP-forwarding est bien pratique, mais il ne réfléchit pas plus que ça (et il a bien raison, car en tant normal on lui demande pas de réfléchir). Quand il reçoit un paquet qui ne lui est pas destiné, le serveur regarde dans sa table de routage vers quelle passerelle il enverrait lui-même ce paquet, et il retransmet le paquet intact. J'ai bien dit intact, c'est à dire sans modifier l'adresse source. Et l'adresse source, ben en l’occurrence c'est 10.42.0.2, une adresse bizarre que nous avons nous même attribué, une adresse interne, une adresse hippie, bref, aucune chance de routage retour.

    Ce problème peut vous en rappeler un autre, enfin plus exactement le même problème mais dans un autre contexte. Si vous avez une box internet et plusieurs PC derrière, vous avez pu remarquer que vous n'avez qu'une seule IP publique, celle de votre box, et que vos PC ont chacun une IP interne. C'est exactement notre cas, sauf que nos PC ici sont virtuels (chaque NetNS auxilliaire représente l'équivalent d'un PC au point de vue réseau), et que les PC derrière une box arrivent à faire des ping à qui ça leur chante. Pourquoi ?

    Eh bien, la box utilise un NAT, c'est à dire un bidule qui permet, entre autres, d'altérer des paquets sortant et de bien diriger les paquets entrants. Saux que votre box fait ça toute seule. Vu que nous on a un Linux (ouais, liberté, pouvoir au peuple, et tout et tout) on va devoir faire un NAT dans notre espace principal, qui correspond par analogie à la box. L'outil Linux pour faire un NAT s'appelle iptables, et c'est un outil assez immonde à apprendre à maitriser. Mais ne craignez rien, Hashtagueule est là pour vous tenir la main et vous écouter pleurer la nuit quand personne d'autre ne vous prête attention.

    En fait, iptables est un parre-feu, c'est à dire qu'il va examiner tous les paquets venant de tous les côtés et va décider de leur sort : basiquement, les laisser passer ou les ignorer.

    Pour faire du NATing, déjà, il faut activer le mode masquerade, c'est à dire la réécriture des ports entrants et sortants :

    iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE

    (en admettant que vous vous connectez à internat par l'interface eth0).

    Vous pouvez définir des ensembles de règles (on les appelle des chaînes de règles), et il est recommandé de faire une chaîne spéciale pour vos NetNS, histoire de ne pas flinguer une configuration déjà existante, et dire à la chaîne principale dédiée à la redirection des paquets de prendre en considération cette nouvelle chaîne :

    iptables -N netns
    iptables -A FORWARD -j netns

    Puis vous allez dire à votre NAT d'accepter tous les paquets impliquant l'interface virtuelle vers notre nouveau NetNS :

    iptables -A netns -i nseth -j ACCEPT

    Voilà, vous êtes parés ! Maintenant votre NetNS peut pleinement communiquer avec Internet. Les paquets sortants seront modifiés afin de prendre l'IP publique, et les paquets entrants seront automatiquement restitués au bon NetNS.

    Maintenant, pour ouvrir un VPN sans risquer de troubler votre routage (c'était le but à la base), par exemple avec OpenVPN, et ouvrir une connexion SSH sur un serveur membre de ce VPN, vous n'avez qu'à effectuer les commandes :

    ip netns exec vpn0 openvpn fichier\_de\_conf.ovpn
    ip netns exec vpn0 ssh mon\_serveur\_distant

    Astuce : pour ne pas être obligé de retaper ip netns exec vpn0 à chaque commande, vous pouvez lancer un nouveau shell dans le NetNS et bénéficier ainsi de l'hérédité de l'environnement de travail :

    ip netns exec vpn0 bash

    Récapitulatif du finctionnement interne

    Récapitulatif du fonctionnement interne

    Voilà, c'est pas beau tout ça ?

    Eh bien non, ce n'est pas beau. Il y a plusieurs grands problèmes :

    • Il est nécessaire de passer en super-utilisateur pour passer des commandes dans les NetNS qui nous intéresse et pour lancer des tunnels VPN.
    • On ne veut pas être obligé de se rappeler d'utiliser tel ou tel protocole pour ouvrir un VPN. Il faut standardiser tout ça.

    Nous verrons la solution de la standardisation des accès VPN dans la partie 2.

    Restez connectés, à la prochaine.