Site-til-site kontra fjernadgang via VPN: hvad de to forbinder

Begge design kaldes en VPN, og de løser forskellige problemer. En site-til-site-tunnel forbinder to gateways, så hver vært bag dem kan nå tilladte adresser på den anden side uden at installere noget. En fjernadgangstunnel forbinder enkelte enheder til et netværk, én klient ad gangen. Sammenligningen er vigtig, fordi de fleste udrulningsfejl opstår ved at konfigurere det ene design og forvente det andets adfærd, og symptomet er normalt en timeout på en tjeneste, som tunnelen faktisk nåede.

To designs, to grænser

Ingen af designene udvider et LAN-broadcastdomæne. Enheder på den anden side vises ikke på en lokal opdagelsesliste, og at forvente det er den første antagelse, man skal slippe. Private DNS-navne, som du bevidst offentliggør, er mere forudsigelige end enhver opdagelsesprotokol og overlever et skift af leverandør.

Tag 10.10.0.0/24 på det ene sted og 10.20.0.0/24 på det andet. Gateway A har brug for en rute eller en trafikvælger, der sender præfikset 10.20.0.0/24 ind i tunnelen, og gateway B har brug for det spejlvendte billede. Værter på begge sider bruger derefter almindelig IP-forbindelse og opdager aldrig, at der findes en tunnel. Den usynlighed er funktionen, og det er også derfor, fejl ser ud som almindelige netværksfejl snarere end tunnelfejl.

Politikbaseret og rutebaseret er ikke den samme tunnel

I en politikbaseret IPsec-udrulning definerer de forhandlede trafikvælgere præcis, hvilke kilde- og destinationspar der er beskyttet. Hvis der dukker et nyt undernet op bag en gateway, og ingen vælger dækker det, forbliver tunnelen oppe, og det nye undernet bæres simpelthen ikke. I et rutebaseret design modtager et interface trafikken, og routingtabellen beslutter, hvilket gør tilføjelsen af et præfiks til en routingændring i stedet for en genforhandling af tunnelen.

StrongSwan viser begge synspunkter direkte, og ved at læse dem sammen kan du afgøre, hvilken model du faktisk har udrullet.

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

En vælgerliste, der udelader det præfiks, du har brug for, forklarer fejlen uden nogen pakkefangst, og en rute, der peger på det forkerte interface, forklarer den spejlvendte fejl på vejen tilbage. Læs begge, før du genforhandler noget, for en nøglefornyelse tilføjer ikke en vælger, du aldrig har konfigureret.

Planlæg adresseringen før tunnelen

Overlappende områder er den designfejl, der ikke kan rettes med konfiguration. Hvis begge steder bruger 192.168.1.0/24, har en vært, der har brug for 192.168.1.50, to kandidater og ingen måde at vælge. Tunnelen godkender, sikkerhedsassociationerne oprettes, og routingbeslutningen vil alligevel være forkert eller tvetydig.

Vælg en af tre ærlige muligheder: omnummerer det ene sted, oversæt det overlappende område ved gatewayen, så hver side ser et forskelligt præfiks, eller opgiv direkte routing for de værter og offentliggør tjenesten på en anden måde. Hver har en pris, og den første er normalt den billigste over en toårig horisont. Beslut det, før tunnelen findes, for bagefter rammer ændringen hver enhed med den gamle adresse.

Løs også MTU-spørgsmålet tidligt. En tunnel reducerer den brugbare nyttelast, og et design, der bygger på fragmentering, opfører sig anderledes end et, der fastlåser MSS ved gatewayerne.

Videresendelse og politik ligger uden for tunnelen

Gatewayen skal være villig til at videresende pakker mellem tunnelinterfacet og LAN-interfacet, og begge retninger har brug for politik, der tillader tjenesten. På Linux er det to separate indstillinger plus firewallreglerne, som afgør, om den videresendte strøm overhovedet er tilladt.

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 modtagende vært tilføjer et tredje lag: dens egen firewall skal stadig acceptere en klient fra det fjerne undernet. En fileserver, der kun tillader sit lokale /24, afviser videresendt trafik fra 10.20.0.7, uanset hvor sund tunnelen ser ud, og den afvisning læses let som en routingfejl.

Test fra en vært, ikke fra gatewayen

En ping, der sendes af gatewayen selv, kan følge en anden kildeadresse og en anden politik end videresendt brugertrafik. Det gør den til en svag test og af og til en misvisende: den lykkes, mens applikationen fejler, eller fejler, mens applikationen 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/null

Brug en rigtig vært, en rigtig kildeadresse og den rigtige protokol, som applikationen bruger. Læs derefter svarvejen separat, fordi en fungerende fremadgående retning uden returrute giver en timeout, der ser identisk ud med en blokeret tjeneste.

Vælg designet efter det spørgsmål, du besvarer: forbinder du netværk, eller optager du enheder? Alt andet, inklusive hvilken leverandør du konfigurerer, følger af det svar.