Antwoord van werf-tot-werf-VPN gaan nie deur die tonnel nie

Ek het ’n oggend spandeer aan ’n tonnel wat skoon opgekom het en verkeer in presies een rigting beweeg het: die tak kon die lêerserver by die hoofkwartier bereik, en elke verbinding wat van die hoofkwartier na die tak oopgemaak is, het by die eerste SYN doodgegaan. Die SAs was op, die tonneltellers het geklim, en die handskud was nooit die probleem nie. Die antwoord is ergens heen gestuur waar die tonnel dit nie dek nie, en daardie keuse behoort aan die ander kant. ’n Werf-tot-werf-VPN dra net pakkette wat ’n gasheer aan die poort oorhandig, en elke gasheer maak daardie keuse afsonderlik, in elke rigting, uit sy eie roetetabel.

Beide rigtings word afsonderlik geroute

IP hou geen geheue van ’n gesprek se rigting nie. Elke gasheer wat ’n pakket stuur, doen sy eie langste-voorvoegsel-soektog, kies een volgende sprong en vergeet die besluit. Die versoek en die antwoord is twee onverwante pakkette wat toevallig aan dieselfde verbinding behoort, en die tonnel is een sprong wat enigeen van hulle mag gebruik of nie. Niks in die IKE-uitruiling leer die afgeleë bediener hoe om jou subnet te bereik nie; die onderhandeling kom net ooreen watter voorvoegsels geïnkripteer mag word.

Daardie ooreenkoms is die tweede hek. Op strongSwan is die verkeerskeurders leftsubnet en rightsubnet, en ’n pakket waarvan die bron of bestemming buite die onderhandelde paar val, word nie geïnkripteer nie, wat die roetetabel ook al sê. ’n Voorvoegsel wat in die tonnel geroute word maar in die keurders ontbreek, is ’n stil eenrigting-mislukking: die roete lyk reg, die pakket verlaat steeds in die oopte of word laat val, en net die charon-log kla.

Die afgeleë gasheer weet niks van jou tonnel nie

Binne die afgeleë LAN is die antwoord ’n gewone pakket wat aan jou kliënt gerig is. Die bestemmingsgasheer sien geen IPsec-kop nie en het geen rede om die VPN-poort te verkies nie; hy soek jou voorvoegsel op, vind niks meer spesifiek as sy verstekroete nie en volg dit. As die verstek na ’n kern-firewall wys, het die firewall óf ’n roete terug in die tonnel óf nie. Wanneer dit nie het nie, kry jy ’n stil wegval, ’n ICMP onbereikbaar, of ’n antwoord wat deur die internetgerigte koppelvlak vertrek en sterf.

’n Tweede koppelvlak is genoeg om dit te breek selfs wanneer ’n roete wel bestaan. ’n NAS met ’n bestuurskoppelvlak op ’n ander VLAN, ’n bediener met ’n rugsteun-opstuurkoppeling, ’n beleidsreël wat een bronreeks in ’n tweede tabel stuur: enigeen van hierdie kan die antwoord vang. Op Linux openbaar ip rule show en ip route show table all reëls en tabelle wat die versteklys verberg.

Lees die besluit op die boks wat die antwoord stuur

Vra die kern voor jy enigiets verander, en gee dit die bronadres, want bronafhanklike reëls verander die antwoord.

ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"

Die uitset noem die uitgaande koppelvlak en die volgende sprong. As die koppelvlak nie die een is wat na die VPN-poort wys nie, het jy die fout gevind, en die oorblywende werk is om te kies waar die roete hoort. ’n Ping vanaf die poort bewys hier min: dit antwoord met ’n adres wat die afgeleë gasheer kan plaas, nie jou skootrekenaar se adres nie.

Op Windows is die ekwivalente Find-NetRoute -RemoteIPAddress 10.10.5.10 vir die besluit en Get-NetRoute vir die tabel. ’n Roete wat met New-NetRoute bygevoeg word en ’n hoër metriek as die verstek dra, verloor stilweg, so lees die metriekkolom, nie die inskrywing nie. Bevestig dan met pakkette: tcpdump -ni any "host 10.10.5.10 and tcp port 445" op die afgeleë LAN-koppelvlak wys die versoek, en dieselfde filter aan die tonnelkant wys of ’n antwoord teruggekom het. Versoek sigbaar met geen antwoord beteken die antwoord is elders geroute of laat val; ’n antwoord op die verkeerde koppelvlak gee jou die skuldige voordat jy aan ’n roete raak.

Wanneer die bediener se poort nie die VPN-eindpunt is nie

Baie terreine sit ’n firewall tussen die bedieners en die konsentrator. Daardie firewall stuur die antwoord aan, so dit het ’n roete vir jou kliëntvoorvoegsel nodig wat na die VPN-poort wys, en aanstuurbeleid in beide rigtings. Toestandvaste toestelle maak dit erger: die versoek het die firewall vanaf ’n LAN-gasheer oorgesteek wat dit toegelaat het, die antwoord kom nou uit ’n ander rigting, en die verbindingsnasporingsinskrywing pas nie meer nie, so die pakket word as ongeldig weggegooi eerder as geweier. Dis hoekom die beleidslog leeg lyk terwyl verkeer verdwyn.

Die poort het sy eie tweede filter. Linux se tru-roete-filtering laat pakkette val wie se bron nie deur die koppelvlak bereikbaar is waarop hulle aangekom het nie, wat presies die vorm van ’n wettige asimmetriese terugroete is. Die strongSwan-aanstuurriglyne vra net.ipv4.ip_forward en ’n verslapte net.ipv4.conf.all.rp_filter om daardie rede. ’n Streng waarde van 1 op enige van die twee poorte breek ’n korrekte roete stilweg, en nstat -az wys die wegvalle as jy weet om te kyk.

Roete of vertaal, en verifieer dan in beide rigtings

Die twee herstellings is nie gelykwaardig nie. Om ’n roete by te voeg hou die kliëntadres ongeskonde, so brongebaseerde reëls, ouditlogs en toepassings wat die oproeper aanteken, bly werk; die prys is dat elke sprong wat die besluit neem die roete nodig het, wat meer plekke is om verkeerd te wees. Vermomming op die afgeleë poort laat die terugroete tot een sprong ineenkrimp, want die antwoord is nou aan die poort self gerig, en verberg watter kliënt wat gedoen het.

iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADE

Kies dit doelbewus: sodra kliënte as die poortadres verskyn, hou brongebaseerde ACL’s op om hulle van mekaar te onderskei, en conntrack moet die kartering hou sodat die antwoord terug in die tonnel herskryf word. As die keurders die kliëntvoorvoegsel steeds uitsluit, verander NAT niks, want die versoek het nooit die tonnel betree nie.

Voordat jy dit reg noem, bevestig vier dinge in volgorde: die roete op die gasheer wat die antwoord stuur, die roete op elke sprong wat dit aanstuur, die keurders wat beide voorvoegsels dek, en ’n opname wat wys die antwoord betree die tonnel met die bron wat jy verwag. Herhaal dan die toets vanaf die ander terrein. Een rigting wat werk is ’n half-oop ontwerp, en die tweede rigting misluk gewoonlik om ’n ander rede as die een wat jy pas herstel het.