Fjärranvändare når inte den andra platsen genom VPN-hubben

En fjärranvändare ansluter till hubben, når filservern på hubbens eget LAN och allt ser friskt ut. Sedan öppnar hen en delning på 10.20.0.50 på huvudkontoret, som hubben når via en separat site-till-site-tunnel, och det tar timeout. Båda tunnlarna är uppe och båda räknarna stiger, så ingen tunnel är trasig. Att korsa hubben är tre routingbeslut på tre enheter, och en tunnel bär bara de prefix den byggdes för. Här är ordningen jag kontrollerar, och kommandot som visar om varje steg stämmer.

Transit kräver tre uppslagningar, inte en tunnel

Varje enhet gör sin egen längsta-prefix-matchning och glömmer den. Laptopen måste skicka 10.20.0.50 in i tunneln och inte till sin lokala router. Hubben måste ta emot ett paket som kom in på fjärråtkomstgränssnittet och lämna det till site-till-site-gränssnittet. Huvudkontoret måste skicka ett svar för användarens adress tillbaka genom tunneln. Vilket som helst av de tre felen ser likadant ut i webbläsaren: tystnad.

Det är därför test av varje tunnel för sig bevisar så lite. Ping mot hubbens LAN-adress övar det första beslutet, och ping mot hubben från huvudkontoret övar det tredje. Paketet som misslyckas har användarpoolen som källa och den andra platsen som mål, så skriv ned de prefixen först. Här är poolen 10.80.0.0/24, hubbens LAN är 10.10.0.0/24 och huvudkontoret är 10.20.0.0/24.

Knuffa det avlägsna prefixet till fjärrklienten

På en OpenVPN fjärråtkomstserver lär sig klienten vägar vid anslutning. Utan push skickar en klient med delad tunnel 10.20.0.50 till sin egen gateway och paketet kommer aldrig in i tunneln.

push "route 10.20.0.0 255.255.255.0"

En knuffad väg träder i kraft när klienten ansluter, så en användare som stannar online ser ingenting förrän hen återansluter. Kontrollera på klienten: ip route get 10.20.0.50 i Linux, route print i Windows. Utdata bör namnge tunnelns gränssnitt.

push hjälper inte hubben. Det är ett meddelande till klienten, inte en väg på servern och inte ett tillstånd att vidarebefordra, så en hubb med en perfekt push-rad tappar ändå flödet en hopp senare. Det är det vanliga skälet till att folk drar slutsatsen att push misslyckades.

Ge hubben en riktig utgående väg

Hubben behöver sitt eget nästa hopp för huvudkontorets prefix. På en routad tunnel är det en vanlig väg genom site-till-site-gränssnittet, och ett kommando visar både den valda vägen och den valda källan:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Där site-till-site-benet självt är OpenVPN kan vägen leva i den konfigurationen med motpartens tunneladress som gateway: route 10.20.0.0 255.255.255.0 172.30.0.2. Gatewayen är inte valfri. Om du utelämnar den faller nästa hopp till ett implementeringsstandardvärde, som skiljer sig mellan en klient med en fjärranslutning och en hubb med flera motparter.

Policybaserad IPsec är annorlunda: hubbens kärna skickar paketet till sin vanliga LAN-gateway och policyn fångar det på väg ut, så en tunnelväg antingen gör ingenting eller leder trafiken förbi policyn. Titta på källan i kommandot ovan, eftersom 10.10.0.1 i stället för pooladressen betyder att kärnan valde en adress som andra sidan kommer att avvisa. Inte heller iroute är svaret; det berättar för servern vilken klient som äger ett subnät bakom sin egen tunnel, inte vart trafik för en tredje plats ska skickas.

Utöka andra sidan till användarpoolen

Huvudkontoret täcker redan hubbens LAN, 10.10.0.0/24. Användarpoolen är ett andra prefix och måste också finnas i selektorerna, annars täcker ingen policy ett svar riktat till 10.80.0.25. Varje motpart namnger samma par av prefixmängder från sin egen sida:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

local_ts på en enhet är remote_ts på den andra. Kopiera hubbens block till huvudkontoret och paret vänds, så den underordnade SA:n kommer aldrig upp.

Den äldre syntaxen ipsec.conf använder leftsubnet separerade med kommatecken. Den körande säkerhetsassociationen behåller de selektorer den förhandlade, så återupprätta tunneln efter ändringen. En selektor som ändrades klockan 10:00 och testades mot en SA som kom upp klockan 09:40 misslyckas fortfarande, medan konfigurationsfilen ser korrekt ut hela tiden.

Kontrollera sedan sista hoppet. ip route get 10.80.0.25 på fjärränden bör peka in i tunneln. Om tjänsten använder en LAN-router som sin standardgateway behöver den routern också returvägen, annars dör svaret där. Att köra tcpdump -ni eth1 host 10.80.0.25 på det segmentet visar om svaret ens lämnade ändpunkten.

Tillåt flödet i hubben

Vidarebefordran måste vara påslagen och vägen tillåten. Begränsa reglerna till de två prefixen i stället för att acceptera allt mellan gränssnitten.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

Omvänd väg-filtrering är det tysta felet bredvid: när de två benen ligger på olika gränssnitt kan rp_filter=1 släppa svaret medan tillåtelseregelns räknare aldrig rör sig. Jämför iptables -vnL FORWARD före och efter ett försök. En regel som aldrig ökar nås inte, så titta ett lager lägre i stället för att skriva om den.

Om bara en grupp behöver transit, lägg vägen i en fil per klient under client-config-dir i stället för att bredda den globala push:en. Source NAT i hubben tar också bort behovet av en returväg på andra sidan, men den döljer användarens adress, så loggarna på fjärrplatsen och adressbaserade regler slutar skilja användare åt.

Verifiera från klienten och rulla sedan tillbaka i omvänd ordning

Testa en TCP-port, inte bara ICMP, eftersom ping kan passera medan tjänsten förblir blockerad. nc -vz 10.20.0.50 445 och traceroute -n 10.20.0.50 från klienten visar om det andra hoppet är hubbens tunneladress. I hubben tcpdump -ni tun0 host 10.20.0.50 och samma filter på site-till-site-gränssnittet: en begäran på båda utan svar på någon flyttar problemet till andra sidan.

Testa sedan något som måste förbli blockerat. Om en värd som poolen aldrig bör nå också svarar har du öppnat mer än transit och bör snäva in reglerna. En hubb som vidarebefordrar allt till varje eker klarar det första testet och misslyckas med det andra.

Håll en återställningslista, eftersom fyra objekt ändrades och tre är lätta att glömma: den knuffade vägen, hubbens väg, selektorerna och brandväggsreglerna. Ångra dem i omvänd ordning, återupprätta SA:n och låt en användare ansluta igen. En delvis återställning lämnar en väg som pekar på en tunnel som inte längre matchar, och det är svårare att läsa än den ursprungliga tystnaden. OpenVPN 2.6-handboken dokumenterar push, route och iroute för din version.