Afstandgebruikers bereik nie die tweede perseel deur die VPN-hub nie

'n Afstandgebruiker koppel aan die hub, bereik die lêerbediener op die hub se eie LAN, en alles lyk gesond. Dan maak hy 'n gedeelte op 10.20.0.50 by die hoofkwartier oop, wat die hub oor 'n aparte perseel-tot-perseel-tonnel bereik, en dit verstryk. Albei tonnels is op en albei tellers klim, so nie een tonnel is stukkend nie. Om die hub oor te steek is drie roetebesluite op drie toestelle, en 'n tonnel dra net die prefikse waarvoor dit gebou is. Hier is die volgorde wat ek nagaan, en die opdrag wat wys of elke stap waar is.

Deurgang vereis drie opsoeke, nie een tonnel nie

Elke toestel doen sy eie langste-prefiks-passing en vergeet dit. Die skootrekenaar moet 10.20.0.50 in die tonnel stuur eerder as na sy plaaslike roeteerder. Die hub moet 'n pakkie wat op die afstandtoegang-koppelvlak aangekom het, aan die perseel-tot-perseel-koppelvlak oorhandig. Die hoofkwartier moet 'n antwoord vir die gebruiker se adres terug deur die tonnel stuur. Enige een van die drie wat misluk, lyk dieselfde in die blaaier: stilte.

Dit is hoekom die toets van elke tonnel alleen so min bewys. Om die hub se LAN-adres te ping, oefen die eerste besluit, en om die hub van die hoofkwartier af te ping, oefen die derde. Die pakkie wat misluk, het die gebruikerspoel as bron en die tweede perseel as bestemming, so skryf daardie prefikse eerste neer. Hier is die poel 10.80.0.0/24, die hub se LAN is 10.10.0.0/24 en die hoofkwartier is 10.20.0.0/24.

Stuur die verre prefiks na die afstandkliënt

Op 'n OpenVPN afstandtoegang-bediener leer die kliënt roetes by verbindingstyd. Sonder 'n push stuur 'n kliënt met 'n verdeelde tonnel 10.20.0.50 na sy eie poort en die pakkie gaan nooit die tonnel in nie.

push "route 10.20.0.0 255.255.255.0"

’n Gepusde roete land wanneer die kliënt koppel, so 'n gebruiker wat aanlyn bly, sien niks tot hy weer koppel. Verifieer op die kliënt: ip route get 10.20.0.50 op Linux, route print op Windows. Die uitvoer moet die tonnel-koppelvlak noem.

Die push help nie die hub nie. Dit is 'n boodskap aan die kliënt, nie 'n roete op die bediener nie en nie 'n toestemming om deur te stuur nie, so 'n hub met die perfekte push-reël laat die vloei steeds een hop later val. Dit is die gewone rede waarom mense aflei die push het misluk.

Gee die hub 'n werklike uitgangroete

Die hub het sy eie volgende hop vir die hoofkwartier-prefiks nodig. Op 'n geroteerde tonnel is dit 'n gewone roete deur die perseel-tot-perseel-koppelvlak, en een opdrag wys beide die gekose roete en die gekose bron:

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

Waar die perseel-tot-perseel-been self OpenVPN is, kan die roete in daardie konfigurasie woon met die eweknie se tonneladres as poort: route 10.20.0.0 255.255.255.0 172.30.0.2. Die poort is nie opsioneel nie. Laat dit uit en die volgende hop val na 'n implementeringsverstek, wat verskil tussen 'n enkel-afstand-kliënt en 'n hub met baie eweknieë.

Beleid-gebaseerde IPsec is anders: die hub se kern stuur die pakkie na sy normale LAN-poort en die beleid vang dit op pad uit, so 'n tonnelroete doen óf niks óf stuur verkeer verby die beleid. Let op die bron in die opdrag hierbo, want 10.10.0.1 in plaas van die poeladres beteken die kern het 'n adres gekies wat die verre kant sal verwerp. iroute is ook nie die antwoord nie; dit vertel die bediener watter kliënt 'n subnet agter sy eie tonnel besit, nie waarheen om verkeer vir 'n derde perseel te stuur nie.

