VPN mellan platser eller fjärråtkomst: vad de två kopplar ihop

Båda lösningarna kallas VPN och löser olika problem. En tunnel mellan platser kopplar ihop två gateways, så varje värd bakom dem kan nå tillåtna adresser på andra sidan utan att installera något. En fjärråtkomsttunnel kopplar ihop enskilda enheter med ett nätverk, en klient i taget. Jämförelsen är viktig eftersom de flesta utrullningsfel uppstår när man konfigurerar den ena lösningen och förväntar sig den andras beteende, och symptomet är oftast en tidsgräns på en tjänst som tunneln faktiskt nådde.

Två lösningar, två gränser

Ingen av lösningarna utökar en LAN-broadcastdomän. Enheter på andra sidan visas inte i en lokal upptäcktslista, och att förvänta sig det är det första antagandet man måste släppa. Privata DNS-namn som du medvetet publicerar är mer förutsägbara än något upptäcktsprotokoll och överlever ett byte av leverantör.

Ta 10.10.0.0/24 på den ena platsen och 10.20.0.0/24 på den andra. Gateway A behöver en rutt eller en trafikväljare som skickar prefixet 10.20.0.0/24 in i tunneln, och gateway B behöver dess spegelbild. Värdarna på båda sidor använder då vanlig IP-anslutning och får aldrig veta att det finns en tunnel. Den osynligheten är funktionen, och det är också därför fel ser ut som vanliga nätverksfel i stället för tunnelfel.

Policybaserat och ruttbaserat är inte samma tunnel

I en policybaserad IPsec-utrullning definierar de förhandlade trafikväljarna exakt vilka käll- och målpar som skyddas. Om ett nytt subnät dyker upp bakom en gateway och ingen väljare täcker det, stannar tunneln uppe och det nya subnätet fraktas helt enkelt inte. I en ruttbaserad design tar ett gränssnitt emot trafiken och routningstabellen avgör, vilket gör att det att lägga till ett prefix blir en ruttändring i stället för en ny tunnelförhandling.

StrongSwan visar båda vyerna direkt, och att läsa dem tillsammans är sättet att avgöra vilken modell du faktiskt rullade ut.

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

En väljarlista som utelämnar prefixet du behöver förklarar felet utan någon paketinsamling, och en rutt som pekar på fel gränssnitt förklarar spegelfelet på vägen tillbaka. Läs båda innan du förhandlar om något igen, för en nyckeluppdatering lägger inte till en väljare du aldrig konfigurerade.

Planera adresseringen före tunneln

Överlappande intervall är det designfel som inte kan rättas med konfiguration. Om båda platserna använder 192.168.1.0/24 har en värd som behöver 192.168.1.50 två kandidater och inget sätt att välja. Tunneln autentiserar, säkerhetsassociationerna upprättas, och routningsbeslutet blir ändå fel eller tvetydigt.

Välj ett av tre ärliga alternativ: numrera om den ena platsen, översätt det överlappande intervallet vid gatewayen så att varje sida ser ett eget prefix, eller avstå från direkt routning för de värdarna och publicera tjänsten på annat sätt. Varje val har en kostnad, och det första är oftast billigast över en tvåårsperiod. Bestäm innan tunneln finns, för efteråt berör ändringen varje enhet som har den gamla adressen.

Lös också MTU-frågan tidigt. En tunnel minskar den användbara nyttolasten, och en design som bygger på fragmentering beter sig annorlunda än en som låser MSS vid gatewayerna.

Vidarebefordran och policy ligger utanför tunneln

Gatewayen måste vara villig att vidarebefordra paket mellan tunnelgränssnittet och LAN-gränssnittet, och båda riktningarna behöver policy som tillåter tjänsten. På Linux är det två separata inställningar, plus brandväggsreglerna som avgör om det vidarebefordrade flödet alls är tillåtet.

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 mottagande värden lägger till ett tredje lager: dess egen brandvägg måste fortfarande acceptera en klient från det avlägsna subnätet. En filserver som bara tillåter sitt lokala /24 kommer att avvisa vidarebefordrad trafik från 10.20.0.7, hur frisk tunneln än ser ut, och den avvisningen läses lätt som ett routningsfel.

Testa från en värd, inte från gatewayen

En ping som gatewayen själv skickar kan följa en annan källadress och en annan policy än vidarebefordrad användartrafik. Det gör den till ett svagt test och ibland ett missvisande: den lyckas medan applikationen misslyckas, eller misslyckas medan applikationen fungerar.

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

Använd en riktig värd, en riktig källadress och det riktiga protokoll som applikationen använder. Läs sedan returvägen separat, eftersom en fungerande framåtriktning utan returrutt ger en tidsgräns som ser identisk ut med en blockerad tjänst.

Välj lösningen efter frågan du besvarar: kopplar du ihop nätverk eller tar du emot enheter? Allt annat, inklusive vilken leverantör du konfigurerar, följer av det svaret.