Kva pakke må ein VPN-policy med to WAN treffe?

Førespurnader om å rute VPN over den andre uplink-linja skildrar minst to ulike jobbar, og policyen som rettar den eine, rører ikkje den andre. I den første jobben flyttar den krypterte transporten mellom to endepunkt til ei anna WAN-adresse. I den andre går den dekrypterte applikasjonsflyten til ein tilkopla brukar mot eit anna neste hopp. Begge er legitime, begge brukar ruting, og kvar krev eit treff på ein pakke som finst på punktet der avgjerda blir teken. Gå gjennom kontrollane nedanfor i rekkjefølgje, fordi den første avgjer kva pakke seinare reglar må nemne.

Namngje dei to samtalene

Sjå føre deg ein fjernarbeidar kopla til ein kontorgateway, som opnar HTTPS mot ein intern applikasjonsserver. Det er to uavhengige samtaler på linja, og dei har ulike adresser i kvar ende. Den ytre samtalen går mellom dei to VPN-endepunkta: gatewayadresse til peeradresse, med det protokollen og den porten utrullinga forhandla fram. Den indre samtalen går frå adressa klienten fekk tildelt, til adressa til applikasjonsserveren på port 443.

Destinasjonsporten til applikasjonen er ikkje transportporten til VPN-en, og inga mengd policy på TCP 443 flyttar tunnelen. På same måte seier ein regel som omdirigerer transportadressa til peeren ingenting om kvar HTTP-førespurnaden til den brukaren går etter dekryptering. Skriv ned begge samtalene med dei verkelege adressene sine før du rører ein regel, fordi det meste av forvirringa på dette feltet kjem av å namngje den eine og konfigurere den andre.

Finn ut kvar policyen du faktisk kan sjå pakken

Treffet må evaluerast i den kjeda og det namnerommet der pakken framleis er i forma du skildra. Ein regel festa til LAN-ingress ser den indre pakken ukryptert, før han blir ruta mot tunnelen. Ein regel som blir brukt på lokalt generert trafikk, ser pakkar som gatewayen sjølv genererer, og han dekkjer ikkje automatisk trafikk som gatewayen berre videresender. Kapsla utdata er igjen eit tredje tilfelle, vanlegvis handsama på grensesnittet som ber tunnelen, og ikkje på LAN-sida.

Det er derfor det same konfigurasjonsutdraget oppfører seg ulikt på to plattformer: festepunkta er ulike, og policykroken til ein leverandør kan sitje før eller etter krypteringstrinnet. Les pakkestien for det konkrete produktet i staden for å anta rekkjefølgja frå diagrammet til ein annan leverandør.

Stadfest transporten du forhandla fram

For UDP-kapsla IPsec plasserer RFC 3948 ESP inne i UDP og brukar ein markør som ikkje er ESP, slik at IKE blir skilbar på den delte porten. Vanleg ESP er ein IP-protokoll, ikkje ein TCP- eller UDP-port, så ein brannmurregel skriven mot eit portnummer vil ikkje treffe han i det heile. Denne skilnaden avgjer om WAN-policyen din treng ein UDP-regel, ein protokollregel eller begge.

Forhandla verdiar slår hugsa verdiar. Les dei gjeldande portane og adressene til assosiasjonen frå eininga i staden for å leggje til TCP 4500 eller ein gamal leverandørport for sikkerheits skuld, noko som fangar urelatert trafikk og skjuler det eigentlege klassifiseringsproblemet.

Kontroller returvegen før du forpliktar deg

Suksess utover beviser halvparten av eit design. Ein pakke som kjem tilbake mot gruppa av fjernklientar, er ikkje lenger synleg under adressa til klienten når kapslinga erstattar henne: den ytre destinasjonen er transportadressa til peeren. Viss den andre uplink-linja når den peeren gjennom ein annan tilbydar, kan omsetjinga og filtreringa hennar avvike frå den første, og assosiasjonen må kanskje byggjast opp på nytt i staden for å migrerast.

Tilstanden til nettverksadresseomsetjinga er det vanlege offeret for eit WAN-byte. Noter den valde uplink-linja, den forventa ytre kjeldeadressa, omsetjinga som blir brukt og tilgjenge til peeren tilbake dit, og hald deretter transporten tilgjengeleg utan å sende han inn i tunnelen han ber.

Verifiser begge laga med to opptak

Eitt opptak på WAN-grensesnittet og eitt inne i tunnelen avgjer spørsmålet raskare enn nokon konfigurasjonsdiff. Køyr dei frå gatewayen medan ein godkjend klient gjer éin einaste førespurnad, 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 meinte, med den forventa kjeldeadressa. Det andre skal vise den indre samtalen éin gong, ikkje duplisert, med klientadressa som kjelde og applikasjonsserveren som destinasjon. Ruteoppslaget stadfester kva tabell ruteren ville brukt for det kjelde-destinasjonsparet, og det er der ein policyfeil vanlegvis dukkar opp. Viss eitt av opptaka ikkje dukkar opp, er avgjerdsprunktet ein annan stad enn der regelen vart festa, og rettinga høyrer heime der og ikkje i eit breiare treff.