Je fais des essais pour me connecter via un vpn. Ça marche... sauf que
je n'arrive pas Í faire fonctionner le truc avec iptables, ie. si je
stoppe iptables, ça marche et dès que je le mets en route, je n'ai plus
de connexion internet.
J'ai bien essayé d'autoriser le port 1194 (udp) dans les 2 sens et si je
ne mets que cette règle dans iptables, ça marche encore, mais l'ensemble
de règles en service par défaut bloque la connexion et je ne sais pas
pourquoi.
J'ai essayé de suivre ces indications:
https://arashmilani.com/post?idS
mais, il y a des ambiguͯtés: qu'est-ce que cette interface "tun"?
J'ai essayé tel quel, ça ne marche pas.
J'ai essayé en remplaçant "tun" par "proton0" qui est l'interface créée
par le vpn, sans plus de succès.
Qui a une expérience dans ce domaine et pourrait me fournir quelques
lumières sur la manièree de procéder?
Peut-être faut-il me mettre au goÍ»t du jour et remplacer iptables par
nftables?
Question subsidiaire: quels vpn utiliser? Je fais des essais avec
protonvpn qui offre une possibilité gratuite, mais n'y a-t-il pas des
limitations Í cette version gratuite qui coincerait mes essais?
Merci pour toute aide.
--
François Patte
Université Paris Descartes
François Patte , dans le message <sv80e9$7i5$, a écrit :
mais, il y a des ambiguͯtés: qu'est-ce que cette interface "tun"?
C'est le nom par défaut sous Linux pour les interfaces réseau virtuelles logicielles.
Question subsidiaire: quels vpn utiliser?
Question préalable : pourquoi utiliser un VPN ?
Pascal Hambourg
Le 24/02/2022 Í 14:15, François Patte a écrit :
J'ai bien essayé d'autoriser le port 1194 (udp) dans les 2 sens et si je ne mets que cette règle dans iptables, ça marche encore, mais l'ensemble de règles en service par défaut bloque la connexion et je ne sais pas pourquoi.
Et nous n'aurons aucune chance de te dire pourquoi si tu ne les montres pas.
Le 24/02/2022 Í 14:15, François Patte a écrit :
J'ai bien essayé d'autoriser le port 1194 (udp) dans les 2 sens et si je
ne mets que cette règle dans iptables, ça marche encore, mais l'ensemble
de règles en service par défaut bloque la connexion et je ne sais pas
pourquoi.
Et nous n'aurons aucune chance de te dire pourquoi si tu ne les montres pas.
J'ai bien essayé d'autoriser le port 1194 (udp) dans les 2 sens et si je ne mets que cette règle dans iptables, ça marche encore, mais l'ensemble de règles en service par défaut bloque la connexion et je ne sais pas pourquoi.
Et nous n'aurons aucune chance de te dire pourquoi si tu ne les montres pas.
Fran=c3=a7ois Patte
Le 24/02/2022 Í 17:31, Nicolas George a écrit :
François Patte , dans le message <sv80e9$7i5$, a écrit :
mais, il y a des ambiguͯtés: qu'est-ce que cette interface "tun"?
C'est le nom par défaut sous Linux pour les interfaces réseau virtuelles logicielles.
Oui, je viens de trouver dans les fichiers qui viennent avec l'installation d'openvpn des tas de fichiers d'exemples de configuration et, parmi eux, un qui concerne le firewall avec iptables... Je vais essayer de comprendre!
Question subsidiaire: quels vpn utiliser?
Question préalable : pourquoi utiliser un VPN ?
Relations inter-universitaires... Le cnrs nous oblige Í avoir des partitions chiffrées alors, pourquoi pas des connexions pour tromper l'ennemi. Je n'y connais rien alors je cherche Í m'entrainer pour le jour o͹... -- François Patte Université Paris Descartes
Le 24/02/2022 Í 17:31, Nicolas George a écrit :
François Patte , dans le message <sv80e9$7i5$1@dont-email.me>, a écrit :
mais, il y a des ambiguͯtés: qu'est-ce que cette interface "tun"?
C'est le nom par défaut sous Linux pour les interfaces réseau virtuelles
logicielles.
Oui, je viens de trouver dans les fichiers qui viennent avec
l'installation d'openvpn des tas de fichiers d'exemples de configuration
et, parmi eux, un qui concerne le firewall avec iptables... Je vais
essayer de comprendre!
Question subsidiaire: quels vpn utiliser?
Question préalable : pourquoi utiliser un VPN ?
Relations inter-universitaires... Le cnrs nous oblige Í avoir des
partitions chiffrées alors, pourquoi pas des connexions pour tromper
l'ennemi. Je n'y connais rien alors je cherche Í m'entrainer pour le
jour o͹...
François Patte , dans le message <sv80e9$7i5$, a écrit :
mais, il y a des ambiguͯtés: qu'est-ce que cette interface "tun"?
C'est le nom par défaut sous Linux pour les interfaces réseau virtuelles logicielles.
Oui, je viens de trouver dans les fichiers qui viennent avec l'installation d'openvpn des tas de fichiers d'exemples de configuration et, parmi eux, un qui concerne le firewall avec iptables... Je vais essayer de comprendre!
Question subsidiaire: quels vpn utiliser?
Question préalable : pourquoi utiliser un VPN ?
Relations inter-universitaires... Le cnrs nous oblige Í avoir des partitions chiffrées alors, pourquoi pas des connexions pour tromper l'ennemi. Je n'y connais rien alors je cherche Í m'entrainer pour le jour o͹... -- François Patte Université Paris Descartes
Fran=c3=a7ois Patte
Le 24/02/2022 Í 22:22, Pascal Hambourg a écrit :
Le 24/02/2022 Í 14:15, François Patte a écrit :
J'ai bien essayé d'autoriser le port 1194 (udp) dans les 2 sens et si je ne mets que cette règle dans iptables, ça marche encore, mais l'ensemble de règles en service par défaut bloque la connexion et je ne sais pas pourquoi.
Et nous n'aurons aucune chance de te dire pourquoi si tu ne les montres pas.
Oui oui, je me doutais bien d'une réponse en ce sens, mais voilÍ , c'est un vieux script du temps o͹ les boxes n'existaient pas et je distribuais internet chez moi Í partir d'un modem... Au fil des années, j'ai adapté le script pour essayer de ne conserver que ce qui m'est indispensable, mais j'avoue qu'il ne doit pas être jojo et j'ai honte de le montrer avant de l'avoir examiné en détail (le temps... ) Mais bon, je pose cette question pour voir s'il n'y aurait pas des solutions que je puisse adapter... Les pistes que j'ai pu consulter sur internet sont assez évasives sur la question. -- François Patte Université Paris Descartes
Le 24/02/2022 Í 22:22, Pascal Hambourg a écrit :
Le 24/02/2022 Í 14:15, François Patte a écrit :
J'ai bien essayé d'autoriser le port 1194 (udp) dans les 2 sens et si
je ne mets que cette règle dans iptables, ça marche encore, mais
l'ensemble de règles en service par défaut bloque la connexion et je
ne sais pas pourquoi.
Et nous n'aurons aucune chance de te dire pourquoi si tu ne les montres
pas.
Oui oui, je me doutais bien d'une réponse en ce sens, mais voilÍ , c'est
un vieux script du temps o͹ les boxes n'existaient pas et je distribuais
internet chez moi Í partir d'un modem... Au fil des années, j'ai adapté
le script pour essayer de ne conserver que ce qui m'est indispensable,
mais j'avoue qu'il ne doit pas être jojo et j'ai honte de le montrer
avant de l'avoir examiné en détail (le temps... )
Mais bon, je pose cette question pour voir s'il n'y aurait pas des
solutions que je puisse adapter... Les pistes que j'ai pu consulter sur
internet sont assez évasives sur la question.
J'ai bien essayé d'autoriser le port 1194 (udp) dans les 2 sens et si je ne mets que cette règle dans iptables, ça marche encore, mais l'ensemble de règles en service par défaut bloque la connexion et je ne sais pas pourquoi.
Et nous n'aurons aucune chance de te dire pourquoi si tu ne les montres pas.
Oui oui, je me doutais bien d'une réponse en ce sens, mais voilÍ , c'est un vieux script du temps o͹ les boxes n'existaient pas et je distribuais internet chez moi Í partir d'un modem... Au fil des années, j'ai adapté le script pour essayer de ne conserver que ce qui m'est indispensable, mais j'avoue qu'il ne doit pas être jojo et j'ai honte de le montrer avant de l'avoir examiné en détail (le temps... ) Mais bon, je pose cette question pour voir s'il n'y aurait pas des solutions que je puisse adapter... Les pistes que j'ai pu consulter sur internet sont assez évasives sur la question. -- François Patte Université Paris Descartes
Nicolas George
François Patte , dans le message <sv8u3i$l8c$, a écrit :
Question préalable : pourquoi utiliser un VPN ?
Relations inter-universitaires... Le cnrs nous oblige Í avoir des partitions chiffrées alors, pourquoi pas des connexions pour tromper l'ennemi. Je n'y connais rien alors je cherche Í m'entrainer pour le jour o͹...
Alors tu perds ton temps : si le CNRS impose un VPN, ce sera avec son propre serveur, pas avec un opérateur privé douteux.
François Patte , dans le message <sv8u3i$l8c$1@dont-email.me>, a écrit :
Question préalable : pourquoi utiliser un VPN ?
Relations inter-universitaires... Le cnrs nous oblige Í avoir des
partitions chiffrées alors, pourquoi pas des connexions pour tromper
l'ennemi. Je n'y connais rien alors je cherche Í m'entrainer pour le
jour o͹...
Alors tu perds ton temps : si le CNRS impose un VPN, ce sera avec son propre
serveur, pas avec un opérateur privé douteux.
François Patte , dans le message <sv8u3i$l8c$, a écrit :
Question préalable : pourquoi utiliser un VPN ?
Relations inter-universitaires... Le cnrs nous oblige Í avoir des partitions chiffrées alors, pourquoi pas des connexions pour tromper l'ennemi. Je n'y connais rien alors je cherche Í m'entrainer pour le jour o͹...
Alors tu perds ton temps : si le CNRS impose un VPN, ce sera avec son propre serveur, pas avec un opérateur privé douteux.
Fran=c3=a7ois Patte
Le 24/02/2022 Í 23:42, Nicolas George a écrit :
François Patte , dans le message <sv8u3i$l8c$, a écrit :
Question préalable : pourquoi utiliser un VPN ?
Relations inter-universitaires... Le cnrs nous oblige Í avoir des partitions chiffrées alors, pourquoi pas des connexions pour tromper l'ennemi. Je n'y connais rien alors je cherche Í m'entrainer pour le jour o͹...
Alors tu perds ton temps : si le CNRS impose un VPN, ce sera avec son propre serveur, pas avec un opérateur privé douteux.
Sans doute, mais ne puis-je voir comment ça se configure avant?
-- François Patte Université Paris Descartes
Le 24/02/2022 Í 23:42, Nicolas George a écrit :
François Patte , dans le message <sv8u3i$l8c$1@dont-email.me>, a écrit :
Question préalable : pourquoi utiliser un VPN ?
Relations inter-universitaires... Le cnrs nous oblige Í avoir des
partitions chiffrées alors, pourquoi pas des connexions pour tromper
l'ennemi. Je n'y connais rien alors je cherche Í m'entrainer pour le
jour o͹...
Alors tu perds ton temps : si le CNRS impose un VPN, ce sera avec son propre
serveur, pas avec un opérateur privé douteux.
Sans doute, mais ne puis-je voir comment ça se configure avant?
François Patte , dans le message <sv8u3i$l8c$, a écrit :
Question préalable : pourquoi utiliser un VPN ?
Relations inter-universitaires... Le cnrs nous oblige Í avoir des partitions chiffrées alors, pourquoi pas des connexions pour tromper l'ennemi. Je n'y connais rien alors je cherche Í m'entrainer pour le jour o͹...
Alors tu perds ton temps : si le CNRS impose un VPN, ce sera avec son propre serveur, pas avec un opérateur privé douteux.
Sans doute, mais ne puis-je voir comment ça se configure avant?
-- François Patte Université Paris Descartes
Nicolas George
François Patte , dans le message <sv9225$fh8$, a écrit :
Sans doute, mais ne puis-je voir comment ça se configure avant?
Seulement si tu sais déjÍ ce qu'ils vont utiliser.
François Patte , dans le message <sv9225$fh8$1@dont-email.me>, a écrit :
Sans doute, mais ne puis-je voir comment ça se configure avant?
Seulement si tu sais déjÍ ce qu'ils vont utiliser.
François Patte , dans le message <sv9225$fh8$, a écrit :
Sans doute, mais ne puis-je voir comment ça se configure avant?
Seulement si tu sais déjÍ ce qu'ils vont utiliser.
Marc SCHAEFER
François Patte wrote:
J'ai bien essayé d'autoriser le port 1194 (udp) dans les 2 sens et si je ne mets que cette règle dans iptables, ça marche encore, mais l'ensemble de règles en service par défaut bloque la connexion et je ne sais pas pourquoi.
Je pense que la plupart des interventions du fil font sens: il faut d'abord déterminer quel protocole de VPN et/ou quel fournisseur de VPN sera imposé par votre institution, et si elle vous fournit des scripts automatisés ou non. Toutefois, pour répondre un peu plus concrètement Í votre questions intéressantes, il y a plusieurs aspects: 1) tout d'abord, le protocole de VPN doit pouvoir fonctionner par défaut, sans modifier le firewall: Etant donné que le client que vous lancez va intier un flux UDP vers l'extérieur (comme vous le dites, le port 1194/UDP est courant avec OpenVPN), il est très probable que même si le script de firewall de Linux qui est préconfiguré sur votre machine (par qui? la distribution?) est très strict, il laissera le trafic passer, en particulier si vous ajoutez dans la config une sorte de `keep-alive' pour maintenir le flux régulièrement, par exemple avec OpenVPN: ping 10 Sinon, vous aurez des sessions qui coincent après un `certain' temps (sans trafic). Un autre problème qui peut arriver est si le client est sur une liaison Internet dont l'adresse publique peut changer, dans ce cas, le serveur (qui lui est supposé avoir une adresse fixe et un firewall autorisant les flux entrants) devrait avoir l'option float. 2) ensuite, les datagrammes doivent pouvoir circuler de l'interface de VPN (tunnel) vers vos autres interfaces réseaux sans encombre: LÍ , par contre, la politique par défaut de votre préconfiguration de firewall pourrait être stricte. Dans ce cas, il faut réfléchir Í ce qui est nécessaire (p.ex, utiliser le VPN uniquement pour sortir, mais ne pas autoriser de création de nouveaux flux UDP ou de connexions TCP par l'extérieur). Dans ce cas, vous pourriez faire quelque chose d'assez universel, mais pas forcément très sécurisé, comme: # autoriser la création de nouveaux flux ou connexions # depuis la machine locale, sortant par le VPN iptables -A OUTPUT -o tun0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT # n'accepter que les réponses directes, voire # liées (!) iptables -A INPUT -i tun0 -m state --state ESTABLISHED,RELATED -j ACCEPT # on suppose une policy DROP sinon, et aussi qu'il # n'y a pas de règle DROP Í la fin des tables # (sinon utiliser -I) Pour rendre cela plus générique par rapport aux noms des interfaces, notamment du VPN, cela peut se faire dans les scripts up/down d'OpenVPN. 3) NAT ou pas NAT: Si ce n'est que la machine locale qui produit des flux vers le VPN, alors l'adresse IP du tunnel de votre cÍ´té sera utilisée, on supposera alors que c'est le serveur de VPN qui l'a configurée et qu'elle est soit publique, soit que le serveur fait le NAT approprié. Sinon, le point 2 est Í revoir (tables FORWARD) et du NAT peut être nécessaire. 4) il y a encore la question du routage: Voulez-vous que seul un sous-réseau routé spécifiquement passe par le VPN, ou tout le trafic? Dans ce dernier cas, il y a le problème de la poule et de l'oeuf: changer la route par défaut vers l'interface du VPN nécessitera une règle plus précise pour pouvoir quand même atteindre le serveur de VPN par l'interface originale. En bref, si je pense que c'est toujours intéressant d'expérimenter, il faut toutefois avouer que c'est assez compliqué de se lancer lÍ -dedans, a fortiori si tout Í coup l'institution choisit un autre outil.
François Patte <francois.patte@mi.parisdescartes.fr> wrote:
J'ai bien essayé d'autoriser le port 1194 (udp) dans les 2 sens et si je
ne mets que cette règle dans iptables, ça marche encore, mais l'ensemble
de règles en service par défaut bloque la connexion et je ne sais pas
pourquoi.
Je pense que la plupart des interventions du fil font sens: il faut
d'abord déterminer quel protocole de VPN et/ou quel fournisseur de VPN
sera imposé par votre institution, et si elle vous fournit des scripts
automatisés ou non.
Toutefois, pour répondre un peu plus concrètement Í votre questions
intéressantes, il y a plusieurs aspects:
1) tout d'abord, le protocole de VPN doit pouvoir fonctionner par
défaut, sans modifier le firewall:
Etant donné que le client que vous lancez va intier un flux UDP
vers l'extérieur (comme vous le dites, le port 1194/UDP est
courant avec OpenVPN), il est très probable que même si le
script de firewall de Linux qui est préconfiguré sur votre
machine (par qui? la distribution?) est très strict, il
laissera le trafic passer, en particulier si vous ajoutez
dans la config une sorte de `keep-alive' pour maintenir
le flux régulièrement, par exemple avec OpenVPN:
ping 10
Sinon, vous aurez des sessions qui coincent après un
`certain' temps (sans trafic).
Un autre problème qui peut arriver est si le client est sur une
liaison Internet dont l'adresse publique peut changer, dans ce cas,
le serveur (qui lui est supposé avoir une adresse fixe et un firewall
autorisant les flux entrants) devrait avoir l'option float.
2) ensuite, les datagrammes doivent pouvoir circuler de l'interface
de VPN (tunnel) vers vos autres interfaces réseaux sans encombre:
LÍ , par contre, la politique par défaut de votre préconfiguration
de firewall pourrait être stricte.
Dans ce cas, il faut réfléchir Í ce qui est nécessaire (p.ex,
utiliser le VPN uniquement pour sortir, mais ne pas autoriser
de création de nouveaux flux UDP ou de connexions TCP par
l'extérieur).
Dans ce cas, vous pourriez faire quelque chose d'assez
universel, mais pas forcément très sécurisé, comme:
# autoriser la création de nouveaux flux ou connexions
# depuis la machine locale, sortant par le VPN
iptables -A OUTPUT
-o tun0
-m state --state NEW,ESTABLISHED,RELATED
-j ACCEPT
# n'accepter que les réponses directes, voire
# liées (!)
iptables -A INPUT
-i tun0
-m state --state ESTABLISHED,RELATED
-j ACCEPT
# on suppose une policy DROP sinon, et aussi qu'il
# n'y a pas de règle DROP Í la fin des tables
# (sinon utiliser -I)
Pour rendre cela plus générique par rapport aux noms des
interfaces, notamment du VPN, cela peut se faire dans les
scripts up/down d'OpenVPN.
3) NAT ou pas NAT:
Si ce n'est que la machine locale qui produit des flux vers
le VPN, alors l'adresse IP du tunnel de votre cÍ´té sera
utilisée, on supposera alors que c'est le serveur de VPN
qui l'a configurée et qu'elle est soit publique, soit que
le serveur fait le NAT approprié.
Sinon, le point 2 est Í revoir (tables FORWARD) et du NAT
peut être nécessaire.
4) il y a encore la question du routage:
Voulez-vous que seul un sous-réseau routé spécifiquement passe
par le VPN, ou tout le trafic? Dans ce dernier cas, il y a le
problème de la poule et de l'oeuf: changer la route par défaut
vers l'interface du VPN nécessitera une règle plus précise
pour pouvoir quand même atteindre le serveur de VPN par
l'interface originale.
En bref, si je pense que c'est toujours intéressant d'expérimenter,
il faut toutefois avouer que c'est assez compliqué de se lancer
lÍ -dedans, a fortiori si tout Í coup l'institution choisit un autre
outil.
J'ai bien essayé d'autoriser le port 1194 (udp) dans les 2 sens et si je ne mets que cette règle dans iptables, ça marche encore, mais l'ensemble de règles en service par défaut bloque la connexion et je ne sais pas pourquoi.
Je pense que la plupart des interventions du fil font sens: il faut d'abord déterminer quel protocole de VPN et/ou quel fournisseur de VPN sera imposé par votre institution, et si elle vous fournit des scripts automatisés ou non. Toutefois, pour répondre un peu plus concrètement Í votre questions intéressantes, il y a plusieurs aspects: 1) tout d'abord, le protocole de VPN doit pouvoir fonctionner par défaut, sans modifier le firewall: Etant donné que le client que vous lancez va intier un flux UDP vers l'extérieur (comme vous le dites, le port 1194/UDP est courant avec OpenVPN), il est très probable que même si le script de firewall de Linux qui est préconfiguré sur votre machine (par qui? la distribution?) est très strict, il laissera le trafic passer, en particulier si vous ajoutez dans la config une sorte de `keep-alive' pour maintenir le flux régulièrement, par exemple avec OpenVPN: ping 10 Sinon, vous aurez des sessions qui coincent après un `certain' temps (sans trafic). Un autre problème qui peut arriver est si le client est sur une liaison Internet dont l'adresse publique peut changer, dans ce cas, le serveur (qui lui est supposé avoir une adresse fixe et un firewall autorisant les flux entrants) devrait avoir l'option float. 2) ensuite, les datagrammes doivent pouvoir circuler de l'interface de VPN (tunnel) vers vos autres interfaces réseaux sans encombre: LÍ , par contre, la politique par défaut de votre préconfiguration de firewall pourrait être stricte. Dans ce cas, il faut réfléchir Í ce qui est nécessaire (p.ex, utiliser le VPN uniquement pour sortir, mais ne pas autoriser de création de nouveaux flux UDP ou de connexions TCP par l'extérieur). Dans ce cas, vous pourriez faire quelque chose d'assez universel, mais pas forcément très sécurisé, comme: # autoriser la création de nouveaux flux ou connexions # depuis la machine locale, sortant par le VPN iptables -A OUTPUT -o tun0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT # n'accepter que les réponses directes, voire # liées (!) iptables -A INPUT -i tun0 -m state --state ESTABLISHED,RELATED -j ACCEPT # on suppose une policy DROP sinon, et aussi qu'il # n'y a pas de règle DROP Í la fin des tables # (sinon utiliser -I) Pour rendre cela plus générique par rapport aux noms des interfaces, notamment du VPN, cela peut se faire dans les scripts up/down d'OpenVPN. 3) NAT ou pas NAT: Si ce n'est que la machine locale qui produit des flux vers le VPN, alors l'adresse IP du tunnel de votre cÍ´té sera utilisée, on supposera alors que c'est le serveur de VPN qui l'a configurée et qu'elle est soit publique, soit que le serveur fait le NAT approprié. Sinon, le point 2 est Í revoir (tables FORWARD) et du NAT peut être nécessaire. 4) il y a encore la question du routage: Voulez-vous que seul un sous-réseau routé spécifiquement passe par le VPN, ou tout le trafic? Dans ce dernier cas, il y a le problème de la poule et de l'oeuf: changer la route par défaut vers l'interface du VPN nécessitera une règle plus précise pour pouvoir quand même atteindre le serveur de VPN par l'interface originale. En bref, si je pense que c'est toujours intéressant d'expérimenter, il faut toutefois avouer que c'est assez compliqué de se lancer lÍ -dedans, a fortiori si tout Í coup l'institution choisit un autre outil.
Pat Pato
Le Thu, 24 Feb 2022 22:52:54 +0100, François Patte a écrit :
Le 24/02/2022 Í 22:22, Pascal Hambourg a écrit :
Le 24/02/2022 Í 14:15, François Patte a écrit :
J'ai bien essayé d'autoriser le port 1194 (udp) dans les 2 sens et si je ne mets que cette règle dans iptables, ça marche encore, mais l'ensemble de règles en service par défaut bloque la connexion et je ne sais pas pourquoi.
Et nous n'aurons aucune chance de te dire pourquoi si tu ne les montres pas.
Oui oui, je me doutais bien d'une réponse en ce sens, mais voilÍ , c'est un vieux script du temps o͹ les boxes n'existaient pas et je distribuais internet chez moi Í partir d'un modem... Au fil des années, j'ai adapté le script pour essayer de ne conserver que ce qui m'est indispensable, mais j'avoue qu'il ne doit pas être jojo et j'ai honte de le montrer avant de l'avoir examiné en détail (le temps... ) Mais bon, je pose cette question pour voir s'il n'y aurait pas des solutions que je puisse adapter... Les pistes que j'ai pu consulter sur internet sont assez évasives sur la question.
Bonjour, Je regrette pour ma part que vousn'ayez pas explicité davantage. les règles qu(IP tables affiche(nt) par défaut pourraient être montrées en réponse Í une sollicitation et même simplement parce qu'elles éclairent les points de vue; cela est mon point de vue. Merci Patrick
Le Thu, 24 Feb 2022 22:52:54 +0100,
François Patte <francois.patte@mi.parisdescartes.fr> a écrit :
Le 24/02/2022 Í 22:22, Pascal Hambourg a écrit :
> Le 24/02/2022 Í 14:15, François Patte a écrit :
>>
>> J'ai bien essayé d'autoriser le port 1194 (udp) dans les 2 sens et
>> si je ne mets que cette règle dans iptables, ça marche encore,
>> mais l'ensemble de règles en service par défaut bloque la
>> connexion et je ne sais pas pourquoi.
>
> Et nous n'aurons aucune chance de te dire pourquoi si tu ne les
> montres pas.
Oui oui, je me doutais bien d'une réponse en ce sens, mais voilÍ ,
c'est un vieux script du temps o͹ les boxes n'existaient pas et je
distribuais internet chez moi Í partir d'un modem... Au fil des
années, j'ai adapté le script pour essayer de ne conserver que ce qui
m'est indispensable, mais j'avoue qu'il ne doit pas être jojo et j'ai
honte de le montrer avant de l'avoir examiné en détail (le temps... )
Mais bon, je pose cette question pour voir s'il n'y aurait pas des
solutions que je puisse adapter... Les pistes que j'ai pu consulter
sur internet sont assez évasives sur la question.
Bonjour,
Je regrette pour ma part que vousn'ayez pas explicité
davantage. les règles qu(IP tables affiche(nt) par défaut pourraient
être montrées en réponse Í une sollicitation et même simplement parce
qu'elles éclairent les points de vue; cela est mon point de vue.
Le Thu, 24 Feb 2022 22:52:54 +0100, François Patte a écrit :
Le 24/02/2022 Í 22:22, Pascal Hambourg a écrit :
Le 24/02/2022 Í 14:15, François Patte a écrit :
J'ai bien essayé d'autoriser le port 1194 (udp) dans les 2 sens et si je ne mets que cette règle dans iptables, ça marche encore, mais l'ensemble de règles en service par défaut bloque la connexion et je ne sais pas pourquoi.
Et nous n'aurons aucune chance de te dire pourquoi si tu ne les montres pas.
Oui oui, je me doutais bien d'une réponse en ce sens, mais voilÍ , c'est un vieux script du temps o͹ les boxes n'existaient pas et je distribuais internet chez moi Í partir d'un modem... Au fil des années, j'ai adapté le script pour essayer de ne conserver que ce qui m'est indispensable, mais j'avoue qu'il ne doit pas être jojo et j'ai honte de le montrer avant de l'avoir examiné en détail (le temps... ) Mais bon, je pose cette question pour voir s'il n'y aurait pas des solutions que je puisse adapter... Les pistes que j'ai pu consulter sur internet sont assez évasives sur la question.
Bonjour, Je regrette pour ma part que vousn'ayez pas explicité davantage. les règles qu(IP tables affiche(nt) par défaut pourraient être montrées en réponse Í une sollicitation et même simplement parce qu'elles éclairent les points de vue; cela est mon point de vue. Merci Patrick
Fran=c3=a7ois Patte
Le 25/02/2022 Í 08:39, Marc SCHAEFER a écrit :
François Patte wrote:
J'ai bien essayé d'autoriser le port 1194 (udp) dans les 2 sens et si je ne mets que cette règle dans iptables, ça marche encore, mais l'ensemble de règles en service par défaut bloque la connexion et je ne sais pas pourquoi.
Je pense que la plupart des interventions du fil font sens: il faut d'abord déterminer quel protocole de VPN et/ou quel fournisseur de VPN sera imposé par votre institution, et si elle vous fournit des scripts automatisés ou non. Toutefois, pour répondre un peu plus concrètement Í votre questions intéressantes, il y a plusieurs aspects:
<couic> Merci pour ces explications... En les lisant et avec l'aide des fichiers de doc fournis par le paquet openvpn sur ma distribution, j'arrive Í faire fonctionner un vpn tout en gardant iptables "vivant", j'ai ajouté au script iptables définissant les règles du parefeu les règles suivantes: $IPTABLES -A INPUT -i tun0 -j LOG_ACCEPT $IPTABLES -A FORWARD -i tun0 -j LOG_ACCEPT $IPTABLES -A OUTPUT -o tun0 -j LOG_ACCEPT $IPTABLES -A OUTPUT -m state --state NEW -o $IFACE_EXTERNE -j ACCEPT $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -m state --state NEW -o $IFACE_EXTERNE -j ACCEPT $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT # Masquerade local subnet $IPTABLES -t nat -A POSTROUTING -s $PRIVATE -o $IFACE_EXTERNE -j MASQUERADE o͹ $IPTABLES = /sbin/iptables $IFACE_EXTERNE = $( ip route show | grep ^default | cut -d' ' -f5 ) $PRIVATE = 10.0.0.0/24 Je ne sais pas encore si ces règles sont "minimales"... Í tester. Ni si ça fonctionne avec un autre vpn que j'utilise pour le test. Merci -- François Patte Université Paris Descartes
Le 25/02/2022 Í 08:39, Marc SCHAEFER a écrit :
François Patte <francois.patte@mi.parisdescartes.fr> wrote:
J'ai bien essayé d'autoriser le port 1194 (udp) dans les 2 sens et si je
ne mets que cette règle dans iptables, ça marche encore, mais l'ensemble
de règles en service par défaut bloque la connexion et je ne sais pas
pourquoi.
Je pense que la plupart des interventions du fil font sens: il faut
d'abord déterminer quel protocole de VPN et/ou quel fournisseur de VPN
sera imposé par votre institution, et si elle vous fournit des scripts
automatisés ou non.
Toutefois, pour répondre un peu plus concrètement Í votre questions
intéressantes, il y a plusieurs aspects:
<couic>
Merci pour ces explications... En les lisant et avec l'aide des fichiers
de doc fournis par le paquet openvpn sur ma distribution, j'arrive Í
faire fonctionner un vpn tout en gardant iptables "vivant", j'ai ajouté
au script iptables définissant les règles du parefeu les règles suivantes:
$IPTABLES -A INPUT -i tun0 -j LOG_ACCEPT
$IPTABLES -A FORWARD -i tun0 -j LOG_ACCEPT
$IPTABLES -A OUTPUT -o tun0 -j LOG_ACCEPT
$IPTABLES -A OUTPUT -m state --state NEW -o $IFACE_EXTERNE -j ACCEPT
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -m state --state NEW -o $IFACE_EXTERNE -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# Masquerade local subnet
$IPTABLES -t nat -A POSTROUTING -s $PRIVATE -o $IFACE_EXTERNE -j MASQUERADE
J'ai bien essayé d'autoriser le port 1194 (udp) dans les 2 sens et si je ne mets que cette règle dans iptables, ça marche encore, mais l'ensemble de règles en service par défaut bloque la connexion et je ne sais pas pourquoi.
Je pense que la plupart des interventions du fil font sens: il faut d'abord déterminer quel protocole de VPN et/ou quel fournisseur de VPN sera imposé par votre institution, et si elle vous fournit des scripts automatisés ou non. Toutefois, pour répondre un peu plus concrètement Í votre questions intéressantes, il y a plusieurs aspects:
<couic> Merci pour ces explications... En les lisant et avec l'aide des fichiers de doc fournis par le paquet openvpn sur ma distribution, j'arrive Í faire fonctionner un vpn tout en gardant iptables "vivant", j'ai ajouté au script iptables définissant les règles du parefeu les règles suivantes: $IPTABLES -A INPUT -i tun0 -j LOG_ACCEPT $IPTABLES -A FORWARD -i tun0 -j LOG_ACCEPT $IPTABLES -A OUTPUT -o tun0 -j LOG_ACCEPT $IPTABLES -A OUTPUT -m state --state NEW -o $IFACE_EXTERNE -j ACCEPT $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -m state --state NEW -o $IFACE_EXTERNE -j ACCEPT $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT # Masquerade local subnet $IPTABLES -t nat -A POSTROUTING -s $PRIVATE -o $IFACE_EXTERNE -j MASQUERADE o͹ $IPTABLES = /sbin/iptables $IFACE_EXTERNE = $( ip route show | grep ^default | cut -d' ' -f5 ) $PRIVATE = 10.0.0.0/24 Je ne sais pas encore si ces règles sont "minimales"... Í tester. Ni si ça fonctionne avec un autre vpn que j'utilise pour le test. Merci -- François Patte Université Paris Descartes
