Ni all defnyddwyr o bell gyrraedd yr ail safle trwy’r canolbwynt VPN

Mae defnyddiwr o bell yn cysylltu â’r canolbwynt, yn cyrraedd y gweinydd ffeil ar LAN y canolbwynt ei hun, ac mae popeth yn edrych yn iach. Yna maen nhw’n agor rhannu ar 10.20.0.50 yn y pencadlys, y mae’r canolbwynt yn ei gyrraedd dros dwnnel ar wahân rhwng safleoedd, ac mae’n rhedeg allan o amser. Mae’r ddau dwnnel i fyny ac mae’r ddau gyfrifydd yn dringo, felly nid yw’r un twnnel wedi torri. Croesi’r canolbwynt yw tair penderfyniad llwybro ar dri dyfais, a dim ond y rhagddodiaid y cafodd ei adeiladu ar eu cyfer y mae twnnel yn eu cario. Dyma’r drefn yr wyf yn ei gwirio, a’r gorchymyn sy’n dangos a yw pob cam yn wir.

Mae tramwy angen tri chwiliad, nid un twnnel

Mae pob dyfais yn gwneud ei chydweddiad rhagddodiad hiraf ei hun ac yn ei anghofio. Rhaid i’r gliniadur anfon 10.20.0.50 i’r twnnel yn hytrach na’i lwybrydd lleol. Rhaid i’r canolbwynt gymryd pecyn a gyrhaeddodd ar ryngwyneb mynediad o bell a’i drosglwyddo i ryngwyneb rhwng safleoedd. Rhaid i’r pencadlys anfon ateb ar gyfer cyfeiriad y defnyddiwr yn ôl trwy’r twnnel. Mae methiant unrhyw un o’r tri yn edrych yr un fath yn y porwr: distawrwydd.

Dyna pam mae profi pob twnnel ar ei ben ei hun yn profi cyn lleied. Mae pingio cyfeiriad LAN y canolbwynt yn ymarfer y penderfyniad cyntaf, ac mae pingio’r canolbwynt o’r pencadlys yn ymarfer y trydydd. Mae gan y pecyn sy’n methu y gronfa defnyddwyr yn ffynhonnell a’r ail safle yn gyrchfan, felly nodwch y rhagddodiaid hynny gyntaf. Yma’r gronfa yw 10.80.0.0/24, LAN y canolbwynt yw 10.10.0.0/24 a’r pencadlys yw 10.20.0.0/24.

Gwthiwch y rhagddodiad pell i’r cleient o bell

Ar OpenVPN weinydd mynediad o bell mae’r cleient yn dysgu llwybrau ar adeg cysylltu. Heb push, mae cleient â thwnnel holltiedig yn anfon 10.20.0.50 i’w borth ei hun ac nid yw’r pecyn byth yn mynd i mewn i’r twnnel.

push "route 10.20.0.0 255.255.255.0"

Mae llwybr a wthiwyd yn dod i rym pan fydd y cleient yn cysylltu, felly nid yw defnyddiwr sy’n aros ar-lein yn gweld dim nes iddo ailgysylltu. Gwiriwch ar y cleient: ip route get 10.20.0.50 ar Linux, route print ar Windows. Dylai’r allbwn enwi rhyngwyneb y twnnel.

Nid yw’r push yn helpu’r canolbwynt. Neges i’r cleient yw hi, nid llwybr ar y gweinydd ac nid caniatâd i anfon ymlaen, felly mae canolbwynt â llinell push berffaith yn dal i ollwng y llif un naid yn hwyrach. Dyna’r rheswm arferol dros ddod i’r casgliad bod y push wedi methu.

Rhowch lwybr allan go iawn i’r canolbwynt

Mae ar y canolbwynt angen ei naid nesaf ei hun ar gyfer rhagddodiad y pencadlys. Ar dwnnel wedi’i lwybro mae hwnnw’n llwybr cyffredin trwy ryngwyneb y safleoedd, ac mae un gorchymyn yn dangos y llwybr a ddewiswyd a’r ffynhonnell a ddewiswyd:

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

Pan fo’r goes rhwng safleoedd ei hun yn OpenVPN, gall y llwybr fyw yn y ffurfweddiad hwnnw gyda chyfeiriad twnnel y cymar fel porth: route 10.20.0.0 255.255.255.0 172.30.0.2. Nid yw’r porth yn ddewisol. Gadewch ef allan ac mae’r naid nesaf yn disgyn i ragosodiad gweithrediad, sy’n wahanol rhwng cleient un cymar a chanolbwynt â sawl cymar.

Mae IPsec sy’n seiliedig ar bolisi yn wahanol: mae cnewyllyn y canolbwynt yn anfon y pecyn i’w borth LAN arferol ac mae’r polisi yn ei ddal ar y ffordd allan, felly mae llwybr twnnel naill ai’n gwneud dim neu’n llywio traffig heibio’r polisi. Gwyliwch y ffynhonnell yn y gorchymyn uchod, oherwydd mae 10.10.0.1 yn lle cyfeiriad y gronfa yn golygu bod y cnewyllyn wedi dewis cyfeiriad y bydd yr ochr bell yn ei wrthod. iroute yw’r ateb chwaith; mae’n dweud wrth y gweinydd pa gleient sy’n berchen ar isrwydwaith y tu ôl i’w dwnnel ei hun, nid i ble i anfon traffig ar gyfer trydydd safle.

