Site-til-site eller fjernåtkomst via VPN: kva dei to knyter saman

Begge designa blir kalla VPN, og dei løyser ulike problem. Ein site-til-site-tunnel knyter saman to gateways, slik at kvar vert bak dei kan nå tillatne adresser på den andre sida utan å installere noko. Ein fjernåtkomst-tunnel knyter einingar til eit nettverk, éin klient om gongen. Samanlikninga er viktig fordi dei fleste utrullingsfeila kjem av å konfigurere det eine designet medan ein ventar åtferda til det andre, og symptomet er vanlegvis eit tidsavbrot på ein teneste som tunnelen faktisk nådde.

To design, to grenser

Ingen av designa utvidar eit LAN-kringkastingsdomene. Einingar på den andre sida viser seg ikkje i ei lokal oppdagingsliste, og å vente det er den første føresetnaden ein må sleppe. Private DNS-namn du med vilje publiserer, er meir føreseielege enn nokon oppdagingsprotokoll, og dei overlever eit byte av leverandør.

Ta 10.10.0.0/24 på den eine staden og 10.20.0.0/24 på den andre. Gateway A treng ei rute eller ein trafikkveljar som sender prefikset 10.20.0.0/24 inn i tunnelen, og gateway B treng spegelbiletet av det. Vertane på begge sider brukar då vanleg IP-tilkopling og får aldri vita at det finst ein tunnel. Den usynlegheiten er funksjonen, og det er også grunnen til at feil ser ut som vanlege nettverksfeil og ikkje tunnelfeil.

Policysbasert og rutebasert er ikkje den same tunnelen

I ein policysbasert IPsec-utrulling definerer dei forhandla trafikkveljarane nøyaktig kva kjelde- og målpar som er verna. Viss det dukkar opp eit nytt subnett bak ein gateway og ingen veljar dekkjer det, blir tunnelen ståande og det nye subnettet blir rett og slett ikkje frakta. I eit rutebasert design tek eit grensesnitt imot trafikken og rutetabellen avgjer, noko som gjer det å leggje til eit prefiks til ei ruteendring i staden for ein ny tunneforhandling.

StrongSwan viser begge visingane direkte, og å lese dei saman er måten å finne ut kva modell du faktisk rulla ut.

swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'

Ei veljarliste som utelèt prefikset du treng, forklarer feilen utan noko pakkefangst, og ei rute som peikar på feil grensesnitt forklarer speilfeilen på veg tilbake. Les begge før du forhandlar på nytt, for ei nøkkelfornying legg ikkje til ein veljar du aldri konfigurerte.

Planlegg adresseringa før tunnelen

Overlappande område er designfeilen som ikkje kan rettast med konfigurasjon. Viss begge stadene brukar 192.168.1.0/24, har ein vert som treng 192.168.1.50 to kandidatar og ingen måte å velje. Tunnelen vil autentisere, tryggleiksassosiasjonane vil bli oppretta, og ruteavgjerda blir likevel feil eller tvitydig.

Vel eitt av tre ærlege alternativ: omnummerer den eine staden, omset det overlappande området ved gatewayen slik at kvar side ser eit eige prefiks, eller gje opp direkte ruting for desse vertane og publiser tenesta på ein annan måte. Kvar har ein kostnad, og den første er vanlegvis billegast over ein toårsperiode. Bestem før tunnelen finst, for etterpå rører endringa kvar eining som har den gamle adressa.

Løys også MTU-spørsmålet tidleg. Ein tunnel reduserer den nyttige lasta, og eit design som byggjer på fragmentering oppfører seg annleis enn eit som festar MSS ved gatewayane.

Vidaresending og policy ligg utanfor tunnelen

Gatewayen må vere viljug til å vidaresende pakkar mellom tunnegrensesnittet og LAN-grensesnittet, og begge retningane treng policy som tillèt tenesta. På Linux er dette to separate innstillingar, i tillegg til brannmurreglane som avgjer om den vidaresende straumen i det heile er tillaten.

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 ACCEPT

Den mottakande verten legg til eit tredje lag: hans eigen brannmur må framleis godta ein klient frå det fjerne subnettet. Ein filtenar som berre tillèt sitt lokale /24, vil avvise vidaresend trafikk frå 10.20.0.7, uansett kor sunn tunnelen ser ut, og den avvisinga blir lett lesen som ein rutefeil.

Test frå ein vert, ikkje frå gatewayen

Ein ping som gatewayen sjølv sender, kan følgje ei anna kjeldeadresse og ein annan policy enn vidaresend brukartrafikk. Det gjer han til ein svak test og av og til ein misvisande: han lukkast medan applikasjonen feilar, eller feilar medan applikasjonen verkar.

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/null

Bruk ein ekte vert, ei ekte kjeldeadresse og den ekte protokollen applikasjonen brukar. Les deretter returvegen separat, fordi ei fungerande framoverretning utan returrute gjev eit tidsavbrot som ser identisk ut med ein blokkert teneste.

Vel designet etter spørsmålet du svarar på: knyter du saman nettverk, eller slepp du inn einingar? Alt anna, også kva leverandør du konfigurerer, følgjer av det svaret.