Breid die verre kant uit na die gebruikerspoel

Die hoofkwartier dek al die hub se LAN, 10.10.0.0/24. Die gebruikerspoel is 'n tweede prefiks en moet ook in die keurders wees, anders dek geen beleid 'n antwoord wat aan 10.80.0.25 gerig is nie. Elke eweknie noem dieselfde paar prefiksstelle van sy eie kant af:

# 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

'n Toestel se local_ts is die ander s'n remote_ts. Kopieer die hub-blok na die hoofkwartier en die paar is omgekeer, so die kind-SA kom nooit op nie.

Die ouer ipsec.conf sintaks gebruik 'n komma-geskeide leftsubnet. Die lopende sekuriteitsassosiasie hou die keurders wat dit onderhandel het, so herstel die tonnel ná die wysiging. 'n Keurder wat om 10:00 verander is en teen 'n SA wat om 09:40 opgekom het getoets word, misluk steeds, terwyl die konfigurasielêer deurgaans korrek lyk.

Gaan dan die laaste hop na. ip route get 10.80.0.25 op die verre eindpunt moet in die tonnel wys. As die diens 'n LAN-roeteerder as sy verstekpoort gebruik, het daardie roeteerder ook die terugroete nodig, anders sterf die antwoord daar. Om tcpdump -ni eth1 host 10.80.0.25 op daardie segment te laat loop, wys of die antwoord die eindpunt hoegenaamd verlaat het.

Laat die vloei by die hub toe

Deurvoer moet geaktiveer wees en die pad toegelaat. Beperk die reëls tot die twee prefikse eerder as om alles tussen die koppelvlakke te aanvaar.

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

Terugpad-filtering is die stille mislukking daarnaas: met die twee bene op verskillende koppelvlakke, kan rp_filter=1 die antwoord laat val terwyl die aanvaardingsreël se teller nooit beweeg nie. Vergelyk iptables -vnL FORWARD voor en ná 'n poging. 'n Reël wat nooit inkrementeer nie, word nie bereik nie, so kyk 'n laag laer eerder as om dit te herskryf.

As net een groep deurgang nodig het, sit die roete in 'n per-kliënt-lêer onder client-config-dir eerder as om die globale push te verbreed. Bron-NAT op die hub verwyder ook die nodigheid vir 'n verre-kant-terugroete, maar dit verberg die gebruiker se adres, so die verre perseel se logs en adresgebaseerde reëls hou op om gebruikers te onderskei.

Verifieer van die kliënt af, en rol dan in omgekeerde volgorde terug

Toets 'n TCP-poort, nie net ICMP nie, want 'n ping kan deurgaan terwyl die diens geblokkeer bly. nc -vz 10.20.0.50 445 en traceroute -n 10.20.0.50 van die kliënt af wys of die tweede hop die hub se tonneladres is. Op die hub, tcpdump -ni tun0 host 10.20.0.50 en dieselfde filter op die perseel-tot-perseel-koppelvlak: 'n versoek op beide met geen antwoord op enige van die twee skuif die probleem na die verre kant.

Toets dan iets wat geblokkeer moet bly. As 'n gasheer wat die poel nooit behoort te bereik nie, ook antwoord, het jy meer as deurgang oopgemaak en moet jy die reëls vernou. 'n Hub wat alles aan elke spaak deurstuur, slaag die eerste toets en faal die tweede.

Hou 'n terugrollys, want vier objekte het verander en drie is maklik om te vergeet: die gepusde roete, die hub se roete, die keurders en die brandmuurreëls. Maak hulle in omgekeerde volgorde ongedaan, herstel die SA, en laat een gebruiker weer koppel. 'n Gedeeltelike terugrol laat 'n roete wat na 'n tonnel wys wat nie meer pas nie, wat moeiliker lees as die oorspronklike stilte. Die OpenVPN 2.6-handleiding dokumenteer push, route en iroute vir jou weergawe.