Debian-facile
Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#1 Re : Vos sites et projets perso » nakeDeb, une debian toute nue, but safe for work ! » 07-06-2023 00:06:42
Je viens de tester rapidement nakeDeb v1.4.6 sous VMware Workstation (gratuit!) avec 1 CPU, 1Go de RAM et 10 Go de disque, carte graphique 32Mo, c'est bluffant, ça tourne très bien !
(hôte agé d'environ 4 ans, mais pas trop faiblard: 4 coeurs Intel Core i5-8250U CPU @ 1.60GHz, en SSD)
Apps que j'ai installées:
* Chromium (=Chrome déGoogle-isé
) , bien plus rapide que Firefox !+ Ublock Origin : filtre anti-pub efficace pour économiser RAM et CPU bouffés par les pubs !
+ Close all & Clean : pour tout nettoyer en sortant du browser (selon les options cochées au niv du plugin)
Lecture vidéo/audio fluide dans Youtube
* LibreOffice (dernière version)
=> peu de RAM consommée, opérationnel !
Bravo Arpinux pour cette belle réalisation optimisée au max pour exploiter au mieux les ressource d'une machine !
Super pour donner une 2nde vie à un vieux PC ou créer une mini-VM...
Sais-tu si Nukedeb fonctionne bien sur un Asus eeePC 1000H avec 2 Go de RAM, en wifi ?
J'en ai un qui traîne qqpart, en dual boot avec W7 et Slax 9.x ... si j'ai un peu de temps, je les mettrais bien en concurrence, par curiosité.
@+
El Gecko
#2 Re : Réseau » OpenVPN: accès soudain impossible cause perte configuration(ufw...)!?! » 06-06-2023 23:04:39
Ha, je me sens un peu moins seul avec cette histoire de fou !
Ce VPS est apparemment sous KVM d'après le résultat de lscpu .
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 40 bits physical, 48 bits virtual
CPU(s): 2
On-line CPU(s) list: 0,1
Thread(s) per core: 1
Core(s) per socket: 2
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 45
Model name: Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz
Stepping: 7
CPU MHz: 3200.350
BogoMIPS: 6400.70
Hypervisor vendor: KVM <= <= <= <= <=
Virtualization type: full
L1d cache: 64 KiB
L1i cache: 64 KiB
L2 cache: 8 MiB
L3 cache: 16 MiB
NUMA node0 CPU(s): 0,1
Vulnerability Itlb multihit: KVM: Mitigation: VMX unsupported
Vulnerability L1tf: Mitigation; PTE Inversion
Vulnerability Mds: Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown
Vulnerability Meltdown: Mitigation; PTI
Vulnerability Mmio stale data: Unknown: No mitigations
Vulnerability Retbleed: Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2: Mitigation; Retpolines, IBPB conditional, IBRS_FW, STIBP disabled, RSB filling, PBRSB-
eIBRS Not affected
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fx
sr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl
xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic pop
cnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm cpuid_fault pti ssbd ibrs ibpb
tsc_adjust xsaveopt arat umip
Les causes de la perte du SSH sont hyper obscures aussi.
Via une connexion x2go en SSH sur le port 22, j'ai réparé la conf OpenVPN puis a un moment j'ai arrêté et redémarré ufw puis j'ai rebooté et là, impossible de me reconnecter en SSH !?!
J'ai du passer par VNC et galéré un max avec la saisie de mon mot de passe root complexe, avec un pb de clavier mal géré... grrrrr... ! 
C'est quand même très pète burettes ces config qui disparaissent pour de très sombres raisons !
Heureusement, ce n'est pas de la PROD...
Je peux signaler le pb. au support de l'hébergeur mais avec mon tarif à 4€/mois de 2019, je n'ai rien à espérer !
Pour 2 CPU, 4 Go de RAM, 300Go de disque, 100Mbit/s, c'est cadeau mais faut pas trop en attendre...
@+
El Gecko.
#3 Réseau » OpenVPN: accès soudain impossible cause perte configuration(ufw...)!?! » 05-06-2023 22:09:30
- El_Gecko
- Réponses : 2
Il m'est arrivé un truc très curieux sur un VPS (2 CPU, 4 Go RAM ) sous Debian 11.
J'avais configuré récemment un serveur OpenVPN qui marchait très bien sur le port 443 en TCP et il y a 2 jours, impossible d'y accéder, à partir d'un client Unix ou Android.
Le service OpenVPN démarrait très bien mais impossible d'y accéder.
J'ai même perdu l'accès SSH !
En fait, j'ai du refaire à la main presque toute la partie réseau de l'installation:
Ajout:
net.ipv4.ip_forward = 1
---
sudo nano /etc/ufw/before.rules
Ajout:
# START OPENVPN RULES
# NAT table rules
*nat
:POSTROUTING ACCEPT [0:0]
# Allow traffic from OpenVPN client to eth0 (change to the interface you discovered!)
-A POSTROUTING -s 10.8.0.0/8 -o eth0 -j MASQUERADE
COMMIT
# END OPENVPN RULES
---
sudo nano /etc/default/ufw
Modif:
DEFAULT_FORWARD_POLICY="ACCEPT"
----
sudo ufw allow 22
sudo ufw allow 443
Je ne comprends vraiment pas ce qui a pu se passer. Comment ces réglages ont pu disparaître soudainement ?!?
Je soupçonne une mise à jour de sécurité faite le 3/6/2023 mais je trouve ça extrême !
Voici l'historique intégral des commandes lancées avant l'incident, sans utiliser le VPN, avec un compte du groupe sudo :
-----------------
sudo hdparm -Tt /dev/sda
sudo apt-get install hdparm
sudo apt update
sudo apt list --upgradable
sudo apt dist-upgrade
sudo apt list --upgradable
sudo apt update
sudo hdparm -Tt /dev/sda
sync; dd if=/dev/zero of=tempfile bs=1M count=1024; sync
ls
rm tempfile
hdinfo
sud hdinfo
lspci
lsusb
w
smartctl -a /dev/sda
sudo smartctl -a /dev/sda
sudo apt install smartctl
sudo smartctl
smartctl
sudo lshw -c disk
cat /sys/block/sda/queue/rotational
lsblk -d -o name,rota
time for i in `seq 1 1000`; do dd bs=4k if=/dev/sda count=1 skip=$(( $RANDOM * 128 )) >/dev/null 2>&1; done
cat /proc/scsi/scsi
sudo cat /proc/scsi/scsi
sg_vpd --page=bdc /dev/sda
sudo sg_vpd --page=bdc /dev/sda
sudo lshw -short -C disk
lsblk
cat /sys/block/sda/queue/rotational
sudo smartctl -a /dev/sda | grep 'Rotation Rate'
sudo hdparm -I /dev/sd*X* | grep SATA
sudo hdparm -I /dev/sda | grep SATA
sudo hdparm -I /dev/sda
cat /sys/block/vda/queue/rotational
cat /proc/scsi/scsi
sudo apt-get install fio
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=random_read_write.fio --bs=4k --iodepth=64 --size=250M --readwrite=randrw --rwmixread=80
cd T*
cd ..
ls
cd Dow*
ls
cd Gee*
cd Geekbench-6.0.3-Linux
ls
./geekbench6
ps -ef | grep vpn
-----------------------
Je n'ai pas souvenir d'avoir lancé autre chose qu'un browser en mode graphique (Chromium ou Opera), j'ai très peu d'apllis graphiques installées, j'utilise principalement le terminal.
Avez-vous déjà rencontré ce genre de problème ???
Franchement, j'aimerais bien comprendre pour éviter que cela ne se reproduise.
@+
El Gecko.
#4 Re : Installation de Debian » Debian 10 + Opera 88 = la cata !!! » 07-07-2022 01:26:36
Le pb disparaît si je désinstalle Opera. Càd que je peux à nouveau utiliser sans erreur apt update et apt ugrade.
Merci pour ces suggestions que je vais tester ce WE car là, je tombe de sommeil.
@+
El Gecko.
#5 Re : Réseau » SSH : MobaXterm vs Putty » 07-07-2022 01:15:31
Aux grands maux les grands remèdes comme on dit !
J'ai retrouvé un WireShark portable qui traînait dans un coin de mon disque dur, même pas besoin de le dl !
Et là...on voit le "handshake" dans toute sa splendeur.
Les 1ères captures (l.143 à161) sont celles faites lors d'une cnx° OK via Putty vers le port SSH 443.
l. 426-481: test KO de cnx° via MobaXterm vers le port SSH 443 (qui n'est plus associé par Wireshark au protcole SSL mais toujours TCP).
J'ai toujours cru que juste après le handshake, la chaîne identifiant la version du client était envoyée.
Mais bon, là, MobaXterm a fait un autre choix, pourquoi ? Mystère !
Putty et X2Go passent sans problème en SSH par ce port 443.
@+
El Gecko.
#6 Installation de Debian » Debian 10 + Opera 88 = la cata !!! » 04-07-2022 23:58:00
- El_Gecko
- Réponses : 3
Je teste différents navigateurs et j'ai voulu installer la dernière version d'Opera ( dpkg -i opera-stable_88.0.4412.27_amd64.deb ) sous Debian 10 : c'est la cata !
Depuis, c'est un souk pas possible pour la mise à jour du système.
Seul remède, désinstaller Opéra, ce que propose apt --fix-broken install ?
Quelqu'un a déjà testé avec succès Opera sous Debian 10 ???
Hit:1 http://asi-fs-m.contabo.net/debian buster InRelease
Get:2 http://asi-fs-m.contabo.net/debian buster-updates InRelease [51.9 kB]
Get:3 http://security.debian.org/debian-security buster/updates InRelease [65.4 kB]
Hit:4 https://brave-browser-apt-release.s3.brave.com stable InRelease
Hit:5 https://deb.opera.com/opera-stable stable InRelease
Ign:6 http://download.webmin.com/download/repository sarge InRelease
Hit:7 http://download.webmin.com/download/repository sarge Release
Get:8 http://security.debian.org/debian-security buster/updates/main Sources [244 kB]
Get:9 http://security.debian.org/debian-security buster/updates/main amd64 Packages [334 kB]
Get:10 http://security.debian.org/debian-security buster/updates/main Translation-en [182 kB]
Fetched 877 kB in 1s (756 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
1 package can be upgraded. Run 'apt list --upgradable' to see it.
W: Target Packages (non-free/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list:14 and /etc/apt/sources.list.d/opera-stable.list:4
W: Target Packages (non-free/binary-all/Packages) is configured multiple times in /etc/apt/sources.list:14 and /etc/apt/sources.list.d/opera-stable.list:4
W: Target Translations (non-free/i18n/Translation-en_US) is configured multiple times in /etc/apt/sources.list:14 and /etc/apt/sources.list.d/opera-stable.list:4
W: Target Translations (non-free/i18n/Translation-en) is configured multiple times in /etc/apt/sources.list:14 and /etc/apt/sources.list.d/opera-stable.list:4
W: Target Packages (non-free/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list:14 and /etc/apt/sources.list.d/opera-stable.list:4
W: Target Packages (non-free/binary-all/Packages) is configured multiple times in /etc/apt/sources.list:14 and /etc/apt/sources.list.d/opera-stable.list:4
W: Target Translations (non-free/i18n/Translation-en_US) is configured multiple times in /etc/apt/sources.list:14 and /etc/apt/sources.list.d/opera-stable.list:4
W: Target Translations (non-free/i18n/Translation-en) is configured multiple times in /etc/apt/sources.list:14 and /etc/apt/sources.list.d/opera-stable.list:4
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
opera-stable : Depends: libgcc-s1 (>= 3.0) but it is not installable
Recommends: pepperflashplugin-nonfree but it is not installed
Recommends: chromium-codecs-ffmpeg-extra but it is not installable
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).
#7 Re : Réseau » SSH : MobaXterm vs Putty » 04-07-2022 23:04:15
Pas de nouvelle de mes nouveaux amis du support de MobaXterm mais bon, rien de surprenant, je suis sur une verson gratuite !
Bon, j'ai refait un test de capture réseau sans aucun filtre pour être sûr de ne rien manquer, j'ai toujours le même résultat:
Connexion MobaXterm vers le port SSH 44322: OK, le prompt de login s'affiche
Connexion MobaXterm vers le port SSH 443 : KO, le prompt n'apparaît jamais et absolument rien ne passe sur le réseau !?!
(pas de copie d'écran, rien à montrer !)
Avec Putty, sur lequel est sensé s'appuyer MobaXterm, tout marche nickel !
Connexion Putty vers le port SSH 44322: OK, le prompt de login s'affiche
Connexion Putty vers le port SSH 443: OK, le prompt de login s'affiche
Le serveur n'initie pas la session, il envoie sa version quand il reçoit une connexion.
Et on ne voit rien passer sur le réseau "quand il reçoit une connexion" ??? 
@+
El_Gecko
#8 Re : Réseau » SSH : MobaXterm vs Putty » 27-06-2022 23:23:35
...je ne vois pas ce que je pourrais faire de plus puisque tu as déjà confirmé mon hypothèse.
J'ai regardé avec un petit sniffer gratuit très basique (Nirsoft - Smart sniffer) mais qui rend bien des services.
Je pensais que tu étais peut-être mieux outillé (Wireshark...) et plus compétent que moi pour une observation plus précise.
Mais bon, le serveur qui initie la session, ça m'intrigue.
C'est plus un serveur, par définition, non ?
....ou alors il crée un tunnel puis attend le client mais là, c'est pas le cas.
Si MobaXterm daigne me répondre, je vous tiendrai au jus.
@+
El Gecko.
#9 Re : LXDE » X2Go : caractères spéciaux par [Alt Gr] absents au clavier » 27-06-2022 23:01:35
Eurêka !
La réponse était dans la question.
"VPS X2go OK
... (toutes les installations ont été faites via sudo avec un user du groupe sudo)"et cela fait toute la différence !
La touche AltGr [Alt Gr] (hé, hé, ça marche, j'ai bien accès aux crochets!) est KO si je me connecte via X2Go en root !
Elle marche nickel avec n'importe quel user, qu'il appartienne ou non au groupe sudo.
Hé oui, on n'est pas sensé se connecter à distance en étant root, pour des raisons de sécurité, mais ils aurient pu mettre un warning !
En fait, tout marche très bien en root sauf cette touche de clavier.
D'après ce que j'ai compris, pour root, il manque certains fichiers de conf X11.
@+ (Wahooo! Un @ !)
El Gecko.
#10 Re : Réseau » SSH : MobaXterm vs Putty » 26-06-2022 17:01:16
Je n'ai ni putty ni mobaxterm pour le vérifier.
Si tu as un poste client sous Windows sous le coude:
La dernière version portable et gratuite de MobaXterm est dispo ici:
https://mobaxterm.mobatek.net/download- … ition.html
Pour Putty portable et gratuit, c'est par ici :
https://portableapps.com/apps/internet/putty_portable
#11 Re : Installation de Debian » Quel Debian pour 512Mo de RAM ? » 26-06-2022 16:18:49
En fait, le gros intérêt est quand on dispose d'un débit internet très faible.
Je fais du "remote desktop" vers le VPS ce qui permet de ne transférer en fait que des copies d'écran.
Le VPS dispose par contre d'une connexion stable à 100 Mbits/s et de CPU et RAM à prix très abordable.
Comme poste client nomade, j'ai un vieil ultraportable qui date de 7 ans, passé de 2Go à 8Go et qui est largement suffisant pour servir de terminal.
Avec X2go (gratuit et open source), j'ai été supris par le grand nombre de paramètres, hélas peu documentés, lui permettant de fonctionner avec des débits très faibles.
J'ai testé sur un réseau 4G saturé ou j'avais à peine 128kbits/s !!!
(le seul truc qui me rend fou avec X2go c'est la touche AltGr parfois non gérée, j'ai ouvert un sujet dans la rubrique "LXDE")
En réduisant la résolution, le nombre couleurs, en augmentant la compression, j'arrivais à surfer, en conditions certes dégradées mais ça marchait !
...j'attendais env. 7 sec. entre chaque clic pour faire défiler une page !
En connexion directe avec un browser sur smartphone, c'était inexploitable...
Bon, c'est vraiment pour les cas d'urgence mais ça dépanne bien !
@+
El_Gecko.
#12 Re : Réseau » SSH : MobaXterm vs Putty » 26-06-2022 15:54:50
option port-share ... Currently only designed to work with HTTP/HTTPS, though it would be theoretically possible to extend to other protocols such as ssh.
C'est justement ça qui a attisé ma curiosité !
... et ça marche nickel avec Putty et X2go qui passent sans soucis en SSH sur les ports 443 et 44322 !
MobaXterm qui s'appuie, d'après mes lectures, pourtant sur Putty, semble attendre indéfiniment.
Dans le protocole SSH, le client peut attendre que le serveur parle en premier.
???
C'est la 1ère fois que je lis ça... mais c'est ce qui semble se passer !?!
Je ne vois pas bien comment ça peut marcher.
Tu aurais un peu de littérature sur le sujet ?
J'ai sniffé le début de session, sous Putty, on voit que c'est Putty qui parle en 1er à Debian SSH server.
Avec MobaXterm vers le port SSH 44322, on voit Debian SSH server en 1er !
Ca me démange les neurones tout ça !
J'ai d'ailleurs branché le support MobaXterm sur le sujet, mais bon, comme je suis en version gratuite, mon cas n'est bien sûr pas prioritaire ! Ils m'ont fait testé avec leur ancien "SSH engine" mais ça ne change rien.
Et puis le transport d'un VPN de couche 2 ou 3 sur TCP, ce n'est pas idéal pour les performances. A utiliser en dernier recours.
UDP est certes à privilégier pour les perfs si disponible et non bridé.
Mais je préfère avoir un accès VPN lent mais qui marche partout plutôt que rien du tout.
L'idéal est d'avoir une instance OpenVPN en UDP et l'autre en TCP.
Mais le top du top en matière de vitesse est le tunnel SSH d'où l'idée d'avoir via le port 443, toujours ouvert, accès à un serveur VPN et un serveur SSH. C'est ceinture et bretelles !
Ceci offre un maximum de chance d'accès au web, qqs le routeur par lequel on passe.
/!\ Contourner la "censure" ou le blocage de ports peux coûter très cher selon les pays ou... la charte régissant les activités pro ou scolaires /!\
@+
El_Gecko.
#13 Re : LXDE » X2Go : caractères spéciaux par [Alt Gr] absents au clavier » 26-06-2022 14:39:23
Merci d'avoir jeté un oeil.
Cette liste n'est effectivement pas toute jeune.
On trouve sur le web pas mal de gens qui se plaignent de ce bug depuis longtemps mais jamais de réponse vraiment concluante.
Ce qui est fou, c'est que j'ai monté depuis peu 2 VPS sous Debian 11 et ça marche nickel seulement sur l'un des deux !
La config est similaire:
- Debian 11
VPS X2go OK
... (toutes les installations ont été faites via sudo avec un user du groupe sudo)Linux vps-O 5.10.0-15-cloud-amd64 #1 SMP Debian 5.10.120-1 (2022-06-09) x86_64 GNU/Linux
VPS X2go KO ... (toutes les installations ont été faites aves le user root)
Linux vps-H 5.10.0-15-cloud-amd64 #1 SMP Debian 5.10.120-1 (2022-06-09) x86_64 GNU/Linux
- dernier package LXDE light
VPS X2go OK
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
lxde-common/stable,now 0.99.2-4 all [installed,automatic]
lxde-core/stable,now 11 all [installed]
lxde-icon-theme/stable,now 0.5.1-2.1 all [installed,automatic]
openbox-lxde-session/stable,now 0.99.2-4 all [installed,automatic]
VPS X2go KO
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
lxde-common/stable,now 0.99.2-4 all [installed,automatic]
lxde-core/stable,now 11 all [installed]
lxde-icon-theme/stable,now 0.5.1-2.1 all [installed,automatic]
openbox-lxde-session/stable,now 0.99.2-4 all [installed,automatic]
- dernier package X2go
VPS X2go OK
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
libx2go-config-perl/stable,now 4.1.0.3-5 all [installed,automatic]
libx2go-log-perl/stable,now 4.1.0.3-5 all [installed,automatic]
libx2go-server-db-perl/stable,now 4.1.0.3-5 amd64 [installed,automatic]
libx2go-server-perl/stable,now 4.1.0.3-5 all [installed,automatic]
libx2go-utils-perl/stable,now 4.1.0.3-5 all [installed,automatic]
x2goserver-common/stable,now 4.1.0.3-5 all [installed,automatic]
x2goserver-extensions/stable,now 4.1.0.3-5 all [installed,automatic]
x2goserver-fmbindings/stable,now 4.1.0.3-5 all [installed,automatic]
x2goserver-printing/stable,now 4.1.0.3-5 all [installed,automatic]
x2goserver-x2goagent/stable,now 4.1.0.3-5 amd64 [installed,automatic]
x2goserver-xsession/stable,now 4.1.0.3-5 all [installed]
x2goserver/stable,now 4.1.0.3-5 amd64 [installed]
VPS X2go KO
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
libx2go-config-perl/stable,now 4.1.0.3-5 all [installed,automatic]
libx2go-log-perl/stable,now 4.1.0.3-5 all [installed,automatic]
libx2go-server-db-perl/stable,now 4.1.0.3-5 amd64 [installed,automatic]
libx2go-server-perl/stable,now 4.1.0.3-5 all [installed,automatic]
libx2go-utils-perl/stable,now 4.1.0.3-5 all [installed,automatic]
x2goserver-common/stable,now 4.1.0.3-5 all [installed,automatic]
x2goserver-extensions/stable,now 4.1.0.3-5 all [installed,automatic]
x2goserver-fmbindings/stable,now 4.1.0.3-5 all [installed,automatic]
x2goserver-printing/stable,now 4.1.0.3-5 all [installed,automatic]
x2goserver-x2goagent/stable,now 4.1.0.3-5 amd64 [installed,automatic]
x2goserver-xsession/stable,now 4.1.0.3-5 all [installed]
x2goserver/stable,now 4.1.0.3-5 amd64 [installed]
- même version de X2go client, unique
...
en fait, tout pareil, en suivant des notes d'installation qui me servent de guide.
Sur les 2 VPS:
Cannot open display "default display"
NB: en console SSH, je n'ai aucun problème de clavier, la touche AltGr est OK
Y'a bien une différence quelque part mais où ?
Plutôt au niveau X11, peut-être ?
J'ai remarqué qu'il manque des fichiers de conf X11 mais c'est la cas sur les 2 VPS...
Y'a-t-il un expert en conf clavier sur le forum ?
@+
El Gecko.
#14 Réseau » SSH : MobaXterm vs Putty » 25-06-2022 00:59:18
- El_Gecko
- Réponses : 10
J'ai un problème bizarre.
Sous Debian 11, sur un VPS tout beau tout neuf, j'ai configuré tout récemment OpenVPN sur le port 443 en TCP, avec redirection vers le port SSH 44322/TCP.
Le port 443 est comme "partagé" entre les services VPN et SSH.
Très pratique pour s'assurer d'avoir un accès VPN et SSH quel que soit le matériel auquel on est connecté (hotspot Wifi...), le port 443 étant toujours ouvert.
Cool, non ?
Dans /etc/openvpn/server.conf j'ai :
...
proto tcp
port 443
# Acces SSH via port 443 redirige vers port 44322
port-share localhost 44322
...
J'ai testé avec Putty, l'accès SSH marche nickel sur les 2 ports !
Par contre, avec MobaXterm, que je trouve assez pratique quand on utilise plusieurs machines, impossible d'accéder en SSH via le port 443 !
Seul l'accès SSH en 44322 est OK.
La dernière version portable et gratuite de MobaXterm est dispo ici:
https://mobaxterm.mobatek.net/download- … ition.html
Pour Putty portable et gratuit, c'est par ici :
https://portableapps.com/apps/internet/putty_portable
Si une bonne âme veut bien se donner la peine de tester et de communiquer les résultats obtenus, merci !
Le VPS : 51*38*235*238
2 ports à tester en SSH : 443 et 44322
Objectif: obtenir le prompt de login
@+
El Gecko.
#15 Re : LXDE » X2Go : caractères spéciaux par [Alt Gr] absents au clavier » 25-06-2022 00:37:44
Personne n'utilise x2go ???
#16 LXDE » X2Go : caractères spéciaux par [Alt Gr] absents au clavier » 16-06-2022 22:21:52
- El_Gecko
- Réponses : 4
J'aime bien X2Go comme solution d'accès à un bureau à distance (LXDE dans mon cas), offrant plein de paramètres pour fonctionner avec un très faible débit réseau mais la gestion du clavier est rebutante.
Impossible d'obtenir le moindre caratère avec la touche [Alt Gr] (AltGr).
C'est très embêtant pour consulter ses mails, taper un | dans la console... !
NB: je suis sur ultraportable, donc clavier réduit (pas testé avec un clavier classique mais ça ne m'intéresse pas).
Avez-vous dèjà réussi à régler ce problème ?
Celà fonctionne-t-il en standard avec d'autres environnements graphiques ? Lesquels ?
Merci !
El Gecko.
#17 Re : Installation de Debian » Quel Debian pour 512Mo de RAM ? » 16-06-2022 22:01:41
Merci pour vos retours.
Effectivement, j'ai fait quelques essais sous Virtualbox, avec 512Mo, c'est quasiment impossible de faire tourner un navigateur moderne, conforme aux derniers standards techniques et de sécurité.
Midori fonctionne à peu près sur des sites légers, en mono-onglet.
En fait, c'était par rapport à une offre de VPS à 1.2€/mois (1vCPU, 512Mo de RAM, SSD 10 Go), je me demandais si on pouvait faire tourner une petite station web.
La réponse est clairement NON.
Comme dit Otyugh, c'est bon pour faire tourner des services uniquement (ex.: un OpenVPN pas cher...).
Finalement, j'ai opté pour une offre à 3.6€/mois, 1 vCPU, 2 Go de RAM, 20Go SSD.
Je trouve ça "terriblement" cher (l'inflation mon pôve môssieur !) par rapport à mon VPS actuel qui pour 4€/mois m'offre 2 vCPU, 4 Go de RAM et 300Go, souscrit avant la pandémie !
Pourquoi faire tourner un browser sur un VPS ?
Je vous laisse deviner...
@+
El Gecko.
#18 Installation de Debian » Quel Debian pour 512Mo de RAM ? » 14-06-2022 00:29:27
- El_Gecko
- Réponses : 8
Au niveau conso RAM, en installation minimale, Debian 10 ou 11, c'est kif kif ?
Avec LXDE et Midori ou Falkon comme browser, ça peut fonctionner à peu près correctement ?
Merci.
EL Gecko.
#19 Re : Système » VPS inaccessible (réparer grub?) » 13-06-2022 23:28:26
Désolé, je ne comprends pas trop ce que tu veux dire.
http et https sont définis dans /etc/services
Il faut faire les modifs de port dans ce fichier d'ailleurs et tout port non standard que l'on souhaite utiliser doit y être ajouté (ce n'est pas obligatoire certes mais c'est une bonne pratique il me semble).
@+
El Gecko.
#20 Re : Réseau » [RESOLU] xRDP via OpenVPN » 11-06-2022 23:00:22
Un petit complément utile à rappeler, pour rendre les règles persisantes, taper:
Le fichier /etc/iptables.up.rules est importé au démarrage du système dans le script /etc/network/iptables par la commande:
On peut utiliser iptables-save > fichier_backup_regles pour sauver différentes configurations du parefeu, c'est pratique.
Pour lister les règles :
...mais perso, je trouve l'affichage très indigeste !
En fait, il ne manquait que la règle suivante, qui a mystérieusement disparu puisque cet OpenVPN a fonctionné durant des mois.
Les 2 règles suivantes étaient déjà présentes ?
> iptables -A FORWARD -i ens18 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
et correspondent à ça ???
3133K 3543M ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
0 0 ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
Pas évident de faire le rapprochement !
3133K 3543M : c'est quoi ? Des stat. d'utilisation de la règle ???
La 2e règle n'est jamais appliquée ?
La règle :
ne semble pas m'être utile...
Je ne la vois pas dans la liste retournée par iptable -L -n en cherchant POSTROUTING ou MASQUERADE .
Mais je dois mal chercher.
C'est sensé autoriser quoi cette règle ?
@+
El_Gecko
#21 Re : Système » VPS inaccessible (réparer grub?) » 11-06-2022 22:14:03
J'ai masqué le problème en désactivant IPV6 (pas d'utilité) pour ufw:
Dans /etc/default/ufw
Simple, rapide et efficace!
El_Gecko.
#22 Re : Réseau » [RESOLU] xRDP via OpenVPN » 09-06-2022 23:29:40
Je m'auto-réponds.
J'ai trouvé une solution via iptables , obsolète sous Debian 10, je crois, mais ça marche !
source :https://arashmilani.com/post?id=53
Attention à bien préciser la bonne interface, ici ens18 (trouvée avec la commande ip link)
Adapter les commandes au masque d'adresse IP, au port et protocole utilisés par OpenVPN !
-------
> iptables -A INPUT -i ens18 -m state --state NEW -p tcp --dport 443 -j ACCEPT
> iptables -A INPUT -i tun+ -j ACCEPT
> iptables -A FORWARD -i tun+ -j ACCEPT
> iptables -A FORWARD -i tun+ -o ens18 -m state --state RELATED,ESTABLISHED -j ACCEPT
> iptables -A FORWARD -i ens18 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
> iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o ens18 -j MASQUERADE
-------
(grrrr... pas de gras possible dans le code)
(
Si
n'affiche pas la ligne
taper en plus:
)
Test:
OpenVPN ON (IP attribuée : 10.8.0.2)
+ mstsc.exe
Ordinateur: 10.8.0.1
(port d'écoute xRDP standard 3389, non ouvert sur l'extérieu!)
YEEEES, ça passe, connexion OK avec le VPS ! Pas besoin de générer des certificats pour "MS Terminal Server" !
Happy OpenVPN & xRDP !
El Gecko.
#23 Re : Système » VPS inaccessible (réparer grub?) » 08-06-2022 02:00:04
Voici l'erreur obtenue:
Job for networking.service failed because the control process exited with error code.
See "systemctl status networking.service" and "journalctl -xe" for details.
En suivant les indications, j'ai:
(anonymisé xx)
\u25cf networking.service - Raise network interfaces
Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Wed 2022-06-08 01:13:24 CEST; 47s ago
Docs: man:interfaces(5)
Process: 26781 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)
Main PID: 26781 (code=exited, status=1/FAILURE)
Jun 08 01:13:23 vmixxxxxx.contaboserver.net systemd[1]: networking.service: Succeeded.
Jun 08 01:13:23 vmixxxxxx.contaboserver.net systemd[1]: Stopped Raise network interfaces.
Jun 08 01:13:23 vmixxxxxx.contaboserver.net systemd[1]: Starting Raise network interfaces...
Jun 08 01:13:23 vmixxxxxx.contaboserver.net ifup[26781]: /etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /etc/resolvconf/run/resolv.co
Jun 08 01:13:24 vmixxxxxx.contaboserver.net ifup[26781]: RTNETLINK answers: Permission denied
Jun 08 01:13:24 vmixxxxxx.contaboserver.net ifup[26781]: ifup: failed to bring up ens18
Jun 08 01:13:24 vmixxxxxx.contaboserver.net systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
Jun 08 01:13:24 vmixxxxxx.contaboserver.net systemd[1]: networking.service: Failed with result 'exit-code'.
Jun 08 01:13:24 vmixxxxxx.contaboserver.net systemd[1]: Failed to start Raise network interfaces.
-------------------
# journalctl -xe
-- Support: https://www.debian.org/support
--
-- An ExecStart= process belonging to unit networking.service has exited.
--
-- The process' exit code is 'exited' and its exit status is 1.
Jun 08 01:13:24 vmixxxxxx.contaboserver.net systemd[1]: networking.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- The unit networking.service has entered the 'failed' state with result 'exit-code'.
Jun 08 01:13:24 vmixxxxxx.contaboserver.net systemd[1]: Failed to start Raise network interfaces.
-- Subject: A start job for unit networking.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit networking.service has finished with a failure.
--
-- The job identifier is 4364 and the job result is failed.
Jun 08 01:13:31 vmixxxxxx.contaboserver.net kernel: [UFW BLOCK] IN=tun0 OUT= MAC= SRC=10.8.0.2 DST=10.8.0.1 LEN=165 TOS=0x00 PREC=0x00 TTL=128 ID=3424 PROTO=UDP SPT=6353
Jun 08 01:13:37 vmixxxxxx.contaboserver.net kernel: [UFW BLOCK] IN=tun0 OUT= MAC= SRC=10.8.0.2 DST=10.8.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=3426 PROTO=UDP SPT=63540
Jun 08 01:13:57 vmixxxxxx.contaboserver.net kernel: [UFW BLOCK] IN=ens18 OUT= MAC=00:50:56:40:c2:a2:00:08:e3:ff:fd:90:08:00 SRC=198.244.171.193 DST=93.xx.xx.xx LEN=40
Jun 08 01:13:59 vmixxxxxx.contaboserver.net openvpn[550]: TCP connection established with [AF_INET]92.255.85.135:36824
Jun 08 01:13:59 vmixxxxxx.contaboserver.net openvpn[550]: 92.255.85.135:36824 Non-OpenVPN client protocol detected
Jun 08 01:13:59 vmixxxxxx.contaboserver.net openvpn[550]: 92.255.85.135:36824 SIGTERM[soft,port-share-redirect] received, client-instance exiting
Jun 08 01:13:59 vmixxxxxx.contaboserver.net sshd[26981]: Invalid user tomcat from 127.0.0.1 port 51056
Jun 08 01:13:59 vmixxxxxx.contaboserver.net sshd[26981]: pam_unix(sshd:auth): check pass; user unknown
Jun 08 01:13:59 vmixxxxxx.contaboserver.net sshd[26981]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=127.0.0.1
Jun 08 01:14:01 vmixxxxxx.contaboserver.net CRON[26991]: pam_unix(cron:session): session opened for user root by (uid=0)
Jun 08 01:14:01 vmixxxxxx.contaboserver.net CRON[26992]: (root) CMD (sync; echo 3 > /proc/sys/vm/drop_caches)
Jun 08 01:14:01 vmixxxxxx.contaboserver.net kernel: sh (26992): drop_caches: 3
Jun 08 01:14:01 vmixxxxxx.contaboserver.net CRON[26991]: pam_unix(cron:session): session closed for user root
Jun 08 01:14:01 vmixxxxxx.contaboserver.net sshd[26981]: Failed password for invalid user tomcat from 127.0.0.1 port 51056 ssh2
Jun 08 01:14:01 vmixxxxxx.contaboserver.net sshd[26981]: Received disconnect from 127.0.0.1 port 51056:11: Bye Bye [preauth]
Jun 08 01:14:01 vmixxxxxx.contaboserver.net sshd[26981]: Disconnected from invalid user tomcat 127.0.0.1 port 51056 [preauth]
Jun 08 01:14:23 vmixxxxxx.contaboserver.net kernel: [UFW BLOCK] IN=ens18 OUT= MAC=00:50:56:40:c2:a2:00:08:e3:ff:fd:90:08:00 SRC=79.124.62.86 DST=93.xx.xx.xx LEN=40 TOS
Jun 08 01:14:44 vmixxxxxx.contaboserver.net kernel: [UFW BLOCK] IN=ens18 OUT= MAC=00:50:56:40:c2:a2:00:08:e3:ff:fd:90:08:00 SRC=51.89.205.30 DST=93.xx.xx.xx LEN=40 TOS
lines 1286-1322/1322 (END)
"invalid user tomcat" ???
-------------
Ta suggestion me donne :
ifup: configuring interface ens18=ens18 (inet)
/bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/wireless-tools
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
/sbin/ip addr add 93.xx.xx.xx/255.255.255.0 broadcast 93.xx.xx.255 dev ens18 label ens18
RTNETLINK answers: File exists
ifup: failed to bring up ens188
Ca fait quoi au juste ?
Ca tente de démarrer une connexion wifi sur un VPS ?!?
Merci pour ton avis toujours éclairé !
@+
El_Gecko.
#24 Re : Système » VPS inaccessible (réparer grub?) » 07-06-2022 03:04:30
J'ai tenté de repartir d'un ancien fichier interfaces vérolé (et pour cause, mauvais nom d'interface?!?).
C'est fréquent un changement de nom d'interface ???
J'ai remplacé eth0 par ens18 pour obtenir ça :
ne marche pas et renvoie une obscure erreur.
IPV6, j'en ai pas vraiment besoin mais ça fout le bazar:
ERROR: problem running ip6tables
ufw, j'en ai besoin pour comprendre mon soucis de xRDP + OpenVPN... quoique...
@+
El Gecko.
#25 Réseau » [RESOLU] xRDP via OpenVPN » 06-06-2022 17:35:10
- El_Gecko
- Réponses : 2
Sur un VPS sous Debian 10, je ne parviens pas à utiliser xRDP via OpenVPN à partir d'un PC sous Windows 8.1.
Le VPN marche nickel, je me connecte sans soucis (adresse attribuée 10.8.0.2) et je vois bien l'adresse du VPS quand je consulte l'adresse publique détectée sur le web (ex.: showmyip.com).
Le serveur xRDP écoute sur le port standard 3389 que je ne veux surtout pas ouvrir vers le web.
Ports ouvert au niveau firewall du VPS:
- 443 TCP : OpenVPN
- 22443 : SSH
Pour me connecter, je lance mstsc.exe et saisis:
- ordinateur : 10.8.0.1
Au bout de quelques sec. "Le bureau à distance ne peut pas se connecter..."
Windows ping 10.8.0.1 : OK !
Un test de port m'indique qu'il est filtré !?!
Querying target system called: 10.8.0.1
Attempting to resolve IP address to a name...
Failed to resolve IP address to name
querying...
TCP port 3389 (ms-wbt-server service): FILTERED
portqry.exe -n 10.8.0.1 -e 3389 -p TCP exits with return code 0x00000002.
Même punition avec telnet !
L'intérêt de passer par un VPN c'est justement de ne pas avoir à ouvrir ce port, non ?
NB: l'accès via un tunnel SSH établi sous Putty marche nickel (mstsc.exe - ordinateur : localhost:50001 , port local Windows du tunnel débouchant sur le VPS en 93.xx.xx.xx:3389).
Comment régler ce soucis ?
Ouvrir une route ?
Laquelle ?
Merci de m'éclairer sur le sujet.
A votre dispo pour fournir tout complément d'info (route, iptables...).
@+
El Gecko