Site-til-site eller fjernaksess via VPN: hva de to kobler sammen
Den ene kobler sammen gateways, den andre kobler sammen enheter. Sammenlign trafikkvelgere med ruter, planlegg adresseringen, og test deretter videresending og policy fra en ekte vert.
Begge designene kalles VPN, og de løser ulike problemer. En site-til-site-tunnel kobler sammen to gateways, slik at hver vert bak dem kan nå tillatte adresser på den andre siden uten å installere noe. En fjernaksess-tunnel kobler enkeltenheter til et nettverk, én klient om gangen. Sammenligningen er viktig fordi de fleste utrullingsfeil kommer av å konfigurere det ene designet mens man forventer det andres oppførsel, og symptomet er vanligvis en tidsavbrudd på en tjeneste som tunnelen faktisk nådde.
To design, to grenser
| Site-to-site | Remote access | |
|---|---|---|
| Endpoints | two gateways | a gateway and each client |
| Who configures | network owners | each user or an MDM |
| Scope of reach | whatever the gateways route | whatever the client is granted |
| Broadcast discovery | not carried | not carried |
Ingen av designene utvider et LAN-kringkastingsdomene. Enheter på den andre siden vises ikke i en lokal oppdagelsesliste, og å forvente det er den første antakelsen man må slippe. Private DNS-navn du bevisst publiserer, er mer forutsigbare enn noen oppdagelsesprotokoll, og de overlever et bytte av leverandør.
Ta 10.10.0.0/24 på det ene stedet og 10.20.0.0/24 på det andre. Gateway A trenger en rute eller en trafikkvelger som sender prefikset 10.20.0.0/24 inn i tunnelen, og gateway B trenger speilbildet av det. Vertsene på begge sider bruker da vanlig IP-tilkobling og får aldri vite at det finnes en tunnel. Den usynligheten er funksjonen, og det er også grunnen til at feil ser ut som vanlige nettverksfeil og ikke tunnelfeil.
Policysbasert og rutebasert er ikke den samme tunnelen
I en policysbasert IPsec-utrulling definerer de forhandlede trafikkvelgerne nøyaktig hvilke kilde- og målpar som er beskyttet. Hvis det dukker opp et nytt subnett bak en gateway og ingen velger dekker det, blir tunnelen stående og det nye subnettet blir rett og slett ikke fraktet. I et rutebasert design mottar et grensesnitt trafikken og rutetabellen bestemmer, noe som gjør det å legge til et prefiks til en ruteendring i stedet for en ny tunneforhandling.
StrongSwan viser begge visningene direkte, og å lese dem sammen er måten å finne ut hvilken modell du faktisk rullet ut.
swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'En velgerliste som utelater prefikset du trenger, forklarer feilen uten noen pakkefangst, og en rute som peker på feil grensesnitt forklarer speilfeilen på vei tilbake. Les begge før du forhandler på nytt, for en nøkkelfornyelse legger ikke til en velger du aldri konfigurerte.
Planlegg adresseringen før tunnelen
Overlappende områder er designfeilen som ikke kan rettes med konfigurasjon. Hvis begge stedene bruker 192.168.1.0/24, har en vert som trenger 192.168.1.50 to kandidater og ingen måte å velge. Tunnelen vil autentisere, sikkerhetsassosiasjonene vil bli opprettet, og ruteavgjørelsen blir likevel feil eller tvetydig.
Velg ett av tre ærlige alternativer: omnummerer det ene stedet, oversett det overlappende området ved gatewayen slik at hver side ser et eget prefiks, eller gi opp direkte ruting for disse vertene og publiser tjenesten på en annen måte. Hver har en kostnad, og den første er vanligvis billigst over en toårsperiode. Bestem før tunnelen finnes, for etterpå berører endringen hver enhet som har den gamle adressen.
Løs også MTU-spørsmålet tidlig. En tunnel reduserer den nyttige lasten, og et design som bygger på fragmentering oppfører seg annerledes enn et som fester MSS ved gatewayene.
Videresending og policy ligger utenfor tunnelen
Gatewayen må være villig til å videresende pakker mellom tunnegrensesnittet og LAN-grensesnittet, og begge retningene trenger policy som tillater tjenesten. På Linux er dette to separate innstillinger, i tillegg til brannmurreglene som avgjør om den videresendte strømmen i det hele tatt er tillatt.
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPTDen mottakende verten legger til et tredje lag: dens egen brannmur må fortsatt godta en klient fra det fjerne subnettet. En filserver som bare tillater sitt lokale /24, vil avvise videresendt trafikk fra 10.20.0.7, uansett hvor sunn tunnelen ser ut, og den avvisningen leses lett som en rutefeil.
Test fra en vert, ikke fra gatewayen
En ping som sendes av gatewayen selv, kan følge en annen kildeadresse og en annen policy enn videresendt brukertrafikk. Det gjør den til en svak test og av og til en misvisende: den lykkes mens applikasjonen feiler, eller feiler mens applikasjonen virker.
ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/nullBruk en ekte vert, en ekte kildeadresse og den ekte protokollen applikasjonen bruker. Les deretter returveien separat, fordi en fungerende fremoverretning uten returrute gir en tidsavbrudd som ser identisk ut med en blokkert tjeneste.
Velg designet etter spørsmålet du besvarer: kobler du sammen nettverk, eller slipper du inn enheter? Alt annet, også hvilken leverandør du konfigurerer, følger av det svaret.