Problèmes courants de migration relatifs à Vyatta 5400
Les sections ci-après décrivent les problèmes ou les changements de comportement courants que vous pouvez rencontrer après la migration depuis une unité Vyatta 5400 vers un dispositif IBM Cloud® Virtual Router Appliance. Dans certains cas, elles proposent des solutions de contournement.
Règle d'état global basée sur une interface pour un pare-feu avec état
Problèmes
Le comportement lors de la définition de "state-of-state policy" pour les pare-feux avec état a changé depuis l'édition 5.1. Dans les versions antérieures à l'édition 5.1, si vous définissiez state -global -state -policy
pour un pare-feu avec état, le dispositif vRouter ajoutait automatiquement une règle Allow
implicite pour la communication en retour de la session.
Depuis l'édition 5.1, vous devez ajouter un paramètre de règle Allow
sur le dispositif IBM Cloud® Virtual Router Appliance. Le paramètre avec état fonctionne pour les interfaces sur les unités Vyatta 5400 et pour les protocoles
sur les unités VRA.
Solutions de contournement
Si la règle firewall-in
est appliquée à une interface d'entrée/interne, vous devez appliquer la règle Firewall-out
sur l'interface de sortie/externe. Sinon, le trafic de retour est supprimé au niveau de l'interface
de sortie/externe.
Activation d'état dans les règles de pare-feu
Problèmes d'activation d'état
Si global-state-policy
n'est pas configuré, ce changement de comportement n'est pas affecté. De plus, si vous utilisez l'option state enable
dans chaque règle au lieu de global-state-policy
, le changement
de comportement n'est pas affecté.
Règle basée sur une zone : traitement local-zone
Problèmes de traitement local-zone
Il n'existe aucune pseudo-interface "local-zone" à affecter à la règle basée sur une zone.
Solutions de contournement de local-zone
Ce comportement peut être simulé en appliquant un pare-feu basé sur une zone à des interfaces physiques et un pare-feu d'interface à l'interface de bouclage. Le pare-feu situé dans l'interface de bouclage filtre tout ce qui rentre et sort à partir du routeur.
Par exemple :
set security zone-policy zone internal default-action 'drop'
set security zone-policy zone internal description 'Private zone'
set security zone-policy zone internal interface 'dp0bond0'
set security zone-policy zone internal to external firewall 'internal-2-external'
set security zone-policy zone internal to ovpn firewall 'internal-2-ovpn'
set security zone-policy zone ovpn default-action 'drop'
set security zone-policy zone ovpn description 'OpenVPN'
set security zone-policy zone ovpn interface 'vtun0'
set security zone-policy zone ovpn to external firewall 'ovpn-2-external'
set security zone-policy zone ovpn to internal firewall 'ovpn-2-internal'
set interfaces loopback lo firewall local 'Local'
set security firewall name ovpn-2-external default-action accept
set security firewall name ovpn-2-internal default-action accept
set security firewall name external-2-ovpn default-action accept
set security firewall name external-2-internal default-action accept
set security firewall name internal-2-external default-action accept
set security firewall name internal-2-ovpn default-action accept
set security firewall name Local default-action 'drop'
set security firewall name Local 'default-log'
set security firewall name Local rule 10 action 'accept'
set security firewall name Local rule 10 description 'RIP' ("/opt/vyatta/etc/cpp.conf" )
Ordre des opérations pour les pare-feux, la conversion d'adresses réseau, le routage et DNS
Problèmes relatifs à l'ordre des opérations
Dans un scénario où Masquerade Source NAT est déployé sur un dispositif IBM Cloud® Virtual Router Appliance, vous ne pouvez pas utiliser le pare-feu afin de déterminer les droits d'accès à Internet pour les hôtes. En effet, l'adresse post-conversion d'adresses réseau est identique.
Pour les unités Vyatta 5400, cette opération était possible car la protection par pare-feu était établie avant la conversion d'adresses réseau, autorisant la restriction d'accès des hôtes à Internet.
Solutions de contournement relatives à l'ordre des opérations
Un nouveau schéma d'acheminement est requis pour le VRA :