Estynnwch yr ochr bell at y gronfa defnyddwyr

Mae’r pencadlys eisoes yn cwmpasu LAN y canolbwynt, 10.10.0.0/24. Mae’r gronfa defnyddwyr yn ail ragddodiad ac mae’n rhaid iddi fod yn y dewiswyr hefyd, neu nid oes polisi yn cwmpasu ateb a gyfeiriwyd at 10.80.0.25. Mae pob cymar yn enwi’r un pâr o setiau rhagddodiad o’i ochr ei hun:

# 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 un ddyfais yw remote_ts y llall. Copïwch floc y canolbwynt i’r pencadlys ac mae’r pâr yn gwrthdroi, felly nid yw’r child SA byth yn codi.

Mae’r ipsec.conf gystrawen hŷn yn defnyddio leftsubnet wedi’i wahanu gan atalnodau. Mae’r gymdeithas diogelwch sy’n rhedeg yn cadw’r dewiswyr y cytunodd arnynt, felly ailsefydlwch y twnnel ar ôl y newid. Mae dewisydd a newidiwyd am 10:00 ac a brofwyd yn erbyn SA a gododd am 09:40 yn dal i fethu, tra bo’r ffeil ffurfweddu yn edrych yn gywir drwy’r amser.

Yna gwiriwch y naid olaf. ip route get 10.80.0.25 ar y pwynt terfyn pell ddylai bwyntio i’r twnnel. Os yw’r gwasanaeth yn defnyddio llwybrydd LAN fel ei borth diofyn, mae ar y llwybrydd hwnnw angen y llwybr dychwelyd hefyd, neu mae’r ateb yn marw yno. Mae rhedeg tcpdump -ni eth1 host 10.80.0.25 ar y segment hwnnw yn dangos a adawodd yr ateb y pwynt terfyn o gwbl.

Caniatéwch y llif yn y canolbwynt

Rhaid i anfon ymlaen fod wedi’i alluogi a’r llwybr wedi’i ganiatáu. Cyfyngwch y rheolau i’r ddau ragddodiad yn lle derbyn popeth rhwng y rhyngwynebau.

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

Mae hidlo llwybr gwrthdro yn fethiant tawel wrth ei ochr: gyda’r ddwy goes ar ryngwynebau gwahanol, gall rp_filter=1 ollwng yr ateb tra nad yw cyfrifydd y rheol dderbyn byth yn symud. Cymharwch iptables -vnL FORWARD cyn ac ar ôl ymgais. Nid oes modd cyrraedd rheol nad yw byth yn cynyddu, felly edrychwch haen yn is yn lle ei hailysgrifennu.

Os mai dim ond un grŵp sydd angen tramwy, rhowch y llwybr mewn ffeil fesul cleient o dan client-config-dir yn lle lledu’r push byd-eang. Mae NAT ffynhonnell ar y canolbwynt hefyd yn dileu’r angen am lwybr dychwelyd pell, ond mae’n cuddio cyfeiriad y defnyddiwr, felly mae logiau’r safle pell a’r rheolau sy’n seiliedig ar gyfeiriad yn rhoi’r gorau i wahaniaethu defnyddwyr.

Gwiriwch o’r cleient, yna treiglwch yn ôl yn y drefn wrthdro

Profwch borth TCP, nid ICMP yn unig, oherwydd gall ping basio tra bo’r gwasanaeth yn parhau wedi’i rwystro. nc -vz 10.20.0.50 445 a traceroute -n 10.20.0.50 o’r cleient yn dangos ai cyfeiriad twnnel y canolbwynt yw’r ail naid. Ar y canolbwynt, tcpdump -ni tun0 host 10.20.0.50 a’r un hidlydd ar ryngwyneb y safleoedd: cais ar y ddau heb ateb ar y naill na’r llall yn symud y broblem i’r ochr bell.

Yna profwch rywbeth y dylai aros wedi’i rwystro. Os yw gwesteiwr na ddylai’r gronfa byth ei gyrraedd yn ateb hefyd, rydych wedi agor mwy na thramwy a dylech gulhau’r rheolau. Mae canolbwynt sy’n anfon popeth i bob braich yn pasio’r prawf cyntaf ac yn methu’r ail.

Cadwch restr dreiglo, oherwydd newidiwyd pedwar gwrthrych ac mae tri yn hawdd i’w hanghofio: y llwybr a wthiwyd, llwybr y canolbwynt, y dewiswyr a’r rheolau mur tân. Dadwnewch hwy yn y drefn wrthdro, ailsefydlwch yr SA, a gadewch i un defnyddiwr ailgysylltu. Mae treiglhad rhannol yn gadael llwybr yn pwyntio at dwnnel nad yw’n cyfateb mwyach, sy’n anoddach ei ddarllen na’r distawrwydd gwreiddiol. Mae llawlyfr OpenVPN 2.6 yn dogfennu push, route a iroute ar gyfer eich fersiwn.