Hvilken pakke skal en VPN-politik med to WAN matche?

Anmodninger om at route VPN over den anden uplink beskriver mindst to forskellige opgaver, og den politik, der løser den ene, rører ikke den anden. I den første opgave flytter den krypterede transport mellem to endepunkter til en anden WAN-adresse. I den anden forlader en tilsluttet brugers dekrypterede applikationsflow mod et andet næste hop. Begge er legitime, begge bruger routing, og hver især kræver et match på en pakke, der findes på det punkt, hvor beslutningen træffes. Gå gennem kontrollerne nedenfor i rækkefølge, fordi den første afgør, hvilken pakke senere regler skal navngive.

Navngiv de to samtaler

Forestil dig en fjernmedarbejder tilsluttet en kontorgateway, som åbner HTTPS mod en intern applikationsserver. Der er to uafhængige samtaler på ledningen, og de har forskellige adresser i hver ende. Den ydre samtale løber mellem de to VPN-endepunkter: gatewayadresse til peeradresse, med det protokol og den port, som udrulningen forhandlede. Den indre samtale løber fra den adresse, klienten fik tildelt, til applikationsserverens adresse på port 443.

Applikationens destinationsport er ikke VPN’ens transportport, og ingen mængde politik på TCP 443 flytter tunnelen. Ligesom en regel, der omdirigerer peerens transportadresse, intet siger om, hvor den brugers HTTP-anmodning går hen efter dekryptering. Skriv begge samtaler ned med deres rigtige adresser, før du rører en regel, fordi det meste af forvirringen på dette område kommer af at navngive den ene og konfigurere den anden.

Find ud af, hvor din politik faktisk kan se pakken

Matchet skal evalueres i den kæde og det namespace, hvor pakken stadig har den form, du beskrev. En regel knyttet til LAN-ingress ser den indre pakke ukrypteret, før den routes mod tunnelen. En regel anvendt på lokalt genereret trafik ser pakker, som gatewayen selv genererer, og den dækker ikke automatisk trafik, som gatewayen blot videresender. Inkapslet output er igen et tredje tilfælde, som normalt håndteres på det interface, der bærer tunnelen, og ikke på LAN-siden.

Det er derfor, det samme konfigurationsuddrag opfører sig forskelligt på to platforme: vedhæftningspunkterne er forskellige, og en leverandørs politikhook kan sidde før eller efter krypteringstrinnet. Læs pakkestien for det konkrete produkt i stedet for at antage rækkefølgen ud fra en anden leverandørs diagram.

Bekræft den transport, du forhandlede

For UDP-inkapslet IPsec placerer RFC 3948 ESP inde i UDP og bruger en markør, der ikke er ESP, for at holde IKE adskillelig på den delte port. Almindelig ESP er en IP-protokol, ikke en TCP- eller UDP-port, så en firewallregel skrevet mod et portnummer matcher den slet ikke. Denne forskel afgør, om din WAN-politik har brug for en UDP-regel, en protokolregel eller begge.

Forhandlede værdier slår huskede. Læs associeringens aktuelle porte og adresser fra enheden i stedet for at tilføje TCP 4500 eller en gammel leverandørport for en sikkerheds skyld, hvilket fanger urelateret trafik og skjuler det reelle klassificeringsproblem.

Kontroller returvejen, før du forpligter dig

Succes udad beviser halvdelen af et design. En pakke, der vender tilbage mod puljen af fjernklienter, er ikke længere synlig under klientens adresse, når inkapslingen erstatter den: den ydre destination er peerens transportadresse. Hvis den anden uplink når den peer gennem en anden udbyder, kan dens oversættelse og filtrering være uenig med den første, og associeringen kan have brug for at blive genopbygget i stedet for migreret.

Tilstanden for netværksadresseoversættelse er det sædvanlige offer for et WAN-skift. Noter den valgte uplink, den forventede ydre kildeadresse, den anvendte oversættelse og peerens tilgængelighed tilbage til den, og hold derefter transporten tilgængelig uden at sende den ind i den tunnel, den bærer.

Bekræft begge lag med to optagelser

En optagelse på WAN-interfacet og en inde i tunnelen afgør spørgsmålet hurtigere end enhver konfigurationsdiff. Kør dem fra gatewayen, mens en godkendt klient udfører en enkelt anmodning, og gem begge filer.

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

Den første optagelse skal vise den ydre samtale forlade det interface, du havde tænkt, med den forventede kildeadresse. Den anden skal vise den indre samtale én gang, ikke duplikeret, med klientadressen som kilde og applikationsserveren som destination. Ruteopslaget bekræfter, hvilken tabel routeren ville bruge til det kilde-destinationspar, og det er der, en politikfejl normalt dukker op. Hvis en af optagelserne ikke dukker op, er beslutningspunktet et andet sted end det, reglen blev knyttet til, og rettelsen hører der og ikke i et bredere match.