Quin paquet ha de fer coincidir una política VPN de doble WAN?

Els encàrrecs d’encaminar la VPN per la segona connexió descriuen com a mínim dues feines diferents, i la política que arregla una no toca l’altra. A la primera feina, el transport xifrat entre dos extrems es trasllada a una altra adreça WAN. A la segona, el flux d’aplicació desxifrat d’un usuari connectat surt cap a un altre salt següent. Totes dues són legítimes, totes dues fan servir encaminament, i cadascuna necessita una coincidència en un paquet que existeixi al punt on es pren la decisió. Seguiu les comprovacions de sota en ordre, perquè la primera determina quin paquet han de nomenar les regles posteriors.

Nomena les dues converses

Imagineu un treballador remot connectat a una passarel·la d’oficina que obre HTTPS cap a un servidor d’aplicacions intern. Hi ha dues converses independents al fil, i tenen adreces diferents a cada extrem. La conversa exterior va entre els dos extrems de la VPN: de l’adreça de la passarel·la a l’adreça del parell, amb el protocol i el port que hagi negociat el desplegament. La conversa interior va de l’adreça assignada al client a l’adreça del servidor d’aplicacions al port 443.

El port de destinació de l’aplicació no és el port de transport de la VPN, i cap quantitat de política sobre TCP 443 mourà el túnel. Igualment, una regla que redirigeix l’adreça de transport del parell no diu res sobre on va la petició HTTP d’aquell usuari després de desxifrar-la. Escriviu les dues converses amb les seves adreces reals abans de tocar cap regla, perquè la major part de la confusió en aquesta àrea ve de nomenar-ne una i configurar l’altra.

Trobeu on la vostra política pot veure realment el paquet

La coincidència s’ha d’avaluar a la cadena i l’espai de noms on el paquet encara té la forma que heu descrit. Una regla enganxada a l’entrada de LAN veu el paquet interior, sense xifrar, abans que s’encamini cap al túnel. Una regla aplicada al trànsit generat localment veu els paquets que genera la mateixa passarel·la, i no cobreix automàticament el trànsit que la passarel·la només reenvia. La sortida encapsulada és encara un tercer cas, normalment gestionat a la interfície que porta el túnel i no al costat de la LAN.

Per això el mateix fragment de configuració es comporta diferent en dues plataformes: els punts d’enganxament són diferents, i el ganxo de política d’un fabricant pot seure abans o després del pas de xifratge. Llegiu el camí del paquet per al producte concret en lloc de suposar l’ordre a partir del diagrama d’un altre fabricant.

Confirmeu el transport que heu negociat

Per a IPsec encapsulat en UDP, RFC 3948 posa ESP dins d’UDP i fa servir un marcador que no és ESP perquè IKE segueixi essent distingible al port compartit. L’ESP simple és un protocol IP, no un port TCP o UDP, així que una regla de tallafoc escrita contra un número de port no hi coincidirà gens. Aquesta distinció decideix si la vostra política WAN necessita una regla UDP, una regla de protocol o totes dues.

Els valors negociats guanyen els recordats. Llegiu els ports i les adreces actuals de l’associació des del dispositiu en lloc d’afegir TCP 4500 o un port antic del fabricant per si de cas, cosa que captura trànsit no relacionat i amaga el problema real de classificació.

Comproveu el camí de tornada abans de comprometre-us

L’èxit de sortida demostra la meitat d’un disseny. Un paquet que torna cap al conjunt de clients remots ja no és visible sota l’adreça del client quan l’encapsulació la substitueix: la destinació exterior és l’adreça de transport del parell. Si la segona connexió arriba a aquest parell per un operador diferent, la seva traducció i filtratge poden discrepar de la primera, i l’associació pot necessitar reconstruir-se en lloc de migrar-se.

L’estat de traducció d’adreces de xarxa és la víctima habitual d’un canvi de WAN. Anoteu la connexió triada, l’adreça d’origen exterior esperada, la traducció en ús i l’abastabilitat del parell cap a ella, i manteniu després el transport abastable sense enviar-lo dins del túnel que porta.

Verifiqueu les dues capes amb dues captures

Una captura a la interfície WAN i una dins del túnel resolen la qüestió més de pressa que qualsevol comparació de configuració. Executeu-les des de la passarel·la mentre un client aprovat fa una sola petició, i guardeu tots dos fitxers.

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

La primera captura hauria de mostrar la conversa exterior sortint de la interfície que preteníeu, amb l’adreça d’origen esperada. La segona hauria de mostrar la conversa interior una vegada, no duplicada, amb l’adreça del client com a origen i el servidor d’aplicacions com a destinació. La consulta de ruta confirma quina taula faria servir l’encaminador per a aquell parell origen i destinació, que és on sol aparèixer un error de política. Si qualsevol de les captures no apareix, el punt de decisió és en un altre lloc i no on es va enganxar la regla, i la correcció pertany allà i no a una coincidència més àmplia.