Table de routage basée sur des règles
Problèmes de table de routage basés sur des règles
Le mot "Table" dans les configurations est facultatif dans le routage basé sur des règles pour v5400. Toutefois, pour le dispositif VRA, si l'action est accept
, la zone Table est obligatoire. Si l'action
est drop
sur la configuration VRA, la zone Table est facultative.
Solutions de contournement pour le routage basé sur des règles
"Table Main" est une option disponible dans le routage basé sur des règles pour Vyatta 5400. L'équivalent sur le dispositif VRA est "routing-instance default".
Routage basé sur des règles sur l'interface du tunnel
Problèmes de routage basé sur des règles dans l'interface de tunnel
Sur le dispositif IBM Cloud® Virtual Router Appliance, des règles de routage basé sur des règles (PBR) peuvent être appliquées aux interfaces de plan de données pour le trafic entrant, mais pas aux interfaces non numérotées de bouclage, de tunnel, de pont, OpenVPN, VTI et d'adresse IP.
Solutions de contournement pour les problèmes de routage basés sur des règles dans l'interface de tunnel
Il n'existe actuellement aucune solution de contournement pour ce problème.
OpenVPN
Problèmes OpenVPN
OpenVPN ne démarre pas lorsque le paramètre push-route
est utilisé sur le dispositif IBM Cloud® Virtual Router Appliance.
Solutions de contournement OpenVPN
Utilisez le paramètre openvpn-option
au lieu du paramètre push-route
.
GRE/VTI sur IPSEC + OSPF
Problèmes GRE/VTI via IPSEC + OSPF
- Lorsque plusieurs sous-réseaux sont configurés pour l'interface VIF, le trafic ne peut pas traverser ces sous-réseaux sur le dispositif VRA.
- Le routage entre réseaux locaux virtuels ne fonctionne pas sur le dispositif VRA.
Solutions de contournement des problèmes GRE/VTI via IPSEC + OSPF
Utilisez les règles allow implicites pour accepter le trafic sur des interfaces VIF.
IPsec (Internet Protocol Security)
Problèmes IPsec
IPsec (basé sur le préfixe) ne fonctionne pas avec le filtre IN.
Solutions de contournement IPsec
Utilisez IPsec (basé sur VTI).
IPSEC "match-none"
Problèmes IPSEC "match-none"
Avec des unités Vyatta 5400, la règle de pare-feu suivante est autorisée :
set firewall name allow rule 10 ipsec
Toutefois, avec IBM Cloud® Virtual Router Appliance, il n'existe aucun IPsec.
Solutions de contournement IPSEC "match-none"
Les autres règles possibles pour les unités VRA sont les suivantes :
match-ipsec Inbound IPsec packets
match-none Inbound non-IPsec packets
IPSEC 'match-ipsec"
Problèmes IPSEC "match-ipsec"
Avec des unités Vyatta 5400, les règles de pare-feu suivantes sont autorisées :
set firewall name OUTSIDE_LOCAL rule 50 action 'accept'
set firewall name OUTSIDE_LOCAL rule 50 ipsec 'match-ipsec'
Toutefois, avec IBM Cloud® Virtual Router Appliance, il n'existe aucun IPsec.
Solutions de contournement IPSEC "match-ipsec"
Ajoutez les protocoles ESP
et AH
(respectivement, protocoles IP 50 et 51).
La règle action
peut être accept
ou drop
, comme illustré dans l'exemple suivant :
set security firewall name <name> rule <rule-no> action accept
set security firewall name <name> rule <rule-no> destination port 500
set security firewall name <name> rule <rule-no> protocol udp
set security firewall name <name> rule <rule-no> action accept
set security firewall name <name> rule <rule-no> destination port 4500
set security firewall name <name> rule <rule-no> protocol udp
set security firewall name <name> rule <rule-no> action accept
set security firewall name <name> rule <rule-no> protocol ah
set security firewall name <name> rule <rule-no> action accept
set security firewall name <name> rule <rule-no> protocol esp
IPsec de site à site avec DNAT
IPsec Site-to-site avec problèmes DNAT
IPsec (basé sur le préfixe) ne fonctionne pas avec DNAT.
server (10.71.68.245) -- vyatta 1 (11.0.0.1)
===S-S-IPsec=== (12.0.0.1)
vyatta 2 -- client (10.103.0.1)
Tun50 172.16.1.245
Le fragment de code précédent est un petit exemple de configuration pour la conversion DNAT après le déchiffrement d'un paquet IPsec sur un système Vyatta 5400. L'exemple illustre deux unités Vyatta, vyatta1 (11.0.0.1)
et vyatta2 (12.0.0.1)
.
L'appairage IPsec est établi entre 11.0.0.1
et 12.0.0.1
. Dans ce cas, le client cible l'adresse 172.16.1.245
à partir de l'adresse source 10.103.0.1
de bout en bout.Le comportement prévu
dans ce scénario est le suivant : l'adresse de destination 172.16.1.245
doit être convertie en 10.71.68.245
dans l'en-tête de paquet.
Initialement, l'unité Vyatta 5400 effectuait une action DNAT sur l'IPsec entrant, en fermant l'interface et en renvoyant gracieusement le trafic dans le tunnel IPsec à l'aide du tableau de suivi de connexion.
Sur un dispositif IBM Cloud® Virtual Router Appliance, la configuration ne fonctionne pas de la même façon. La session est créée, mais le trafic de retour ignore le tunnel IPsec après que la table conntrack inverse le changement DNAT.Le dispositif VRA envoie ensuite le paquet sur le réseau sans chiffrement IPsec.L'unité en amont n'attend pas ce trafic et en général, le supprime.Tant que la connectivité de bout en bout est rompue, il s'agit du comportement attendu.
IPsec Site-to-site avec des solutions de contournement DNAT
Pour prendre en charge ce scénario de mise en réseau, IBM a créé une demande d'amélioration.
Pendant l'évaluation de cette demande d'amélioration, la solution de contournement suivante est recommandée :
Commandes de configuration de l'interface
set interfaces dataplane dp0p192p1 address '11.0.0.1/30'
set interfaces dataplane dp0p224p1 address '10.0.0.2/30'
set interfaces dataplane dp0p224p1 policy route pbr 'Backwards-DNAT'
set interfaces loopback lo address '169.254.1.1/24'
set interfaces tunnel tun50 address '169.254.240.1/32'
set interfaces tunnel tun50 encapsulation 'gre'
set interfaces tunnel tun50 local-ip '169.254.1.1'
set interfaces tunnel tun50 remote-ip '169.254.1.1'
Commandes de configuration VPN
set security vpn ipsec esp-group ESP lifetime '30000'
set security vpn ipsec esp-group ESP proposal 1 encryption 'aes128'
set security vpn ipsec esp-group ESP proposal 1 hash 'sha1'
set security vpn ipsec ike-group IKE lifetime '60000'
set security vpn ipsec ike-group IKE proposal 1 encryption 'aes128'
set security vpn ipsec ike-group IKE proposal 1 hash 'sha1'
set security vpn ipsec site-to-site peer 12.0.0.1 authentication mode 'pre-shared-secret'
set security vpn ipsec site-to-site peer 12.0.0.1 authentication pre-shared-secret 'thekey'
set security vpn ipsec site-to-site peer 12.0.0.1 default-esp-group 'ESP'
set security vpn ipsec site-to-site peer 12.0.0.1 ike-group 'IKE'
set security vpn ipsec site-to-site peer 12.0.0.1 local-address '11.0.0.1'
set security vpn ipsec site-to-site peer 12.0.0.1 tunnel 1 local prefix '172.16.1.245/30'
set security vpn ipsec site-to-site peer 12.0.0.1 tunnel 1 remote prefix '10.103.0.0/24'
Commandes de configuration NAT
set service nat destination rule 10 destination address '172.16.1.245'
set service nat destination rule 10 inbound-interface 'tun50'
set service nat destination rule 10 source address '10.103.0.1'
set service nat destination rule 10 translation address '10.71.68.245'
set service nat source rule 10 destination address '10.103.0.1'
set service nat source rule 10 'log'
set service nat source rule 10 outbound-interface 'tun50'
set service nat source rule 10 source address '10.71.68.245'
set service nat source rule 10 translation address '172.16.1.245'
Commandes de configuration des protocoles
set protocols static interface-route 172.16.1.245/32 next-hop-interface 'tun50'
set protocols static table 50 interface-route 0.0.0.0/0 next-hop-interface 'tun50'
Commandes de configuration PBR
set policy route pbr Backwards-DNAT description 'Get return traffic back to tunnel for DNAT'
set policy route pbr Backwards-DNAT rule 10 action 'accept'
set policy route pbr Backwards-DNAT rule 10 address-family 'ipv4'
set policy route pbr Backwards-DNAT rule 10 destination address '10.103.0.0/24'
set policy route pbr Backwards-DNAT rule 10 source address '10.71.68.0/24'
set policy route pbr Backwards-DNAT rule 10 table '50'
PPTP
Problèmes PPTP
PPTP n'est plus pris en charge sur le dispositif IBM Cloud® Virtual Router Appliance.
Solutions de contournement PPTP
Utilisez le protocole L2TP à la place.
Script de redémarrage IPsec
Script pour les problèmes de redémarrage IPsec
A chaque fois qu'une adresse virtuelle VRRP est ajoutée à un IBM Cloud® Virtual Router Appliance sur un réseau privé virtuel à haute disponibilité, vous devez réinitialiser le démon IPsec. En effet, le service IPsec écoute uniquement les connexions aux adresses qui sont présentes sur le dispositif VRA lorsque le démon de service IKE est initialisé.
Pour une paire de dispositifs VRA avec VRRP, il se peut que le routeur de secours ne possède pas l'adresse virtuelle VRRP qui est présente sur l'unité au cours de l'initialisation si cette adresse n'est pas présente sur le routeur principal. Par conséquent, pour réinitialiser le démon IPsec lorsqu'une transition d'état VRRP se produit, exécutez la commande suivante sur le routeur principal et le routeur de secours :
interfaces dataplane interface-name vrrp vrrp-group group-id notify
Comptage récent et période récente
Problèmes récents de nombre et d'heure
L'objectif de la règle suivante est de limiter le nombre de connexions SSH à 3 toutes les 30 secondes pour SSH avec n'importe quelle adresse :
set firewall name localGateway rule 300 action 'drop'
set firewall name localGateway rule 300 description 'Deter SSH brute force'
set firewall name localGateway rule 300 destination port '22'
set firewall name localGateway rule 300 protocol 'tcp'
set firewall name localGateway rule 300 recent count '3'
set firewall name localGateway rule 300 recent time '30'
set firewall name localGateway rule 300 state new 'enable'
Dans IBM Cloud® Virtual Router Appliance, cette règle présente les problèmes suivants :
- L'option de comptage récent et de période récente a été dépréciée.
- En raison du problème précédent, la règle ne peut pas fonctionner comme prévu et bloque toutes les connexions SSH à l'interface appliquée.
Solutions de contournement des problèmes récents de nombre et d'heure
Utilisez CPP à la place.
Problèmes liés à set system conntrack
Problèmes liés à set system conntrack
set system conntrack expect-table-size '8192'
set system conntrack hash-size '375000'
set system conntrack modules ftp 'disable'
set system conntrack modules 'gre'
set system conntrack modules h323 'disable'
set system conntrack modules nfs 'disable'
set system conntrack modules pptp 'disable'
set system conntrack modules sip 'disable'
set system conntrack modules sqlnet 'disable'
set system conntrack modules tftp 'disable'
set system conntrack table-size '3000000'
Problèmes liés à set system conntrack timeout
Problèmes de dépassement de délai d'attente de set system conntrack
set system conntrack timeout icmp '30'
set system conntrack timeout other '600'
set system conntrack timeout tcp close '10'
set system conntrack timeout tcp close-wait '60'
set system conntrack timeout tcp established '432000'
set system conntrack timeout tcp fin-wait '120'
set system conntrack timeout tcp last-ack '30'
set system conntrack timeout tcp syn-recv '60'
set system conntrack timeout tcp syn-sent '120'
set system conntrack timeout tcp time-wait '60'
Pare-feu basé sur le temps
Problèmes de pare-feu basés sur la date/heure
set firewall name PRIV_SERVICE_IN rule 58 action 'accept'
set firewall name PRIV_SERVICE_IN rule 58 description '586427 Acesso a base de dados ate 22-2-18'
set firewall name PRIV_SERVICE_IN rule 58 destination address '10.150.156.57'
set firewall name PRIV_SERVICE_IN rule 58 destination port '3306'
set firewall name PRIV_SERVICE_IN rule 58 protocol 'tcp'
set firewall name PRIV_SERVICE_IN rule 58 source address '10.150.156.104'
set firewall name PRIV_SERVICE_IN rule 58 time startdate '2017-08-22'
set firewall name PRIV_SERVICE_IN rule 58 time stopdate '2018-02-22'
TCP-MSS
Problèmes TCP-MSS
set interfaces tunnel tun3 address '172.17.175.45/30'
set interfaces tunnel tun3 encapsulation 'gre'
set interfaces tunnel tun3 local-ip '169.55.223.76'
set interfaces tunnel tun3 mtu '1476'
set interfaces tunnel tun3 multicast 'disable'
set interfaces tunnel tun3 policy route 'change-mss'(in 18.x unable to apply tcp-mss using PBR only option is to set on interface directly which i believe is not equivalent to pbr .
set interfaces tunnel tun3 remote-ip '104.129.200.34'
set policy route change-mss rule 1 protocol 'tcp'
set policy route change-mss rule 1 set tcp-mss '1436'
set policy route change-mss rule 1 tcp flags 'SYN
Application spécifique ou port rompu sur le VPN IPsec S-S
Problèmes spécifiques d'application ou de port interrompu dans le VPN IPsec S-S
vyatta@v5600dallas09# set security vpn ipsec site-to-site peer 12.0.0.1 tunnel 1 remote
Possible Completions:
<Enter> Execute the current command
port Any TCP or UDP port
prefix Remote IPv4 or IPv6 prefix set security vpn ipsec esp-group ESP lifetime '30000'
set security vpn ipsec esp-group ESP proposal 1 encryption 'aes128'
set security vpn ipsec esp-group ESP proposal 1 hash 'sha1'
set security vpn ipsec ike-group IKE lifetime '60000'
set security vpn ipsec ike-group IKE proposal 1 encryption 'aes128'
set security vpn ipsec ike-group IKE proposal 1 hash 'sha1'
set security vpn ipsec site-to-site peer 12.0.0.1 authentication mode 'pre-shared-secret'
set security vpn ipsec site-to-site peer 12.0.0.1 authentication pre-shared-secret 'thekey'
set security vpn ipsec site-to-site peer 12.0.0.1 default-esp-group 'ESP'
set security vpn ipsec site-to-site peer 12.0.0.1 ike-group 'IKE'
set security vpn ipsec site-to-site peer 12.0.0.1 local-address '11.0.0.1'
set security vpn ipsec site-to-site peer 12.0.0.1 tunnel 1 local prefix '172.16.1.245/30'
set security vpn ipsec site-to-site peer 12.0.0.1 tunnel 1 remote prefix '10.103.0.0/24' set security vpn ipsec site-to-site peer 12.0.0.1 tunnel 1 remote port 21 (ftp)
Changement significatif du comportement de journalisation
Problèmes de changement significatif du comportement de journalisation
Le comportement a changé de manière significative entre l'unité Vyatta 5400 et IBM Cloud® Virtual Router Appliance, qu'il s'agisse de la journalisation de session ou de la journalisation de paquet.
- Journalisation de session : enregistrement des transitions d'état de session avec état
- Journalisation de paquet : enregistrement de tous les paquets qui correspondent à la règle. Etant donné que la journalisation de paquet est enregistrée dans le fichier journal par "unités de paquet", une baisse notable du débit et de la pression de la capacité disque est constatée.
- La fonction de journalisation du routeur vRouter peut être utilisée pour capturer les activités de pare-feu. Comme pour toutes les fonctions de journalisation, vous ne devez l'activer que lorsque vous tentez d'identifier et de résoudre un problème spécifique, puis vous devez la désactiver dès que possible.
Le pare-feu avec état, qui gère les sessions de pare-feu/conversion d'adresses réseau, écrit des données dans des "unités de session". Il est recommandé d'utiliser la journalisation de session. Chaque exemple de définition est décrit ci-après.
Session / journalisation
security firewall session-log <protocol>
system syslog file <filename> facility <facility> level <level>
Pare-feu de journalisation de paquets
security firewall name <name> default-log <action>
security firewall name <name> rule <rule-number> log
NAT
service nat destination rule <rule-number> log
service nat source rule <rule-number> log PBR
policy route pbr <name> rule <rule-number> log
qualité de service
policy qos name <policy-name> shaper class <class-id> match <rule-name>