/usr/share/doc/HOWTO/fr-html/VPN-HOWTO.html is in doc-linux-fr-html 2013.01-2.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for Linux/x86 (vers 25 March 2009), see www.w3.org">
<meta name="GENERATOR" content="LinuxDoc-Tools 0.9.69">
<title>VPN HOWTO</title>
</head>
<body>
<h1>VPN HOWTO</h1>
<h2>Matthew D. Wilson, <a href=
"mailto:matthew@shinythings.com">matthew@shinythings.com</a>
Traduction française de Nicolas Prigent <a href=
"mailto:prigentn@thmulti.com">prigentn@thmulti.com</a></h2>
v 1.0, Dec 1999
<hr>
<em>Ce HOWTO décrit la manière de mettre en place un
Réseau Privé Virtuel (Virtual Private Network) avec
Linux.</em>
<hr>
<h2><a name="Introduction"></a> <a name="s1">1.
Introduction</a></h2>
<h2><a name="ss1.1">1.1 Pourquoi ai-je écrit ce
HOWTO</a></h2>
<p>Je travaille chez Real Network, et nous avions besoin d'un VPN.
C'était mon premier véritable projet, et j'en ai
réellement appris plus au sujet de Linux grâce
à cela qu'avec n'importe quelle autre tâche. Je me
suis servi de l'expérience ainsi acquise pour rédiger
ce document, pour partager avec d'autres ce que j'avais appris,
pour qu'ils puissent eux aussi réaliser de super trucs avec
Linux.</p>
<h2><a name="ss1.2">1.2 Remerciements</a></h2>
<p>Je voudrais tout d'abord et surtout remercier mon épouse
Julie, sans qui je ne serais pas où j'en suis actuellement.
Je voudrais aussi remercier Arpad Magosanyi, l'auteur du premier
VPN mini-howto et de pty-redir, l'utilitaire qui a rendu tout cela
possible. Jerry, Rod, Glen, Mark V., Mark W., et David, vous
êtes trop fort les mecs. Merci pour votre aide.</p>
<h2><a name="ss1.3">1.3 Format de ce document</a></h2>
<p>Ce document est divisé en 5 sections.</p>
<dl>
<dt><b>Section 1: Introduction</b></dt>
<dd>
<p>Cette section</p>
</dd>
<dt><b>Section 2: Théorie</b></dt>
<dd>
<p>La théorie à la base des VPNs. Qu'est-ce qu'un
VPN, et comment fonctionne-t-il. Lisez cette partie si vous
êtes néophyte en matière de VPN.</p>
</dd>
<dt><b>Section 3: Serveur</b></dt>
<dd>
<p>Cette section décrit la mise en place d'un serveur de
VPN.</p>
</dd>
<dt><b>Section 4: Client</b></dt>
<dd>
<p>Cette section décrit la mise en place d'un client de
VPN.</p>
</dd>
<dt><b>Section 5: Implémentation</b></dt>
<dd>
<p>Une implémentation de VPN décrite pas à
pas.</p>
</dd>
<dt><b>Section 6: Addenda</b></dt>
<dd>
<p>D'autres éléments d'information qui pourraient
vous être utiles.</p>
</dd>
</dl>
<h2><a name="ss1.4">1.4 Copyright et Avertissements</a></h2>
<p>Copyright (c) Matthew Wilson. Ce document ne peut être
distribué qu'en accord avec les termes et les conditions de
la licence LDP que vous trouverez a l'adresse <a href=
"http://www.linuxdoc.org/COPYRIGHT.html">http://www.linuxdoc.org/COPYRIGHT.html</a>,
excepté le fait que ce document ne doit pas être
distribué sous une forme altérée sans le
consentement de son auteur.</p>
<p>Ni l'auteur, ni le traducteur n'assument une quelconque
responsabilité pour quoi que ce soit pouvant advenir suite a
l'utilisation de ce document, ni ne fournissent une quelconque
garantie, implicite ou explicite. Si vous cassez quelque chose,
nous ne sommes en rien responsable. Souvenez vous que ce que vous
allez faire ici pourrait créer d'énormes trous de
sécurité sur votre réseau. Vous aurez
été prévenus.</p>
<h2><a name="ss1.5">1.5 Histoire de ce document</a></h2>
<p>Le VPN mini-HOWTO original a été écrit par
<a href="mag@bunuel.tii.matav.hu">Arpad Magosanyi</a> en 1997. Il
m'a depuis autorisé à reprendre le document, et
à l'étendre jusqu'à en faire un HOWTO complet.
Rien de ceci n'aurait été possible sans le document
original. Merci encore Arpad. :)</p>
<p>La version 1.0 de ce HOWTO a été terminée
le 10 décembre 1999.</p>
<h2><a name="ss1.6">1.6 Documents associés</a></h2>
<ul>
<li><a href="/HOWTO/Networking-Overview-HOWTO.html">Networking
Overview HOWTO</a></li>
<li><a href="/HOWTO/NET3-4-HOWTO.html">Networking HOWTO</a></li>
<li><a href="/HOWTO/VPN-Masquerade-HOWTO.html">VPN-Masquerade
HOWTO</a></li>
</ul>
<h2><a name="s2">2. Théorie</a></h2>
<h2><a name="ss2.1">2.1 Qu'est-ce qu'un VPN?</a></h2>
<p>VPN est l'acronyme de Virtual Private Network, ou réseau
privé virtuel. Un VPN utilise l'Internet comme
mécanisme de transport, en maintenant la
sécurité des données sur le VPN.</p>
<h3>Mais c'est quoi, en vrai, un VPN?</h3>
<p>Et bien il y a plusieurs réponses à cette
question. Cela dépends vraiment de l'apparence du
réseau. En général, on dispose d'un
réseau principal unique, avec des noeuds distants qui
utilisent le VPN pour gagner un accès complet au
réseau central. Les noeuds distants sont
généralement des bureaux éloignés, ou
des employés travaillant à partir de chez eux. Il est
aussi possible de relier deux réseaux plus petits (ou
même plus grands!) pour former un seul réseau encore
plus grand.</p>
<h3>Alors, ça marche comment?</h3>
<p>Pour simplifier, pour réaliser un VPN, vous créez
un tunnel sécurisé entre deux réseaux et
l'utilisez pour router les datagrammes IP. Au cas ou vous seriez
déjà perdu, vous devriez lire <a href=
"http://www.linuxdoc.org/HOWTO/Networking-Overview-HOWTO.html">Le
Linux Networking Overview HOWTO</a> pour vous informer au sujet des
réseaux sous Linux.</p>
<p>Prière de ne pas m'en vouloir, mes schémas ASCII
mériterait un peu plus de travail.</p>
<pre>
\ \
--------- / / ---------
Réseau ______| Routeur |______\ Internet \_____| Routeur |______ Réseau
Distant | Client | / / | Serveur | Privé
--------- \ \ ---------
/ /
Routeur Client
----------------------------------------------------
| /-> 10.0.0.0/255.0.0.0 \ |
Réseau | |--> 172.16.0.0/255.240.0.0 |--> Tunnel >---\ |
Distant >---|--|--> 192.168.0.0/255.255.0.0 / |--|----> Internet
192.168.12.0 | | | |
| \-----> 0.0.0.0/0.0.0.0 --> Masquarade IP >--/ |
----------------------------------------------------
Routeur Serveur
----------------------------------------------------
| /-> 10.0.0.0/255.0.0.0 \ |
| /--> Tunnel >--|--> 172.16.0.0/255.240.0.0 |--|----> Réseau
Internet >--|--| \--> 192.168.0.0/255.255.0.0 / | Privé
| | | 172.16.0.0/12
| \-----> 0.0.0.0/0.0.0.0 -----> /dev/null | 192.168.0.0/16
----------------------------------------------------
</pre>
<p>Le diagramme ci-dessus montre comment le réseau peut
être mis en place. Si vous ne savez pas ce qu'est la
masquarade IP, vous ne devriez probablement pas être ici.
Allez lire <a href="/HOWTO/Networking-Overview-HOWTO.html">Le Linux
Networking Overview HOWTO</a> et revenez une fois
informé.</p>
<p>Le routeur client est une machine Linux tenant le rôle de
passerelle/firewall pour le réseau distant. Comme vous
pouvez le voir, le réseau distant utilise le réseau
local 192.168.12.0. Pour plus de simplicité dans le
diagramme, j'ai laissé les informations de routage sur les
routeurs. L'idée de base est de router le trafic
destiné aux réseaux privés (10.0.0.0,
172.16.0.0, et 192.168.0.0) via le tunnel. L'installation
montrée ici est une manière de le faire. C'est
à dire qu'alors que le réseau distant peut voir le
réseau privé, le réseau privé ne peut
pas nécessairement voir le réseau distant. Pour que
ceci arrive, il faut spécifier que les routes sont
bidirectionnelles.</p>
<p>Vous devriez aussi remarquer sur le schéma que tout le
trafic sortant du routeur client apparaît comme en provenant,
c'est à dire qu'il porte toujours la même adresse IP.
Vous pouvez router les valeurs véritables de
l'intérieur de votre réseau, mais cela induit une
grande diversité de problèmes de
sécurité.</p>
<h2><a name="ss2.2">2.2 SSH et PPP</a></h2>
<p>Le système que je décris pour implémenter
un VPN utilise SSH et PPP. Schématiquement, je me sers de
ssh pour créer une connexion protégée par
tunnel, puis utilise pppd pour y démarrer le trafic TCP/IP.
C'est ainsi que le tunnel est mis en place.</p>
<p>Le véritable truc pour faire fonctionner ssh et pppd
ensemble correctement est l'utilitaire écrit par Arpad
Magosanyi qui permet la redirection de l'entrée et de la
sortie standard vers un pseudo tty. Ceci permets à pppd de
parler au travers de ssh comme s'il s'agissait d'une liaison
série. Du côté du serveur, pppd est
lancé comme interpreteur de commande utilisateur dans la
session ssh, complétant le lien. Après cela, tout ce
qu'il reste a faire est de réaliser le routage.</p>
<h2><a name="ss2.3">2.3 Systèmes VPN alternatifs</a></h2>
<p>Il y a bien sur d'autres moyens de mettre en place un VPN, dont
voici quelques exemples.</p>
<h3>PPTP</h3>
<p>PPTP est un protocole Microsoft pour les VPN. Il est
supporté sous Linux, mais est connu pour avoir de nombreux
problèmes de sécurité. Je ne décris pas
ici la manière de l'utiliser, étant donné que
ce thème est couvert par <a href=
"http://www.linuxdoc.org/HOWTO/VPN-Masquerade-HOWTO.html">Linux VPN
Masquerade HOWTO</a>.</p>
<h3>IPSec</h3>
<p>IPSec est un ensemble de protocoles différents de SSH.
Franchement, je n'en connais pas énormément à
son sujet. De fait, si quelqu'un veut m'aider d'une description, je
lui en serais très reconnaissant. Encore une fois, je ne
décris pas comment l'utiliser étant donné que
le <a href=
"http://www.linuxdoc.org/HOWTO/VPN-Masquerade-HOWTO.html">Linux VPN
Masquerade HOWTO</a> couvre le sujet.</p>
<h3>CIPE</h3>
<p>CIPE est un système de chiffrement au niveau noyau
probablement mieux adapté aux dispositifs d'entreprise. Vous
pourrez en savoir plus sur <a href=
"http://sites.inka.de/sites/bigred/devel/cipe.html">la page de
CIPE</a>. J'envisage de m'y intéresser plus
sérieusement, et aurais donc peut être plus
d'informations à son sujet bientôt.</p>
<h2><a name="s3">3. Le serveur</a></h2>
<p>Cette section explique comment mettre en place l'aspect serveur
des choses. J'ai placé cette section en premier,
étant donné que sans serveur, un client est assez
inutile.</p>
<h2><a name="ss3.1">3.1 La sécurité - garder les gens
dehors</a></h2>
<p>La sécurité est un aspect très important
des VPNs. C'est pour ça que vous êtes en train d'en
monter un, non? Vous devez garder ces quelques choses à
l'esprit en mettant en place votre serveur.</p>
<h3>Préparez vos démons</h3>
<p>Etant donné que ce serveur va être des deux
côtés du firewall et qu'il va être mis en place
pour transmettre le trafic sur votre réseau, c'est une bonne
idée de sécuriser la machine autant que possible.
Vous pourrez en apprendre plus sur la sécurité Linux
dans <a href="/HOWTO/Security-HOWTO.html">Linux Security HOWTO</a>.
Pour ma part, j'ai tué tous les services, excepté
sshd et un serveur web Roxen. J'utilise ce dernier pour
télécharger quelques fichiers (mes scripts, etc.)
pour permettre à d'autres machines d'accéder au VPN.
Je n'utilise pas de serveur FTP étant donné qu'il est
plus dur d'en sécuriser un que de rendre quelques fichiers
disponibles sur un serveur web. De plus, j'ai seulement besoin de
pouvoir récupérer des fichiers. Si vous souhaitez
réellement exécuter des serveurs différents
sur votre passerelle, vous pourriez vouloir envisager de
restreindre leur accès aux machines situées sur votre
réseau privé.</p>
<h3>Ne pas autoriser de mots de passe</h3>
<p>Effectivement, cela semble assez stupide, mais ça a
retenu votre attention non? Non, vous n'utilisez pas de mots de
passe, vous les désactivez complètement. Toute
l'authentification nécessaire sur cette machine devrait
être faite via le système d'authentification à
clé publique de ssh. Ainsi, seul les entités
dotées de clés peuvent entrer, et il est pratiquement
impossible de se rappeler d'une clé binaire de 530
caractères.</p>
<p>Alors, comment faites-vous ça? Il faut éditer le
fichier /etc/passwd. Le second champ contient soit le
résumé cryptographique (hash) du mot de passe, ou un
'x' prévenant le système d'authentification qu'il
faut regarder dans le fichier /etc/shadow. Vous devez changer ce
champ en '*'. Ainsi le système d'authentification est
informé qu'il n'y a pas de mot de passe, et qu'aucun ne
devrait être autorisé.</p>
<p><a name="passwd"></a> Voila à quoi ressemble un fichier
/etc/passwd classique:</p>
<pre>
...
nobody:x:65534:100:nobody:/dev/null:
mwilson:x:1000:100:Matthew Wilson,,,:/home/mwilson:/bin/bash
joe:*:504:101:Joe Mode (home),,,:/home/vpn-users:/usr/sbin/pppd
bill:*:504:101:Bill Smith (home),,,:/home/vpn-users:/usr/sbin/pppd
frank:*:504:101:Frank Jones (home),,,:/home/vpn-users:/usr/sbin/pppd
...
</pre>
Remarquez que j'ai fait plus qu'éditer simplement le second
champ. J'en dirais plus sur les autres champs par la suite.
<h2><a name="ss3.2">3.2 Accès des utilisateur - les laisser
rentrer</a></h2>
<p>L'accès des utilisateurs est réalisé via le
schéma d'authentification de ssh. Comme je l'ai
indiqué précédemment, c'est ainsi que les
utilisateurs peuvent accéder au système, tout en
maintenant un haut niveau de sécurité. Si vous
n'êtes pas familier de ssh, jetez un oeuil à <a href=
"http://www.ssh.org/">http://www.ssh.org/</a> Remarquez que
j'utilise la version 1 de ssh, pas la version 2. Il y a une grande
différence, particulièrement sur le fait que la
version 1 est libre, contrairement à la version 2.</p>
<h3>Configurer <code>sshd</code></h3>
<p>Vous aurez besoin de configurer sshd. Les options suivantes
devraient être présentes. L'idée est de
désactiver l'authentification par mot de passe, et les
authentifications par rhosts. Les options suivantes devraient
être présentes dans votre fichier
<code>/etc/sshd_config</code>.</p>
<pre>
PermitRootLogin yes
IgnoreRhosts yes
StrictModes yes
QuietMode no
CheckMail no
IdleTimeout 3d
X11Forwarding no
PrintMotd no
KeepAlive yes
RhostsAuthentication no
RhostsRSAAuthentication no
RSAAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
UseLogin no
</pre>
<h2><a name="ss3.3">3.3 Restreindre les possibilités des
utilisateurs</a></h2>
<p>Maintenant que vous maintenez les méchants à
l'extérieur et ne laissez entrer que les gentils, vous
pourriez avoir besoin de vous assurer que ces derniers se
comportent correctement. La manière la plus simple de le
faire est de ne rien les laisser faire d'autre que de lancer pppd.
Ceci peut être, ou non, nécessaire. J'ai restreins les
possibilités des utilisateurs parce que le système
que je maintiens est dédié au VPN, et que les
utilisateurs n'ont aucune raison de faire quoique ce soir d'autre
dessus.</p>
<h3>sudo ou pas sudo</h3>
<p>Il existe un petit programme propret appelé sudo qui
permet à l'administrateur d'un système Unix
d'autoriser à certains utilisateurs la possibilité de
lancer certains programmes en tant que root. C'est ici certainement
le cas, étant donné que pppd doit être
lancé ainsi. Vous devrez utiliser cette méthode si
vous souhaitez autoriser les accès ligne de commande aux
utilisateurs. Référez-vous à la page man de
sudo pour savoir comment mettre sudo en place. Utiliser sudo est
préférable sur les systèmes multi-usage qui
hébergent généralement un faible nombre
d'utilisateurs de confiance.</p>
<p>Si vous désirez ne pas autoriser les utilisateurs
à disposer d'un accès par ligne de commande, le
meilleur moyen de le faire est de faire que leur shell soit pppd.
Ceci se fait dans le fichier /etc/passwd. Vous pouvez voir <a href=
"#passwd">ci-dessous</a> que c'est ce que j'ai fait pour les trois
derniers utilisateurs. Le dernier champ du fichier /etc/passwd est
le shell de l'utilisateur. Vous n'avez pas besoin de faire quoique
ce soit de spécial à pppd pour le faire fonctionner.
Il est exécuté en tant que root lorsque l'utilisateur
se connecte. C'est certainement la mise en place la plus simple
possible, ainsi que la plus sûre. Elle est idéale pour
les systèmes industriels et à grande échelle.
J'ai décris exactement tout ce qu'il faut faire plus loin
dans ce document. Vous pouvez <a href="#user-accounts">y aller
directement</a> si vous le souhaitez.</p>
<h2><a name="ss3.4">3.4 Le réseau</a></h2>
<p>Maintenant que vos utilisateurs ont accès au
système, nous devons nous assurer qu'ils ont accès au
réseau. Pour ce faire, nous utilisons les règles du
noyau Linux relatives au firewall et les tables de routage. En nous
servant des commandes <code>route</code> et <code>ipfwadm</code>,
nous pouvons configurer le noyau pour gérer le trafic
réseau de manière correcte. Pour plus d'information
sur <code>ipfwadm</code>, <code>ipchains</code> et
<code>route</code>, référez vous au <a href=
"http://www.linuxdoc.org/HOWTO/Linux-Networking-HOWTO.html">Linux
Networking HOWTO</a>.</p>
<h3>Le noyau</h3>
<p>Pour que cela fonctionne, votre noyau doit être
configuré correctement. Si vous ne savez pas comment
créer votre propre noyau, vous devriez lire le <a href=
"http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html">Kernel HOWTO</a>.
Vous devez vous assurer que les options suivantes sont
activées, en plus des options réseaux de base.
J'utilise un noyau 2.0.38 sur mon système.</p>
<p>Pour les noyaux 2.0:</p>
<ul>
<li>CONFIG_FIREWALL</li>
<li>CONFIG_IP_FORWARD</li>
<li>CONFIG_IP_FIREWALL</li>
<li>CONFIG_IP_ROUTER</li>
<li>CONFIG_IP_MASQUERADE (optionnel)</li>
<li>CONFIG_IP_MASQUERADE_ICMP (optionnel)</li>
<li>CONFIG_PPP</li>
</ul>
<p>Pour les noyaux 2.2:</p>
<ul>
<li>CONFIG_FIREWALL</li>
<li>CONFIG_IP_ADVANCED_ROUTER</li>
<li>CONFIG_IP_FIREWALL</li>
<li>CONFIG_IP_ROUTER</li>
<li>CONFIG_IP_MASQUERADE (optionnel)</li>
<li>CONFIG_IP_MASQUERADE_ICMP (optionnel)</li>
<li>CONFIG_PPP</li>
</ul>
<h3>Rêgles de filtrage</h3>
<p>Tout d'abord, nous devons écrire des règles de
filtrage de firewall qui permettent aux utilisateurs
d'accéder à nos réseaux internes, tout en leur
interdisant d'accéder au réseau externe. Cela peut
sembler étrange, mais envisagez le sous cet angle: Ils ont
déjà accès à l'Internet, alors pourquoi
les laisser utiliser le tunnel pour y accéder? Cela
gâche à la fois la bande passante et le
processeur.</p>
<p>Les règles de filtrage utilisées dépendent
du réseau interne utilisé. En gros, elle disent:
"Autoriser le trafic venant de nos VPNs et destiné à
nos réseaux internes". Comment allons nous faire? Comme
toujours, ça dépends. Si vous utilisez un noyau 2.0,
vous devez vous servir d'un outil appelé
<code>ipfwadm</code>, alors que si vous utilisez un noyau 2.0, vous
utiliserez <code>ipchains</code>.</p>
<p>Pour mettre en place les règles avec
<code>ipfwadm</code>, lancez le avec les options suivantes:</p>
<pre>
# /sbin/ipchains -F forward
# /sbin/ipchains -P forward DENY
# /sbin/ipchains -A forward -j ACCEPT -s 192.168.13.0/24 -d 172.16.0.0/12
</pre>
<p>Pour les utilisateurs de noyau 2.2, se référer
à <a href="#ipv4forwarding">ceci</a>.</p>
<h3>Routage</h3>
<p>Désormais, nos utilisateurs sont autorisés
à accéder à nos réseaux, et nous devons
dire au noyau où envoyer les paquets. Sur mon
système, je dispose de deux ethernets : L'un d'entre eux est
relié au réseau externe, l'autre au réseau
interne. Ceci aide à la sécurisation, car le trafic
extérieur est masqué par notre passerelle, et
n'importe quel trafic entrant est filtré et routé par
notre Cisco. Pour la plupart des dispositifs, le routage devrait
être une chose simple.</p>
<p>Nous routons l'intégralité du trafic
destiné au réseaux privés vers l'interface
connectée au réseau interne, et le reste du trafic
vers l'interface externe. Les commandes de routage
spécifiques dépendent des réseaux internes que
vous utilisez. Voici un exemple de ce à quoi elles
pourraient ressembler. Ces lignes sont bien sûr
ajoutées à vos règles de routages habituelles
pour vos réseaux locaux. Je doute que vous utilisiez les
trois groupes d'adresses privées.</p>
<pre>
En supposant que 172.16.254.254 est notre passerelle interne:
# /sbin/route add -net 10.0.0.0 netmask 255.0.0.0 gw 172.16.254.254 dev eth1
# /sbin/route add -net 172.16.0.0 netmask 255.240.0.0 gw 172.16.254.254 dev eth1
# /sbin/route add -net 192.168.0.0 netmask 255.255.0.0 gw 172.16.254.254 dev eth1
</pre>
<p>Encore une chose sur le routage. Si vous utilisez du routage
bidirectionnel, vous aurez alors besoin de réaliser une
chose en plus. Il vous faudra mettre en place les routes revenant
vers le client. La manière la plus simple de le faire est de
lancer un cron chaque minute qui va assigner les valeurs des
routes. Ce n'est pas très grave si le client n'est pas
connecté, <code>route</code> va simplement cracher une
erreur (que vous aurez judicieusement redirigé vers
<code>/dev/null</code>).</p>
<h2><a name="s4">4. Le client</a></h2>
<p>Nous nous consacrons maintenant au client. En pratique,
lorsqu'elle est utilisé pour permettre l'accès
à un réseau distant, cette machine peut facilement
servir de serveur Samba (réseau Windows), DHCP, ou
même web interne. L'aspect important dont il faut se souvenir
est que cette machine doit être aussi sécurisée
que possible, étant donnée qu'elle fait fonctionner
tout votre réseau distant.</p>
<h2><a name="ss4.1">4.1 Le noyau</a></h2>
<p>Commençons par le commencement. Vous devez disposer de
ppp dans votre noyau. Si vous souhaitez autoriser plusieurs
machines à utiliser le tunnel, il vous faut aussi les
services de firewall et de transmission (forwarding). Si le client
consiste en une seule machine, ppp est suffisant.</p>
<h2><a name="ss4.2">4.2 Réaliser la liaison</a></h2>
<p>La liaison est créée en lançant
<code>pppd</code> à travers un pseudo terminal
lui-même créé par <code>pty-redir</code> et
connecté à <code>ssh</code>. C'est ce que
réalise la séquence de commande suivante.</p>
<pre>
# /usr/sbin/pty-redir /usr/bin/ssh -t -e none -o 'Batchmode yes' -c blowfish -i /root/.ssh/identity.vpn -l joe > /tmp/vpn-device
# sleep 10
# /usr/sbin/pppd `cat /tmp/vpn-device`
# sleep 15
# /sbin/route add -net 172.16.0.0 gw vpn-internal.mycompany.com netmask 255.240.0.0
# /sbin/route add -net 192.168.0.0 gw vpn-internal.mycompany.com netmask 255.255.0.0
</pre>
<p>Clairement, on lance ssh, et on redirige ses entrées et
sorties vers pppd. Les options passées à ssh le
configurent pour s'exécuter sans caractère
d'échappement (-e), en utilisant l'algorithme de chiffrement
blowfish (-i), en mode terminal (-l), avec les options 'Batchmode
yes' (-o). Les commandes sleep sont utilisées pour espacer
les exécutions des commandes pour que chacune puisse
compléter son initialisation avant que la suivante ne soit
lancée.</p>
<h2><a name="ss4.3">4.3 Faire des scripts</a></h2>
<p>Bien sûr, vous ne souhaitez pas avoir à taper ces
commandes à chaque fois que vous souhaitez voir le tunnel
fonctionner. J'ai écrit un ensemble de scripts bash qui
gardent le tunnel en état de fonctionnement. Vous pouvez
télécharger le package à partir <a href=
"http://www.shinythings.com/vpnd/vpnd.tar.gz">d'ici</a>. Il suffit
de les télécharger et de les décompresser dans
/usr/local/vpn. Vous trouverez trois fichiers à
l'intérieur:</p>
<ul>
<li>vpnd: le script qui contrôle la connexion du tunnel.</li>
<li>check-vpnd: un script qui sera lancé par le cron pour
vérifier que le VPN fonctionne toujours.</li>
<li>pty-redir: un petit exécutable requis pour l'initiation
du tunnel.</li>
</ul>
<p>Vous aurez besoin d'éditer le script <code>vpnd</code>
pour assigner quelques valeurs telles que le nom d'utilisateur du
client et le nom du serveur. Vous pourrez aussi avoir besoin de
modifier la section starttunnel du script pour spécifier le
réseau utilisé. Vous trouverez ci-dessous une copie
du script pour le plaisir des yeux. Remarquez que vous pouvez
mettre le script dans un répertoire différent, il
suffit de changer la variable VPN_DIR.</p>
<p><a name="vpnd-script"></a></p>
<pre>
#! /bin/bash
#
# vpnd: Monitor the tunnel, bring it up and down as necessary
#
USERNAME=vpn-username
IDENTITY=/root/.ssh/identity.vpn
VPN_DIR=/usr/local/vpn
LOCK_DIR=/var/run
VPN_EXTERNAL=vpn.mycompany.com
VPN_INTERNAL=vpn-internal.mycompany.com
PTY_REDIR=${VPN_DIR}/pty-redir
SSH=${VPN_DIR}/${VPN_EXTERNAL}
PPPD=/usr/sbin/pppd
ROUTE=/sbin/route
CRYPTO=blowfish
PPP_OPTIONS="noipdefault ipcp-accept-local ipcp-accept-remote local noauth nocrtscts lock nodefaultroute"
ORIG_SSH=/usr/bin/ssh
starttunnel () {
$PTY_REDIR $SSH -t -e none -o 'Batchmode yes' -c $CRYPTO -i $IDENTITY -l $USERNAME > /tmp/vpn-device
sleep 15
$PPPD `cat /tmp/vpn-device` $PPP_OPTIONS
sleep 15
# Add routes (modify these lines as necessary)
/sbin/route add -net 10.0.0.0 gw $VPN_INTERNAL netmask 255.0.0.0
/sbin/route add -net 172.16.0.0 gw $VPN_INTERNAL netmask 255.240.0.0
/sbin/route add -net 192.168.0.0 gw $VPN_INTERNAL netmask 255.255.0.0
}
stoptunnel () {
kill `ps ax | grep $SSH | grep -v grep | awk '{print $1}'`
}
resettunnel () {
echo "reseting tunnel."
date >> ${VPN_DIR}/restart.log
eval stoptunnel
sleep 5
eval starttunnel
}
checktunnel () {
ping -c 4 $VPN_EXTERNAL 2>/dev/null 1>/dev/null
if [ $? -eq 0 ]; then
ping -c 4 $VPN_INTERNAL 2>/dev/null 1>/dev/null
if [ $? -ne 0 ]; then
eval resettunnel
fi
fi
}
settraps () {
trap "eval stoptunnel; exit 0" INT TERM
trap "eval resettunnel" HUP
trap "eval checktunnel" USR1
}
runchecks () {
if [ -f ${LOCK_DIR}/tunnel.pid ]; then
OLD_PID=`cat ${LOCK_DIR}/vpnd.pid`
if [ -d /proc/${OLD_PID} ]; then
echo "vpnd is already running on process ${OLD_PID}."
exit 1
else
echo "removing stale pid file."
rm -rf ${LOCK_DIR}/vpnd.pid
echo $$ > ${LOCK_DIR}/vpnd.pid
echo "checking tunnel state."
eval checktunnel
fi
else
echo $$ > ${LOCK_DIR}/vpnd.pid
eval starttunnel
fi
}
case $1 in
check) if [ -d /proc/`cat ${LOCK_DIR}/vpnd.pid` ]; then
kill -USR1 `cat ${LOCK_DIR}/vpnd.pid`
exit 0
else
echo "vpnd is not running."
exit 1
fi ;;
reset) if [ -d /proc/`cat ${LOCK_DIR}/vpnd.pid` ]; then
kill -HUP `cat ${LOCK_DIR}/vpnd.pid`
exit 0
else
echo "vpnd is not running."
exit 1
fi ;;
--help | -h)
echo "Usage: vpnd [ check | reset ]"
echo "Options:"
echo " check Sends running vpnd a USR1 signal, telling it to check"
echo " the tunnel state, and restart if neccesary."
echo " reset Sends running vpnd a HUP signal, telling it to reset"
echo " it's tunnel connection." ;;
esac
ln -sf $ORIG_SSH $SSH
settraps
runchecks
while true; do
i=0
while [ $i -lt 600 ]; do
i=((i+1))
sleep 1
done
eval checktunnel
done
</pre>
<h2><a name="ss4.4">4.4 LRP - Projet de Routeur Linux (Linux Router
Project)</a></h2>
<p>J'ai lancé cette installation sur un Pentium 90
exécutant la distribution LRP de Linux. LRP est une
distribution de Linux qui tient et se charge sur une seule
disquette. Vous en apprendrez plus sur <a href=
"http://www.linuxrouter.org/">http://www.linuxrouter.org/</a>. Vous
pouvez télécharger <a href=
"http://www.shinythings.com/vpnd/vpnd.lrp">ici</a> mon package LRP
pour le client VPN. Vous aurez aussi besoin des packages ppp et ssh
du sîte LRP.</p>
<h2><a name="s5">5. Implémentation</a></h2>
<p>Dans cette section, j'explique pas à pas comment mettre
en place votre système VPN. Je commencerais par le serveur,
et poursuivrais avec le client. Pour les besoins de l'exemple,
j'inventerais une situation qui nécessitera
différentes mise en place de VPN.</p>
<h2><a name="ss5.1">5.1 Organisation</a></h2>
<p>Imaginons que nous ayons une entreprise, appelée
monentreprise.com. Au siège, nous utilisons l'adresse
réseau réservée 192.168.0.0, et
séparons le réseau de classe B en 256 réseaux
de classe C pour permettre le routage. Nous venons de mettre en
place deux petits bureaux distants, et souhaitons les ajouter
à notre réseau. Nous souhaitons aussi permettre aux
employés travaillant chez eux d'utiliser leurs connexions
câble ou DSL plutôt que de leur faire utiliser une
communication directe par modem. Pour commencer, nous devons
organiser quelques peu les choses.</p>
<p>J'ai décidé que je voulais donner à chaque
bureau distant une plage d'adresse de classe C pour leur permettre
de s'étendre si cela devait être nécessaire.
J'ai donc réservé les réseaux 192.168.10.0 et
192.168.11.0. J'ai aussi décidé que pour les
utilisateur se connectant depuis leur domicile, je disposais de
suffisamment d'adresses et que je n'avais donc pas besoin de leur
appliquer de masquarade du côté du serveur VPN. Chaque
client dispose de sa propre adresse IP interne. J'ai donc eu besoin
de réserver une autre adresse réseau de classe C pour
cela, disons 192.168.40.0. La seule chose que j'ai alors du faire
fut d'ajouter ces espaces d'adresse à mon routeur. Imaginons
que notre entreprise possède un petit Cisco
(192.168.254.254) qui gère tout le trafic via notre OC1.
Nous n'avons alors qu'à ajouter les routes sur le Cisco de
telle manière que le trafic dirigé vers ces
réseaux réservés soit dirigé vers notre
serveur VPN (192.168.40.254). J'ai considéré que le
serveur VPN appartenait au réseau de l'utilisateur se
connectant depuis son domicile pour une raison qui sera plus claire
tout à l'heure. Nous appellerons l'interface externe du
serveur vpn.monentreprise.com, et l'interface interne
vpn-interne.monentreprise.com.</p>
<p>Nous n'avons pas besoin de connaître explicitement les
adresses externes. Vous devriez avoir les vôtres, fournies
par votre FAI.</p>
<h2><a name="ss5.2">5.2 Rassembler les outils</a></h2>
<p>Nous allons avoir besoin de quelques logiciels.
Récupérez les packages suivants, et installez les
à l'endroit indiqué.</p>
<h3>Pour le serveur :</h3>
<ul>
<li>pppd (version 2.3 ou supérieure)</li>
<li>ssh (version 1.2.26 ou supérieure)</li>
</ul>
<h3>Pour le client :</h3>
<ul>
<li>pppd (la même version que le serveur)</li>
<li>ssh</li>
<li><a href=
"ftp://ftp.vein.hu/ssa/contrib/mag/pty-redir-0.1.tar.gz">pty-redir</a></li>
</ul>
<h2><a name="ss5.3">5.3 Serveur: Compiler le noyau</a></h2>
<p>Pour commencer, vous aurez probablement besoin de recompiler le
noyau pour le serveur. Il faut vous assurer que les options
suivantes du noyau sont activées, en plus des option
réseaux de base, et de toutes celles dont vous avez besoin.
Si vous n'avez jamais compilé de noyau,
référez vous au <a href=
"/HOWTO/Kernel-HOWTO.html">Kernel HOWTO</a>.</p>
<p>Pour les noyaux 2.0 :</p>
<ul>
<li>CONFIG_FIREWALL</li>
<li>CONFIG_IP_FORWARD</li>
<li>CONFIG_IP_FIREWALL</li>
<li>CONFIG_IP_ROUTER</li>
<li>CONFIG_PPP</li>
</ul>
<p>Pour les noyaux 2.2 :</p>
<ul>
<li>CONFIG_FIREWALL</li>
<li>CONFIG_IP_ADVANCED_ROUTER</li>
<li>CONFIG_IP_FIREWALL</li>
<li>CONFIG_IP_ROUTER</li>
<li>CONFIG_PPP</li>
</ul>
<h2><a name="ss5.4">5.4 Serveur: Configurer les paramètres
réseaux</a></h2>
<p>Si vous préparez un serveur ne disposant que d'une carte
réseau, je vous suggère d'envisager d'en acheter une
autre, et de refaire la connectique de votre réseau. La
meilleure méthode pour garder votre réseau
privé est encore de le doter de ses propres câbles. Si
vous avez deux cartes réseaux, vous aurez besoin de savoir
les configurer. Nous nous servirons de eth0 comme interface
externe, et de eth1 comme interface interne.</p>
<h3>Configurer les interfaces</h3>
<p>Nous devons tout d'abord configurer l'interface externe du
serveur. Vous êtes censé savoir le faire, et l'avez
probablement déjà fait. Si ce n'est pas le cas,
faites le. Si vous ne savez pas le faire, référez
vous au <a href="/HOWTO/NET3-4-HOWTO.html">Networking HOWTO</a></p>
<p>Occupons nous maintenant de l'interface interne. Selon la
numérotation que nous avons choisi, elle dispose de
l'adresse 192.168.40.254.</p>
<p>Pour les noyaux 2.0, utilisez les commandes suivantes :</p>
<pre>
# /sbin/ifconfig eth1 192.168.40.254 netmask 255.255.255.0 broadcast 192.168.40.255
# /sbin/route add -net 192.168.40.0 netmask 255.255.255.0 dev eth1
</pre>
<p>Pour les noyaux 2.2, utilisez la commande suivante :</p>
<pre>
# /sbin/ifconfig eth1 192.168.40.254 netmask 255.255.255.0 broadcast 192.168.40.255
</pre>
<p>Cela active nos interfaces. Vous pouvez maintenant communiquer
avec les machines situées sur les deux réseaux
connectés localement au serveur.</p>
<h3>Mettre les routes en place</h3>
<p>Nous pouvons parler aux machines situées sur nos
réseaux locaux, mais ne pouvons accéder au reste de
notre réseau interne. Ceci nécessite quelques lignes
de code supplémentaires. Pour pouvoir atteindre les machines
situées sur les autres sous-réseaux, nous devons
avoir une route envoyant le trafic vers le routeur Cisco. C'est ce
que fait la commande suivante :</p>
<pre>
# /sbin/route add -net 192.168.0.0 gw 192.168.254.254 netmask 255.255.0.0 dev eth1
</pre>
<p>Cette ligne indique au noyau que le trafic destiné au
réseau 192.168.0.0 devrait être envoyé par
eth1, et transmis au Cisco. Le trafic pour notre réseau
local va toujours où il est supposé aller puisque les
tables de routage sont ordonnées par taille de masque de
sous-réseau. Si nous devions avoir d'autres réseaux
internes dans notre réseau, nous devrions avoir une ligne
comme celle-ci pour chacun d'entre eux.</p>
<h3>Mettre en place les règles de filtrage</h3>
<p>Très bien, nous pouvons donc atteindre toutes les
machines que nous voulons. Nous devons maintenant écrire les
règles de filtrage du firewall qui autorise ou refuse
l'accès au via le serveur VPN.</p>
<p>Pour mettre en place les règles avec
<code>ipfwadm</code>, lancez le ainsi :</p>
<pre>
# /sbin/ipfwadm -F -f
# /sbin/ipfwadm -F -p deny
# /sbin/ipfwadm -F -a accept -S 192.168.40.0/24 -D 192.168.0.0/16
# /sbin/ipfwadm -F -a accept -b -S 192.168.10.0/24 -D 192.168.0.0/16
# /sbin/ipfwadm -F -a accept -b -S 192.168.11.0/24 -D 192.168.0.0/16
</pre>
<p>Pour mettre en place les règles avec
<code>ipchains</code>, lancez le ainsi :</p>
<pre>
# /sbin/ipchains -F forward
# /sbin/ipchains -P forward DENY
# /sbin/ipchains -A forward -j ACCEPT -s 192.168.40.0/24 -d 192.168.0.0/16
# /sbin/ipchains -A forward -j ACCEPT -b -s 192.168.10.0/24 -d 192.168.0.0/16
# /sbin/ipchains -A forward -j ACCEPT -b -s 192.168.11.0/24 -d 192.168.0.0/16
</pre>
<p>Cela dit au noyau de refuser tout trafic, excepté celui
provenant du réseau 192.168.40.0/24 et destiné au
réseau 192.168.0.0/16. Le trafic est autorisé entre
les réseaux 192.168.10.0/24 et 192.168.0.0/16, de même
que pour le réseau 192.168.11.0. Ces deux dernières
règles sont bi-directionnelles, ce qui est important pour
obtenir un routage fonctionnant dans les deux sens.</p>
<h3>Le routage</h3>
<p>Pour les utilisateurs souhaitant se connecter depuis leur
domicile, tout fonctionnera parfaitement à partir de
maintenant. Toutefois, pour les bureaux distants, nous devons
réaliser un peu de routage. Nous devons tout d'abord dire au
routeur principal que les bureaux distants sont derrière le
serveur VPN, et donc lui spécifier des routes indiquant
d'envoyer le trafic destiné aux bureaux distants au VPN.
Ceci fait, il faut indiquer au serveur VPN ce qu'il doit faire de
ce trafic. Pour ce faire, il faut lancer la commande
<code>route</code> sur le serveur. Le seul problème est que
pour que celle-ci fonctionne, la liaison doit fonctionner. Si
celle-ci tombe, la route sera perdue. La solution consiste à
ajouter les routes quand les clients se connectent, ou, plus
simplement, à lancer la commande route fréquemment,
étant donné qu'il n'est pas grave de l'utiliser plus
que nécessaire. De fait, créez un script contenant
les lignes suivantes, et ajoutez le à votre crontab pour
qu'il soit lancé toutes les quelques minutes.</p>
<pre>
/sbin/route add -net 192.168.11.0 gw 192.168.10.253 netmask 255.255.255.0
/sbin/route add -net 192.168.10.0 gw 192.168.11.253 netmask 255.255.255.0
</pre>
<h2><a name="ss5.5">5.5 Serveur: Configurer
<code>pppd</code></a></h2>
<p>Nous allons maintenant configurer pppd sur le serveur pour
gérer les connections au VPN. Si vous utilisez
déjà ce serveur pour gérer des utilisateurs
accédant au réseau par modem, ou que vous même
vous servez d'un modem pour sortir du réseau, sachez que ces
modifications peuvent affecter ces services. J'expliquerais comment
éviter les conflits à la fin de cette section.</p>
<h3><code>/etc/ppp/</code></h3>
<p>Ce répertoire peut contenir de nombreux fichiers. Vous
disposez déjà probablement d'un fichier appelé
<code>options</code>. Ce fichier contient toutes les options
globales pour <code>pppd</code>. Elles ne peuvent être
surchargées par l'utilisation de <code>pppd</code> en ligne
de commande.</p>
<h3><code>/etc/ppp/options</code></h3>
<p>Votre fichier <code>options</code> devrait au moins contenir les
paramètres suivants :</p>
<pre>
ipcp-accept-local
ipcp-accept-remote
proxyarp
noauth
</pre>
<p>Les deux premières lignes indiquent à
<code>pppd</code> d'accepter que l'autre côté
spécifie les adresses IP. Ces options sont
nécessaires lorsque l'on se connecte avec des bureaux
distants, mais peut être désactivée si l'on ne
la fait qu'avec des travailleurs à domicile. Les laisser
activées ne pose pas de problèmes, étant
donné qu'elles n'empêchent pas le serveur d'assigner
une adresse, mais informe simplement celui-ci que le client a le
droit d'en proposer une.</p>
<p>La troisième ligne est très importante. Selon la
page man de <code>pppd</code> :</p>
<pre>
proxyarp
Ajoute une entrée à la table ARP [Address Resolution
Protocol] de ce système avec l'adresse IP du pair
et l'adresse Ethernet de ce système. Cela aura pour
effet de faire croire aux autres systèmes que
le pair est situé sur l'ethernet local.
</pre>
<p>C'est une option importante, car si elle n'est pas
utilisée, le trafic local ne pourra pas revenir par le
tunnel.</p>
<p>La dernière ligne est toute aussi importante. Elle
informe <code>pppd</code> qu'il faut autoriser les connections sans
nom d'utilisateur ni mot de passe. Cette méthode ne nuit pas
à la sécurité, puisque l'authentification est
déjà réalisée par
<code>sshd</code>.</p>
<h3>Eviter les conflits</h3>
<p>Si vous gérez d'autres services avec <code>pppd</code>,
vous devez considérer que les configurations respectives de
ces autres services peuvent être différentes de celle
requise par le VPN. <code>pppd</code> est conçu pour que les
options du fichier d'options principal
<code>/etc/ppp/options</code> ne puissent pas être
surchargées par les options spécifiées au
moment de l'exécution, et ceci pour des raisons de
sécurité. Afin d'éviter les conflits,
déterminez les options qui en sont à l'origine, et
déplacez les du fichier principal vers un fichier d'option
distinct, chargé lorsque l'application appropriée de
<code>pppd</code> est lancée.</p>
<h2><a name="ss5.6">5.6 Serveur: Configurer
<code>sshd</code></a></h2>
<p>Voici a quoi ressemble mon fichier
<code>/etc/sshd_config</code>, et à quoi devrait
approximativement ressembler le votre :</p>
<pre>
# Fichier de configuration ssh du serveur
Port 22
ListenAddress 0.0.0.0
HostKey /etc/ssh_host_key
RandomSeed /etc/ssh_random_seed
ServerKeyBits 768
LoginGraceTime 600
KeyRegenerationInterval 3600
PermitRootLogin yes
IgnoreRhosts yes
StrictModes yes
QuietMode no
FascistLogging yes
CheckMail no
IdleTimeout 3d
X11Forwarding no
PrintMotd no
KeepAlive yes
SyslogFacility DAEMON
RhostsAuthentication no
RhostsRSAAuthentication no
RSAAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
UseLogin no
</pre>
<p>Il est important de remarquer que l'authentification par mot de
passe a été désactivée, tout comme tous
les autres services "r". J'ai aussi désactivé la
notification de mail, et le message du jour, étant
donné qu'il peuvent désorienter <code>pppd</code> du
côté client. J'autorise toujours la connexion en tant
que root, qui reste sûre étant donné qu'elle
requiert l'utilisation d'une clé.</p>
<h2><a name="user-accounts"></a> <a name="ss5.7">5.7 Serveur:
Mettre en place les comptes utilisateurs</a></h2>
<p>Nous allons maintenant mettre en place les comptes
utilisateurs.</p>
<h3>Ajouter un groupe <code>vpn-users</code></h3>
<p>lancez simplement:</p>
<pre>
# /usr/sbin/groupadd vpn-users
</pre>
<p>Faites maintenant un cat du fichier <code>/etc/group</code> et
regardez la dernière ligne. Il doit s'agir de
l'entrée pour le groupe vpn-users. Remarquez le
troisième champ. Il s'agit de l'identifiant du groupe (Group
ID ou GID). Notez le, étant donné que nous allons en
avoir besoin sous peu. Dans notre exemple, GID vaut 101.</p>
<h3>Créer le répertoire domicile des
<code>vpn-users</code></h3>
<p>Nous utiliserons un seul répertoire domicile pour tous
les utilisateurs. Lancez simplement :</p>
<pre>
# mkdir /home/vpn-users
</pre>
<h3>Le répertoire <code>.ssh</code></h3>
<p>Créez maintenant le répertoire <code>.ssh</code>
dans le répertoire domicile des <code>vpn-users</code>.</p>
<pre>
# mkdir /home/vpn-users/.ssh
</pre>
<h3>Ajouter des utilisateurs</h3>
<p>Ca devient amusant. Nous allons éditer le fichier
<code>/etc/passwd</code> à la main :) . Normalement, vous
laissez le système gérer ce fichier, mais pour une
installation aussi étrange que celle-ci, il est plus simple
de le faire vous même. Pour commencer, ouvrons le fichier
<code>/etc/passwd</code> et regardons ce qu'il contient. Voici un
exemple de ce que vous pourriez trouver:</p>
<pre>
...
nobody:x:65534:100:nobody:/dev/null:
mwilson:x:1000:100:Matthew Wilson,,,:/home/mwilson:/bin/bash
joe:*:1020:101:Joe Mode (home),,,:/home/vpn-users:/usr/sbin/pppd
bill:*:1020:101:Bill Smith (home),,,:/home/vpn-users:/usr/sbin/pppd
frank:*:1020:101:Frank Jones (home),,,:/home/vpn-users:/usr/sbin/pppd
...
</pre>
<p>Vous trouverez le premier utilisateur sur la plupart des
systèmes. Le suivant, c'est moi :). Après viennent
quelques vpn-users que j'ai créé. Le premier champ
est le nom d'utilisateur, le second le mot de passe. Le
troisième est l'identifiant d'utilisateur (User ID ou UID),
et le quatrième l'identifiant de groupe. Après
viennent certaines infos sur l'identité de l'utilisateur
(dans le cinquième champ). Le sixième est le
répertoire domicile de l'utilisateur, et le dernier son
shell. Comme vous pouvez le voir, chaque champ est
séparé par une deux points. Regardez les trois
dernières lignes. La seule différence existant entre
eux est le nom d'utilisateur du premier champ et l'information sur
l'utilisateur dans le cinquième. Nous souhaitons
créer une ligne comme celles-ci pour chaque utilisateur.
Evitez d'utiliser un seul utilisateur pour toutes les connections,
faute de quoi il vous sera impossible de les différencier
par la suite. Donc, copiez la dernière ligne du fichier, et
éditez la afin de qu'elle ressemble à notre exemple.
Assurez vous que le second champ contient une astérisque. Le
troisième champ devrait être unique par rapport
à tous les autres identifiants dans le fichier. J'ai
utilisé 1020. Vous devriez utiliser un nombre
supérieur à 1000, étant donné que les
nombres inférieurs à 1000 sont
généralement réservés pour le
système. Le quatrième champ devrait être
l'identifiant du groupe vpn-users. Je vous ai dit tout à
l'heure de l'écrire, c'est maintenant qu'il faut s'en
servir. Donc, mettez ici l'identifiant du groupe. Enfin, changez le
répertoire domicile en <code>/home/vpn-users</code>, et le
shell en <code>/usr/sbin/pppd</code>. C'est fait. Maintenant,
copiez celle ligne pour créer plus d'utilisateurs. Editez
simplement le premier et le dernier champ, et c'est fait.</p>
<h2><a name="ss5.8">5.8 Serveur: Administration</a></h2>
<p>Un des avantages de l'utilisation de ce systèmes pour les
comptes utilisateurs est que l'on peut bénéficier des
commandes d'administrations d'utilisateur UNIX. Comme chaque client
est connecté en tant qu'utilisateur, on peut utiliser les
méthodes standards pour obtenir les statistiques des
utilisateurs. Voici quelques commandes que j'aime utiliser pour
voir ce qui se passe:</p>
<dl>
<dt><b>who</b></dt>
<dd>
<p>Affiche les utilisateurs connectés actuellement, ainsi
que le moment où ils se sont connectés, de quelle
machines (par le nom de celle-ci ou son adresse IP), et sur quel
port.</p>
</dd>
<dt><b>w</b></dt>
<dd>
<p>Cette commande affiche une description plus exhaustive des
entités actuellement connectées. Il fournit aussi le
temps écoulé depuis la mise en fonctionnement du
système, ainsi que sa charge. De même, il liste les
processus des utilisateurs (qui devraient être -pppd pout les
client VPN) qui tournent, le temps processeur non utilisé
(idle time), et l'utilisation faite du processeur, pour chacun des
processus et pour le processus courant. Référez vous
à la page man <code>w</code> pour plus d'information.</p>
</dd>
<dt><b>last [nom_utilisateur]</b></dt>
<dd>
<p>Cette commande fournit l'historique pour l'utilisateur
spécifié, et pour tout les utilisateurs si aucun
nom_utilisateur n'est fourni. Elle est particulièrement
utile pour s'assurer que les tunnels fonctionnent bien, car elle
affiche le temps écoulé depuis la connexion de
l'utilisateur, et donne la liste des utilisateur connectés.
Je dois vous prévenir que sur un système qui n'a pas
été redémarré depuis longtemps, cette
liste peut devenir extrêmement longue. Je vous conseille donc
de l'utiliser conjointement avec <code>grep</code> ou
<code>head</code>, grâce à un pipe, pour
découvrir exactement ce que vous souhaitez.</p>
</dd>
</dl>
<p>Vous pouvez aussi contrôler quels utilisateurs sont
autorisés à se connecter en modifiant le fichier
<code>/home/vpn-users/.ssh/authorized_keys</code>. Si vous en
retirez la ligne contenant la clé publique d'un utilisateur,
il ne sera plus capable de se reconnecter.</p>
<h2><a name="ss5.9">5.9 Client: Compiler le noyau</a></h2>
<p>Nous nous intéressons maintenant au client. Nous devons
tout d'abord recompiler le noyau pour qu'il contienne toutes les
fonctionnalités nécessaires. Il faut au minimum
disposer de ppp dans le noyau. Après cela, il nous faudra
les fonctions de forwarding, de firewall, et de passerelle, mais
seulement si vous comptez autoriser d'autres machines à
accéder au tunnel. Dans cet exemple, je configurerais une
des machines du bureau distant. Ajoutez les options ci-dessous
à votre noyau. Une fois encore, si vous n'avez jamais
recompilé de noyau, référez vous au <a href=
"/HOWTO/Kernel-HOWTO.html">Kernel HOWTO</a>.</p>
<p>Pour les noyaux 2.0:</p>
<ul>
<li>CONFIG_PPP</li>
<li>CONFIG_FIREWALL</li>
<li>CONFIG_IP_FORWARD</li>
<li>CONFIG_IP_FIREWALL</li>
<li>CONFIG_IP_ROUTER</li>
<li>CONFIG_IP_MASQUERADE</li>
<li>CONFIG_IP_MASQUERADE_ICMP</li>
</ul>
<p>Pour les noyaux 2.2:</p>
<ul>
<li>CONFIG_PPP</li>
<li>CONFIG_FIREWALL</li>
<li>CONFIG_IP_ADVANCED_ROUTER</li>
<li>CONFIG_IP_FIREWALL</li>
<li>CONFIG_IP_ROUTER</li>
<li>CONFIG_IP_MASQUERADE</li>
<li>CONFIG_IP_MASQUERADE_ICMP</li>
</ul>
<h2><a name="ss5.10">5.10 Client: Configurer les paramètres
réseaux</a></h2>
<p>Nous devons maintenant configurer les paramètres
réseaux sur notre client. Considérons que tout
fonctionne correctement avec le réseau externe. Nous allons
maintenant mettre en place l'interface interne du client notre
intranet.</p>
<h3>Interface</h3>
<p>Nous devons tout d'abord configurer l'interface réseau
interne. Pour ce faire, ajoutez les lignes suivantes à votre
fichier <code>/etc/rc.d/rc.inet1</code> (ou équivalent):</p>
<p>Pour les noyaux 2.0 :</p>
<pre>
/sbin/ifconfig eth1 192.168.10.253 broadcast 192.168.10.255 netmask 255.255.255.0
/sbin/route add -net 192.168.10.0 netmask 255.255.255.0 dev eth1
</pre>
<p>Pour les noyaux 2.2 :</p>
<pre>
/sbin/ifconfig eth1 192.168.10.253 broadcast 192.168.10.255 netmask 255.255.255.0
</pre>
<h3>Règles de filtrage</h3>
<p>Pour configurer le bureau distant, nous voulons mettre en place
des règles de filtrage qui permettent au trafic d'emprunter
le tunnel dans les deux directions. Ajoutez pour cela les lignes
suivantes à votre fichier <code>/etc/rc.d/rc.inet1</code> ou
équivalent:</p>
<p>Pour les noyaux 2.0 :</p>
<pre>
/sbin/ipfwadm -F -f
/sbin/ipfwadm -F -p deny
/sbin/ipfwadm -F -a accept -b -S 192.168.10.0/24 -D 192.168.0.0/16
</pre>
<p>Pour les noyaux 2.2 :</p>
<pre>
/sbin/ipchains -F forward
/sbin/ipchains -P forward DENY
/sbin/ipchains -A forward -j ACCEPT -b -s 192.168.10.0/24 -d 192.168.0.0/16
</pre>
<p>Vous avez peut-être remarqué que ces lignes
ressemblent à celles que nous avons sur le serveur. C'est
parce qu'elles sont identiques. Elles décrivent simplement
où le trafic est autorisé à aller, c'est
à dire entre les deux réseaux.</p>
<h3>Routage</h3>
<p>Les seules deux routes supplémentaires nécessaires
sont crées par le script qui met en place le tunnel.</p>
<h2><a name="ss5.11">5.11 Client: Configurer
<code>pppd</code></a></h2>
<p>Vous n'aurez peut-être pas besoin d'éditer le
fichier <code>/etc/ppp/options</code> du client. Ce ne sera
nécessaire que si l'option "auth" ou certaines autres
options sont présentes. Essayez, et si ça ne marche
pas, un fichier <code>/etc/ppp/options</code> vide fonctionnera.
Continuez simplement à ajouter les options de l'ancien
fichier pour savoir laquelle pose problème (si ce n'est pas
évident), et regardez si vous pouvez vous en passer.
Peut-être est-ce le cas, notamment si vous ne vous servez de
<code>pppd</code> pour rien d'autre.</p>
<h2><a name="ss5.12">5.12 Client: Configurer
<code>ssh</code></a></h2>
<p>En tant que root, exécutez les lignes suivantes sur le
client:</p>
<pre>
# mkdir /root/.ssh
# ssh-keygen -f /root/.ssh/identity.vpn -P ""
</pre>
<p>Ces commandes vont créer deux fichiers,
<code>identity.vpn</code> et <code>identity.vpn.pub</code> dans le
répertoire <code>.ssh</code>. Le premier est votre
clé privée, et devrait le rester. <em>NE L'ENVOYEZ
JAMAIS SUR LE RESEAU</em>, à moins que ce ne soit au travers
d'un transfert chiffrée. Le second fichier est votre
clé publique, et vous pouvez l'envoyer où vous
voulez, il ne sert qu'à vous autoriser l'accès aux
autres systèmes, et ne peut être utilisé pour
pénétrer le votre. Il s'agit d'un fichier texte d'une
ligne, codant votre clé. A la fin de la ligne se trouve le
champ commentaire, que vous pouvez modifier sans craindre de briser
la clé. Voici un exemple de clé :</p>
<pre>
1024 35 1430723736674162619588314275167.......250872101150654839 root@vpn-client.mycompany.com
</pre>
<p>C'est en fait beaucoup plus long que cela, mais ça ne
tiendrait pas sur une page si je montrais la totalité de la
chose. Copiez votre clé dans le fichier
<code>/home/vpn-users/.ssh/authorized_keys</code> sur le serveur.
Assurez vous qu'il s'agit de la seule clé de la ligne, et
que chaque clé n'est pas séparée sur de
multiples lignes. Vous pouvez modifier le champ de commentaire
comme vous voulez pour vous rappeler quelle clé corresponds
à quel utilisateur. Je vous le recommande fortement.</p>
<h2><a name="ss5.13">5.13 Client: mettre en place la
connexion</a></h2>
<p>Nous allons maintenant essayer de réaliser la connexion
au serveur VPN. Tout d'abord, nous avons besoin d'éditer le
fichier known_hosts de <code>ssh</code> pour réaliser la
moindre connexion. Exécutez ceci:</p>
<pre>
# ssh vpn.mycompany.com
</pre>
<p>Répondez par l'affirmative lorsqu'il vous est
demandé si vous souhaitez continuer à vous connecter.
Le serveur va répondre ''permission denied'', mais c'est
normal. Il est important que vous utilisiez le même nom pour
le serveur que celui que vous utilisez pour vos scripts de
connexion. Exécutez maintenant les lignes suivantes. Vous
aurez évidement besoin de changer la plupart des options
pour correspondre à votre installation.</p>
<pre>
# /usr/sbin/pty-redir /usr/bin/ssh -t -e none -o 'Batchmode yes' -c blowfish -i /root/.ssh/identity.vpn -l vpn-user vpn.mycompany.com > /tmp/vpn-device
(Maintenant, attendez à peu près 10 secondes)
# /usr/sbin/pppd `cat /tmp/vpn-device` 192.168.10.254:192.168.40.254
</pre>
<p>Remarquez les adresses IP spécifiées dans la ligne
pppd. La première est l'adresse du client à l'autre
bout du tunnel. La seconde est l'adresse de l'issue du tunnel
coté serveur, mise à la valeur de l'adresse interne
du serveur. Si tout semble fonctionner, continuez. Si non,
vérifiez que vous avez bien toutes les options, et qu'elles
sont correctement entrée. Si les problèmes
persistent, vérifiez la <a href="#pitfalls">section
Problèmes</a>.</p>
<h2><a name="ss5.14">5.14 Client: Définir les
routes</a></h2>
<p>Définissez maintenant la route pour envoyer le trafic au
travers du tunnel. Lancez simplement cette commande :</p>
<pre>
# /sbin/route add -net 192.168.0.0 gw vpn-internal.mycompany.com netmask 255.255.0.0
</pre>
<p>Vous devriez maintenant être capable de communiquer avec
les machines de l'autre côté du tunnel. Faites un
essais... Nickel, hein? Si ça ne fonctionne pas, essayez
d'utiliser <code>ping</code> et <code>traceroute</code> pour
découvrir où se situe le problème. Si en fait
ça fonctionne réellement, continuez en mettant en
place des scripts qui feront le travail pour vous.</p>
<h2><a name="ss5.15">5.15 Client: Faire des scripts</a></h2>
<p>Utilisez le script vpnd que je montre
<@@ref>vpn-scriptici. Vous n'avez qu'à le modifier un
petit peu. Faites les changements suivants:</p>
<ul>
<li>Changez les variables du début pour correspondre
à votre configuration. La plupart sont probablement
corrects, mais vous pouvez les changer si vous en avez
besoin...</li>
<li>Ligne 27: ajoutez les adresses IP locales et distantes avant
$PPP_OPTIONS</li>
<li>Ligne 31: changez cette ligne, et les deux suivantes pour
configurer les routes pour votre réseau interne.</li>
</ul>
<h3>Le maintenir en état de fonctionnement</h3>
<p>Même si les scripts bash sont généralement
stables, il sont connus pour planter parfois. Pour s'assurer que le
script <code>vpnd</code> continue à tourner, ajoutez une
entrée dans la contab du client qui exécute le script
<code>check-vpnd</code>. Je lance le mien toute les cinq minutes
à peu près. Si <code>vpnd</code> tourne
réellement, <code>check-vpnd</code> n'utilise pas beaucoup
de puissance de calcul.</p>
<h2><a name="s6">6. Annexes</a></h2>
<h2><a name="pitfalls"></a> <a name="ss6.1">6.1
Problèmes</a></h2>
<p>Voici quelques-uns des problèmes que j'ai
rencontré alors que j'utilisais ce système. Je les ai
indiqués ici dans l'espoir que vous puissiez les
éviter. Si vous rencontrez un problème que je ne
décris pas ici, envoyez moi un <a href=
"mailto:matthew@shinythings.com">courrier électronique</a>
pour que je puisse le référencer et permettre aux
autres de l'éviter.</p>
<h3>Lecture : erreur d'entrée/sortie</h3>
<p>Cette erreur vient apparemment de pppd. C'est du à
l'utilisation d'une mauvaise version de pppd. Si cela vous arrive,
essayez de mettre à jour les deux côtés de la
connexion avec la dernière version de pppd. J'ai
découvert que la version 2.2 pose problème, et
utilise les versions 2.3.7 ou 2.3.8 à la place.</p>
<h3>SIOCADDRT: Le réseau est non-atteignable</h3>
<p>Cette erreur est générée par
<code>route</code>. Je l'ai vu se produire quand le temps d'attente
entre <code>ssh</code> et <code>pppd</code> n'est pas assez grand.
Si vous rencontrez cette erreur, lancez <code>ifconfig</code>, il
se peut que vous vous aperceviez qu'il n'y a pas d'interface pppX.
Cela signifie que <code>ssh</code> n'avait pas fini
l'authentification avant que <code>pppd</code> ne soit
lancé, et que <code>pppd</code> n'ait donc pu
réaliser la connexion. Augmentez simplement le délai
d'attente, et vos problèmes seront résolus.</p>
<p>Je me demande toutefois s'il n'existe pas une option pppd qui
règlerait ce problème.</p>
<h3><a name="ipv4forwarding"></a> Transmission IPv4 et les noyaux
2.2</h3>
<p>Dans les nouveaux noyaux 2.2, vous devez spécifier que
vous installez le forwarding IPv4 dans le noyau au
démarrage. Ce qui se fait avec la commande suivante:</p>
<pre>
# echo 1 > /proc/sys/net/ipv4/ip_forward
</pre>
<p>Sans cela, le noyau ne transmettra aucun datagramme, et le
serveur ne fonctionnera donc pas, pas plus qu'aucun des clients
passerelles.</p>
<h3>Routage</h3>
<p>Cela va sans dire, mais faites attention quand vous routez des
adresses réelles que vous ne routez pas le trafic
destiné aux adresses externes du serveur VPN au travers du
tunnel. Ca ne le fera pas (Oui, il s'agit <em>vraiment</em> d'une
expérience personnelle).</p>
<h2><a name="ss6.2">6.2 Configuration minimale matérielle et
logicielle</a></h2>
<h3>Configuration matérielle minimale</h3>
<p>Croyez le ou pas, ce système a été
exécuté sur un 486SX33 avec 8 Mo de RAM. Ca ne
marchait toutefois pas très bien, car il avait des
problèmes à gérer le gros trafic.</p>
<p>Ca n'a cependant pas été trop dur de le faire
fonctionner. Ce système marche très bien sur un
Pentium 75 avec 16 Mo de RAM, utilisant une distribution LRP sur
disquette, avec 6 Mo de ramdisk, et 10 Mo de mémoire
principale. J'ai testé cette configuration en faisant passer
un flux RealVideo à 700Kbits au travers pendant plus d'une
heure.</p>
<p>Je le fait maintenant fonctionner en général sur
des Pentium 90, étant donné que leur fréquence
d'horloge fonctionne mieux avec les cartes Ethernet à
100Mbits/sec.</p>
<h3>Configuration logicielle minimale</h3>
<p>Ce système fonctionne tant avec les noyaux 2.0 qu'avec
les 2.2. Le script permettant de garder le tunnel en fonctionnement
demande un bash raisonnablement moderne. J'ai toutefois
remarqué que les versions de bash que l'on trouve sur
certaines distributions ne fonctionnent pas très bien avec
le script.</p>
<p>De fait, si quelqu'un pouvait m'aider à améliorer
mes scripts (ou même à écrire un
exécutable?), ça m'aiderait beaucoup. Je ne suis pas
certains de savoir pourquoi, mais même mon propre bash ne
suit pas les règles et ne semble pas interpréter les
signaux correctement. Si vous faites des améliorations,
envoyez moi un courrier électronique à <a href=
"mailto:matthew@shinythings.com">matthew@shinythings.com</a> s'il
vous plait.</p>
</body>
</html>
|