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
$IPTABLES -A INPUT -i tun0 -j LOG_ACCEPT $IPTABLES -A FORWARD -i tun0 -j LOG_ACCEPT $IPTABLES -A OUTPUT -o tun0 -j LOG_ACCEPT
Donc, il y a un saut Í LOG_ACCEPT *au début* de votre table, ne connaissant pas ce que fait LOG_ACCEPT, s'il accepte tout, le reste des règles devraient alors être ajoutés en -I.
$IPTABLES -A OUTPUT -m state --state NEW -o $IFACE_EXTERNE -j ACCEPT
Je dirais d'y ajouter ESTABLISHED,RELATED, car tout paquet n'est pas un nouveau flux ni une nouvelle connexion, me semble-t-il.
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.
Vérifier ensuite avec les compteurs (-L) que ces règles sont effectivement utilisées. Et tester des abus.
François Patte <francois.patte@mi.parisdescartes.fr> wrote:
$IPTABLES -A INPUT -i tun0 -j LOG_ACCEPT
$IPTABLES -A FORWARD -i tun0 -j LOG_ACCEPT
$IPTABLES -A OUTPUT -o tun0 -j LOG_ACCEPT
Donc, il y a un saut Í LOG_ACCEPT *au début* de votre table, ne
connaissant pas ce que fait LOG_ACCEPT, s'il accepte tout, le reste des
règles devraient alors être ajoutés en -I.
$IPTABLES -A OUTPUT -m state --state NEW -o $IFACE_EXTERNE -j ACCEPT
Je dirais d'y ajouter ESTABLISHED,RELATED, car tout paquet n'est pas
un nouveau flux ni une nouvelle connexion, me semble-t-il.
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.
Vérifier ensuite avec les compteurs (-L) que ces règles sont
effectivement utilisées. Et tester des abus.
$IPTABLES -A INPUT -i tun0 -j LOG_ACCEPT $IPTABLES -A FORWARD -i tun0 -j LOG_ACCEPT $IPTABLES -A OUTPUT -o tun0 -j LOG_ACCEPT
Donc, il y a un saut Í LOG_ACCEPT *au début* de votre table, ne connaissant pas ce que fait LOG_ACCEPT, s'il accepte tout, le reste des règles devraient alors être ajoutés en -I.
$IPTABLES -A OUTPUT -m state --state NEW -o $IFACE_EXTERNE -j ACCEPT
Je dirais d'y ajouter ESTABLISHED,RELATED, car tout paquet n'est pas un nouveau flux ni une nouvelle connexion, me semble-t-il.
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.
Vérifier ensuite avec les compteurs (-L) que ces règles sont effectivement utilisées. Et tester des abus.
Pascal Hambourg
Le 26/02/2022 Í 16:53, François Patte a écrit :
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
Accepte tout ce qui arrive du VPN Í destination de la machine locale ou d'une machine située derrière. Acceptable si le réseau Í l'autre bout est de confiance, discutable dans le cas contraire (comme internet).
$IPTABLES -A OUTPUT -m state --state NEW -o $IFACE_EXTERNE -j ACCEPT $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Ces règles acceptent non seulement le trafic généré par le VPN mais toute connexion sortante initiée par la machine locale.
$IPTABLES -A FORWARD -m state --state NEW -o $IFACE_EXTERNE -j ACCEPT
Le trafic concerné par cette règle n'a rien Í voir avec le VPN. S'il a vraiment été nécessaire d'ajouter toutes ces règles, je me demande vraiment ce que faisaient les règles existantes.
Le 26/02/2022 Í 16:53, François Patte a écrit :
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
Accepte tout ce qui arrive du VPN Í destination de la machine locale ou
d'une machine située derrière. Acceptable si le réseau Í l'autre bout
est de confiance, discutable dans le cas contraire (comme internet).
$IPTABLES -A OUTPUT -m state --state NEW -o $IFACE_EXTERNE -j ACCEPT
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Ces règles acceptent non seulement le trafic généré par le VPN mais
toute connexion sortante initiée par la machine locale.
$IPTABLES -A FORWARD -m state --state NEW -o $IFACE_EXTERNE -j ACCEPT
Le trafic concerné par cette règle n'a rien Í voir avec le VPN.
S'il a vraiment été nécessaire d'ajouter toutes ces règles, je me
demande vraiment ce que faisaient les règles existantes.
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
Accepte tout ce qui arrive du VPN Í destination de la machine locale ou d'une machine située derrière. Acceptable si le réseau Í l'autre bout est de confiance, discutable dans le cas contraire (comme internet).
$IPTABLES -A OUTPUT -m state --state NEW -o $IFACE_EXTERNE -j ACCEPT $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Ces règles acceptent non seulement le trafic généré par le VPN mais toute connexion sortante initiée par la machine locale.
$IPTABLES -A FORWARD -m state --state NEW -o $IFACE_EXTERNE -j ACCEPT
Le trafic concerné par cette règle n'a rien Í voir avec le VPN. S'il a vraiment été nécessaire d'ajouter toutes ces règles, je me demande vraiment ce que faisaient les règles existantes.
Fran=c3=a7ois Patte
Le 26/02/2022 Í 19:12, Pascal Hambourg a écrit :
Le 26/02/2022 Í 16:53, François Patte a écrit :
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
Accepte tout ce qui arrive du VPN Í destination de la machine locale ou d'une machine située derrière. Acceptable si le réseau Í l'autre bout est de confiance, discutable dans le cas contraire (comme internet).
$IPTABLES -A OUTPUT -m state --state NEW -o $IFACE_EXTERNE -j ACCEPT $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Ces règles acceptent non seulement le trafic généré par le VPN mais toute connexion sortante initiée par la machine locale.
$IPTABLES -A FORWARD -m state --state NEW -o $IFACE_EXTERNE -j ACCEPT
Le trafic concerné par cette règle n'a rien Í voir avec le VPN. S'il a vraiment été nécessaire d'ajouter toutes ces règles, je me demande vraiment ce que faisaient les règles existantes.
Bon, alors finalement, une seule règle suffit! $IPTABLES -A OUTPUT -o tun0 -j ACCEPT Je me demande pourquoi openvpn met toutes ces règles (et d'autres encore) dans ses fichiers d'exemple... -- François Patte Université Paris Descartes
Le 26/02/2022 Í 19:12, Pascal Hambourg a écrit :
Le 26/02/2022 Í 16:53, François Patte a écrit :
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
Accepte tout ce qui arrive du VPN Í destination de la machine locale ou
d'une machine située derrière. Acceptable si le réseau Í l'autre bout
est de confiance, discutable dans le cas contraire (comme internet).
$IPTABLES -A OUTPUT -m state --state NEW -o $IFACE_EXTERNE -j ACCEPT
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Ces règles acceptent non seulement le trafic généré par le VPN mais
toute connexion sortante initiée par la machine locale.
$IPTABLES -A FORWARD -m state --state NEW -o $IFACE_EXTERNE -j ACCEPT
Le trafic concerné par cette règle n'a rien Í voir avec le VPN.
S'il a vraiment été nécessaire d'ajouter toutes ces règles, je me
demande vraiment ce que faisaient les règles existantes.
Bon, alors finalement, une seule règle suffit!
$IPTABLES -A OUTPUT -o tun0 -j ACCEPT
Je me demande pourquoi openvpn met toutes ces règles (et d'autres
encore) dans ses fichiers d'exemple...
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
Accepte tout ce qui arrive du VPN Í destination de la machine locale ou d'une machine située derrière. Acceptable si le réseau Í l'autre bout est de confiance, discutable dans le cas contraire (comme internet).
$IPTABLES -A OUTPUT -m state --state NEW -o $IFACE_EXTERNE -j ACCEPT $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Ces règles acceptent non seulement le trafic généré par le VPN mais toute connexion sortante initiée par la machine locale.
$IPTABLES -A FORWARD -m state --state NEW -o $IFACE_EXTERNE -j ACCEPT
Le trafic concerné par cette règle n'a rien Í voir avec le VPN. S'il a vraiment été nécessaire d'ajouter toutes ces règles, je me demande vraiment ce que faisaient les règles existantes.
Bon, alors finalement, une seule règle suffit! $IPTABLES -A OUTPUT -o tun0 -j ACCEPT Je me demande pourquoi openvpn met toutes ces règles (et d'autres encore) dans ses fichiers d'exemple... -- François Patte Université Paris Descartes
Marc SCHAEFER
François Patte wrote:
Bon, alors finalement, une seule règle suffit! $IPTABLES -A OUTPUT -o tun0 -j ACCEPT Je me demande pourquoi openvpn met toutes ces règles (et d'autres encore) dans ses fichiers d'exemple...
Tout dépend de votre firewall de base, aussi et des politiques. iptables -L iptables -L -t nat # peut-être mieux iptables-save
François Patte <francois.patte@mi.parisdescartes.fr> wrote:
Bon, alors finalement, une seule règle suffit!
$IPTABLES -A OUTPUT -o tun0 -j ACCEPT
Je me demande pourquoi openvpn met toutes ces règles (et d'autres
encore) dans ses fichiers d'exemple...
Tout dépend de votre firewall de base, aussi et des politiques.
Bon, alors finalement, une seule règle suffit! $IPTABLES -A OUTPUT -o tun0 -j ACCEPT Je me demande pourquoi openvpn met toutes ces règles (et d'autres encore) dans ses fichiers d'exemple...
Tout dépend de votre firewall de base, aussi et des politiques. iptables -L iptables -L -t nat # peut-être mieux iptables-save
Fran=c3=a7ois Patte
Le 27/02/2022 Í 12:18, Marc SCHAEFER a écrit :
François Patte wrote:
Bon, alors finalement, une seule règle suffit! $IPTABLES -A OUTPUT -o tun0 -j ACCEPT Je me demande pourquoi openvpn met toutes ces règles (et d'autres encore) dans ses fichiers d'exemple...
Tout dépend de votre firewall de base, aussi et des politiques. iptables -L
(J'ai masqué l'adresse du réseau autorisé Í utiliser ssh) Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT icmp -- anywhere anywhere icmp echo-reply ACCEPT icmp -- anywhere anywhere icmp destination-unreachable ACCEPT tcp -- anywhere anywhere tcp dpt:auth ACCEPT tcp -- anywhere anywhere tcp spt:auth ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT tcp -- anywhere anywhere tcp dpt:netbios-ssn ACCEPT tcp -- X.X.X.X/24 anywhere tcp dpt:ssh ACCEPT all -- 192.168.1.0/24 anywhere ACCEPT udp -- anywhere anywhere udp dpt:ipp ACCEPT udp -- anywhere anywhere udp spt:ipp LOG_ACCEPT all -- 10.0.0.0/24 anywhere LOG_DROP all -- anywhere anywhere Chain FORWARD (policy DROP) target prot opt source destination LOG_DROP all -- anywhere anywhere Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT icmp -- anywhere anywhere icmp echo-request ACCEPT icmp -- anywhere anywhere icmp destination-unreachable ACCEPT tcp -- anywhere anywhere tcp dpt:auth ACCEPT tcp -- anywhere anywhere tcp spt:auth ACCEPT all -- anywhere anywhere ctstate ESTABLISHED ACCEPT udp -- anywhere anywhere udp dpt:domain ACCEPT tcp -- anywhere anywhere multiport dports http,https ACCEPT tcp -- anywhere anywhere tcp dpt:imaps ACCEPT udp -- anywhere anywhere udp dpt:ntp ACCEPT tcp -- anywhere X.X.X.X/24 tcp dpt:ssh LOG_ACCEPT udp -- anywhere anywhere udp dpt:openvpn ACCEPT udp -- anywhere anywhere udp dpt:ssdp ACCEPT all -- anywhere 192.168.1.0/24 ACCEPT udp -- anywhere anywhere udp spt:ipp ACCEPT udp -- anywhere anywhere udp dpt:ipp ACCEPT all -- anywhere base-address.mcast.net/24 ACCEPT all -- anywhere anywhere LOG_DROP all -- anywhere anywhere Chain LOG_ACCEPT (2 references) target prot opt source destination LOG all -- anywhere anywhere LOG level warning prefix "[IPTABLES ACCEPT] : " ACCEPT all -- anywhere anywhere Chain LOG_DROP (3 references) target prot opt source destination LOG all -- anywhere anywhere LOG level warning prefix "[IPTABLES DROP] : " DROP all -- anywhere anywhere Reste des mystère (pour moi!): 1- Alors que la doc openvpn dit que les requètes ont lieu vers le port 1194 (udp), quand on lance openvpn, il envoie des requètes vers le port 80, puis 443, puis vers d'autres ports et finit par utiliser le port 1194 et, donc,Í établir la connexion. 2- ipv6: quand on cherche Í savoir (des tas de sites proposent ce service) quel est le numéro ip attribué, on a 2 numéros, un ipv4 (qui correspond Í celui que le vpn octroit) et un ipv6 qui est celui attribué par le fai... ce qui rend suspectes les affirmations de "cacher le numéro ip" des fournisseurs de vpn, On voit ça aussi avec le dns: j'ai autorisé les connection vers le port 53, dans ce cas le serveur dns qui répond est bien celui désigné dans resolv.conf. Si je supprime cette autorisation, le serveur dns qui répond est celui du fai avec son adresse ipv6. -- François Patte Université Paris Descartes
Le 27/02/2022 Í 12:18, Marc SCHAEFER a écrit :
François Patte <francois.patte@mi.parisdescartes.fr> wrote:
Bon, alors finalement, une seule règle suffit!
$IPTABLES -A OUTPUT -o tun0 -j ACCEPT
Je me demande pourquoi openvpn met toutes ces règles (et d'autres
encore) dans ses fichiers d'exemple...
Tout dépend de votre firewall de base, aussi et des politiques.
iptables -L
(J'ai masqué l'adresse du réseau autorisé Í utiliser ssh)
Chain LOG_DROP (3 references)
target prot opt source destination
LOG all -- anywhere anywhere LOG level
warning prefix "[IPTABLES DROP] : "
DROP all -- anywhere anywhere
Reste des mystère (pour moi!):
1- Alors que la doc openvpn dit que les requètes ont lieu vers le port
1194 (udp), quand on lance openvpn, il envoie des requètes vers le port
80, puis 443, puis vers d'autres ports et finit par utiliser le port
1194 et, donc,Í établir la connexion.
2- ipv6: quand on cherche Í savoir (des tas de sites proposent ce
service) quel est le numéro ip attribué, on a 2 numéros, un ipv4 (qui
correspond Í celui que le vpn octroit) et un ipv6 qui est celui attribué
par le fai... ce qui rend suspectes les affirmations de "cacher le
numéro ip" des fournisseurs de vpn,
On voit ça aussi avec le dns: j'ai autorisé les connection vers le port
53, dans ce cas le serveur dns qui répond est bien celui désigné dans
resolv.conf.
Si je supprime cette autorisation, le serveur dns qui répond est celui
du fai avec son adresse ipv6.
Bon, alors finalement, une seule règle suffit! $IPTABLES -A OUTPUT -o tun0 -j ACCEPT Je me demande pourquoi openvpn met toutes ces règles (et d'autres encore) dans ses fichiers d'exemple...
Tout dépend de votre firewall de base, aussi et des politiques. iptables -L
(J'ai masqué l'adresse du réseau autorisé Í utiliser ssh) Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT icmp -- anywhere anywhere icmp echo-reply ACCEPT icmp -- anywhere anywhere icmp destination-unreachable ACCEPT tcp -- anywhere anywhere tcp dpt:auth ACCEPT tcp -- anywhere anywhere tcp spt:auth ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT tcp -- anywhere anywhere tcp dpt:netbios-ssn ACCEPT tcp -- X.X.X.X/24 anywhere tcp dpt:ssh ACCEPT all -- 192.168.1.0/24 anywhere ACCEPT udp -- anywhere anywhere udp dpt:ipp ACCEPT udp -- anywhere anywhere udp spt:ipp LOG_ACCEPT all -- 10.0.0.0/24 anywhere LOG_DROP all -- anywhere anywhere Chain FORWARD (policy DROP) target prot opt source destination LOG_DROP all -- anywhere anywhere Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT icmp -- anywhere anywhere icmp echo-request ACCEPT icmp -- anywhere anywhere icmp destination-unreachable ACCEPT tcp -- anywhere anywhere tcp dpt:auth ACCEPT tcp -- anywhere anywhere tcp spt:auth ACCEPT all -- anywhere anywhere ctstate ESTABLISHED ACCEPT udp -- anywhere anywhere udp dpt:domain ACCEPT tcp -- anywhere anywhere multiport dports http,https ACCEPT tcp -- anywhere anywhere tcp dpt:imaps ACCEPT udp -- anywhere anywhere udp dpt:ntp ACCEPT tcp -- anywhere X.X.X.X/24 tcp dpt:ssh LOG_ACCEPT udp -- anywhere anywhere udp dpt:openvpn ACCEPT udp -- anywhere anywhere udp dpt:ssdp ACCEPT all -- anywhere 192.168.1.0/24 ACCEPT udp -- anywhere anywhere udp spt:ipp ACCEPT udp -- anywhere anywhere udp dpt:ipp ACCEPT all -- anywhere base-address.mcast.net/24 ACCEPT all -- anywhere anywhere LOG_DROP all -- anywhere anywhere Chain LOG_ACCEPT (2 references) target prot opt source destination LOG all -- anywhere anywhere LOG level warning prefix "[IPTABLES ACCEPT] : " ACCEPT all -- anywhere anywhere Chain LOG_DROP (3 references) target prot opt source destination LOG all -- anywhere anywhere LOG level warning prefix "[IPTABLES DROP] : " DROP all -- anywhere anywhere Reste des mystère (pour moi!): 1- Alors que la doc openvpn dit que les requètes ont lieu vers le port 1194 (udp), quand on lance openvpn, il envoie des requètes vers le port 80, puis 443, puis vers d'autres ports et finit par utiliser le port 1194 et, donc,Í établir la connexion. 2- ipv6: quand on cherche Í savoir (des tas de sites proposent ce service) quel est le numéro ip attribué, on a 2 numéros, un ipv4 (qui correspond Í celui que le vpn octroit) et un ipv6 qui est celui attribué par le fai... ce qui rend suspectes les affirmations de "cacher le numéro ip" des fournisseurs de vpn, On voit ça aussi avec le dns: j'ai autorisé les connection vers le port 53, dans ce cas le serveur dns qui répond est bien celui désigné dans resolv.conf. Si je supprime cette autorisation, le serveur dns qui répond est celui du fai avec son adresse ipv6. -- François Patte Université Paris Descartes
Marc SCHAEFER
François Patte wrote:
iptables -L
et avec -v on voit les compteurs, de mémoire, comme ça on peut voir si une règle sert.
Chain INPUT (policy DROP)
INPUT, OUTPUT et FORWARD en DROP est effectivement une bonne chose.
LOG_ACCEPT all -- 10.0.0.0/24 anywhere
curieux, c'est justifié?
LOG_DROP all -- anywhere anywhere
Ca cela complémente, en bas de queue, la policy DROP en faisant en plus un LOG.
1- Alors que la doc openvpn dit que les requètes ont lieu vers le port 1194 (udp), quand on lance openvpn, il envoie des requètes vers le port 80, puis 443, puis vers d'autres ports et finit par utiliser le port 1194 et, donc,Í établir la connexion.
Curieux, ça ça ressemblerait au setup p.ex. d'un VPN Cisco (qui passe d'abord par le web puis fait du GRE, de mémoire).
2- ipv6: quand on cherche Í savoir (des tas de sites proposent ce service) quel est le numéro ip attribué, on a 2 numéros, un ipv4 (qui correspond Í celui que le vpn octroit) et un ipv6 qui est celui attribué par le fai... ce qui rend suspectes les affirmations de "cacher le numéro ip" des fournisseurs de vpn,
Parler d'adresse plutÍ´t que de numéro est plus clair. Il se peut que votre fournisseur de VPN ne supporte pas l'IPv6 ou qu'il faille l'activer. Effectivement, dans ce cas, le trafic v6 ne sera pas via le VPN. Sans support v6 chez le fournisseur VPN, alors désactiver le v6 semble utile, si le VPN est utilisé pour l'anonymisation.
François Patte <francois.patte@mi.parisdescartes.fr> wrote:
iptables -L
et avec -v on voit les compteurs, de mémoire, comme ça on peut voir si
une règle sert.
Chain INPUT (policy DROP)
INPUT, OUTPUT et FORWARD en DROP est effectivement une bonne chose.
LOG_ACCEPT all -- 10.0.0.0/24 anywhere
curieux, c'est justifié?
LOG_DROP all -- anywhere anywhere
Ca cela complémente, en bas de queue, la policy DROP en faisant en plus
un LOG.
Chain LOG_DROP (3 references)
target prot opt source destination
LOG all -- anywhere anywhere LOG level
warning prefix "[IPTABLES DROP] : "
DROP all -- anywhere anywhere
Les deux chaÍ®nes spécifiques.
1- Alors que la doc openvpn dit que les requètes ont lieu vers le port
1194 (udp), quand on lance openvpn, il envoie des requètes vers le port
80, puis 443, puis vers d'autres ports et finit par utiliser le port
1194 et, donc,Í établir la connexion.
Curieux, ça ça ressemblerait au setup p.ex. d'un VPN Cisco (qui passe
d'abord par le web puis fait du GRE, de mémoire).
2- ipv6: quand on cherche Í savoir (des tas de sites proposent ce
service) quel est le numéro ip attribué, on a 2 numéros, un ipv4 (qui
correspond Í celui que le vpn octroit) et un ipv6 qui est celui attribué
par le fai... ce qui rend suspectes les affirmations de "cacher le
numéro ip" des fournisseurs de vpn,
Parler d'adresse plutÍ´t que de numéro est plus clair.
Il se peut que votre fournisseur de VPN ne supporte pas l'IPv6 ou qu'il
faille l'activer. Effectivement, dans ce cas, le trafic v6 ne sera pas
via le VPN.
Sans support v6 chez le fournisseur VPN, alors désactiver le v6 semble
utile, si le VPN est utilisé pour l'anonymisation.
1- Alors que la doc openvpn dit que les requètes ont lieu vers le port 1194 (udp), quand on lance openvpn, il envoie des requètes vers le port 80, puis 443, puis vers d'autres ports et finit par utiliser le port 1194 et, donc,Í établir la connexion.
Curieux, ça ça ressemblerait au setup p.ex. d'un VPN Cisco (qui passe d'abord par le web puis fait du GRE, de mémoire).
2- ipv6: quand on cherche Í savoir (des tas de sites proposent ce service) quel est le numéro ip attribué, on a 2 numéros, un ipv4 (qui correspond Í celui que le vpn octroit) et un ipv6 qui est celui attribué par le fai... ce qui rend suspectes les affirmations de "cacher le numéro ip" des fournisseurs de vpn,
Parler d'adresse plutÍ´t que de numéro est plus clair. Il se peut que votre fournisseur de VPN ne supporte pas l'IPv6 ou qu'il faille l'activer. Effectivement, dans ce cas, le trafic v6 ne sera pas via le VPN. Sans support v6 chez le fournisseur VPN, alors désactiver le v6 semble utile, si le VPN est utilisé pour l'anonymisation.
