Hvilken pakke må en VPN-policy med to WAN treffe?

Forespørsler om å rute VPN over den andre uplink-forbindelsen beskriver minst to forskjellige jobber, og policyen som fikser den ene, rører ikke den andre. I den første jobben flytter den krypterte transporten mellom to endepunkter til en annen WAN-adresse. I den andre forlater den dekrypterte applikasjonsflyten til en tilkoblet bruker mot et annet neste hopp. Begge er legitime, begge bruker ruting, og hver krever et treff på en pakke som finnes på punktet der beslutningen tas. Gå gjennom kontrollene nedenfor i rekkefølge, fordi den første avgjør hvilken pakke senere regler må navngi.

Navngi de to samtalene

Se for deg en fjernarbeider koblet til en kontorgateway, som åpner HTTPS mot en intern applikasjonsserver. Det er to uavhengige samtaler på ledningen, og de har ulike adresser i hver ende. Den ytre samtalen går mellom de to VPN-endepunktene: gatewayadresse til peeradresse, med det protokoll og den porten utrullingen forhandlet frem. Den indre samtalen går fra adressen klienten fikk tildelt, til applikasjonsserverens adresse på port 443.

Applikasjonens destinasjonsport er ikke VPN-ens transportport, og ingen mengde policy på TCP 443 flytter tunnelen. På samme måte sier en regel som omdirigerer peerens transportadresse ingenting om hvor den brukerens HTTP-forespørsel går etter dekryptering. Skriv ned begge samtalene med deres virkelige adresser før du rører en regel, fordi det meste av forvirringen på dette området kommer av å navngi den ene og konfigurere den andre.

Finn ut hvor policyen du faktisk kan se pakken

Treffet må evalueres i den kjeden og det navnerommet der pakken fortsatt er i formen du beskrev. En regel festet til LAN-ingress ser den indre pakken ukryptert, før den rutes mot tunnelen. En regel som brukes på lokalt generert trafikk, ser pakker som gatewayen selv genererer, og den dekker ikke automatisk trafikk som gatewayen bare videresender. Kapslet utdata er igjen et tredje tilfelle, vanligvis håndtert på grensesnittet som bærer tunnelen, og ikke på LAN-siden.

Det er derfor det samme konfigurasjonsutdraget oppfører seg ulikt på to plattformer: festepunktene er forskjellige, og en leverandørs policykrok kan sitte før eller etter krypteringstrinnet. Les pakkestien for det konkrete produktet i stedet for å anta rekkefølgen fra en annen leverandørs diagram.

Bekreft transporten du forhandlet frem

For UDP-kapslet IPsec plasserer RFC 3948 ESP inne i UDP og bruker en markør som ikke er ESP, slik at IKE forblir skillbar på den delte porten. Vanlig ESP er en IP-protokoll, ikke en TCP- eller UDP-port, så en brannmurregel skrevet mot et portnummer vil ikke treffe den i det hele tatt. Denne forskjellen avgjør om WAN-policyen din trenger en UDP-regel, en protokollregel eller begge.

Forhandlede verdier slår huskede. Les assosiasjonens gjeldende porter og adresser fra enheten i stedet for å legge til TCP 4500 eller en gammel leverandørport for sikkerhets skyld, noe som fanger urelatert trafikk og skjuler det egentlige klassifiseringsproblemet.

Kontroller returveien før du forplikter deg

Suksess utover beviser halvparten av et design. En pakke som kommer tilbake mot gruppen av fjernklienter, er ikke lenger synlig under klientens adresse når kapslingen erstatter den: den ytre destinasjonen er peerens transportadresse. Hvis den andre uplink-forbindelsen når den peeren gjennom en annen tilbyder, kan oversettelsen og filtreringen avvike fra den første, og assosiasjonen må kanskje bygges opp på nytt i stedet for å migreres.

Tilstanden til nettverksadresseoversettelsen er det vanlige offeret for et WAN-bytte. Noter den valgte uplink-forbindelsen, den forventede ytre kildeadressen, oversettelsen som brukes og peerens tilgjengelighet tilbake til den, og hold deretter transporten tilgjengelig uten å sende den inn i tunnelen den bærer.

Verifiser begge lagene med to opptak

Ett opptak på WAN-grensesnittet og ett inne i tunnelen avgjør spørsmålet raskere enn noen konfigurasjonsdiff. Kjør dem fra gatewayen mens en godkjent klient utfører én enkelt forespørsel, og ta vare på begge filene.

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

Det første opptaket skal vise den ytre samtalen forlate grensesnittet du mente, med den forventede kildeadressen. Det andre skal vise den indre samtalen én gang, ikke duplisert, med klientadressen som kilde og applikasjonsserveren som destinasjon. Ruteoppslaget bekrefter hvilken tabell ruteren ville brukt for det kilde-destinasjonsparet, og det er der en policyfeil vanligvis dukker opp. Hvis ett av opptakene ikke dukker opp, er beslutningspunktet et annet sted enn der regelen ble festet, og rettelsen hører hjemme der og ikke i et bredere treff.