VPN-kliënte bereik die bediener, maar nie die LAN nie: watter oplossing?

Die kliënt ping die tonneladres van die OpenVPN-bediener en kry 'n antwoord, probeer dan 'n gasheer op die bediener se LAN en kry niks. Daardie skeiding vernou die fout aansienlik: die tonnel is op, aanstuur werk waarskynlik, en die antwoord verlaat die netwerk deur 'n deur wat nie teruglei nie. Daar is drie oplossings, en die regte een hang daarvan af wat jy beheer en waarmee jy bereid is om op te gee. Beantwoord die drie vrae hieronder in volgorde, dan is die keuse nie meer 'n kwessie van smaak nie.

Eers vasstel watter rigting stukkend is

Die versoek kom op die tonnelkoppelvlak in met 'n bronadres uit die VPN-poel. Die bediener stuur dit aan na die LAN-gasheer, en daardie gasheer antwoord aan watter gateway sy eie tabel ook al noem, gewoonlik die LAN-roeteerder. As die roeteerder geen roete vir die poel het nie, sterf die antwoord daar of dwaal dit in die rigting van die internet.

Toets albei masjiene voordat jy enige van hulle wysig. Vra op die bediener die roeteringstabel hoe hy 'n kliënt sou bereik; vra op die LAN-gasheer hoe hy dieselfde adres sou bereik. Die eerste soektog wys gewoonlik na die tonnel en die tweede na die LAN-roeteerder, en daardie verskil is die fout in een reël. Twee soektogte is goedkoper as 'n brandmuuraudit en hulle bepaal die rigting van die probleem.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

As die LAN-gasheer reeds na die VPN-bediener wys, is jou probleem 'n brandmuurreël of 'n MTU-perk en nie 'n ontbrekende terugroete nie. Moenie 'n roete byvoeg om 'n filter reg te maak nie.

Vraag een: kan jy die verre LAN se roeteerder wysig?

Wanneer die LAN-roeteerder joune is, is 'n statiese roete vir die VPN-poel met die VPN-bediener se LAN-adres as volgende sprong die skoon antwoord. Dit hou kliëntbronadresse ongeskonde, wat saak maak wanneer LAN-gashere volgens adres log, filter of tempo beperk. Dit verg ook geen vertaling op die bediener nie, sodat die tonnel 'n suiwer roeteringspad bly. Die verpligting wat dit skep, is dokumentasie, want die poel, die roete en die bedienerkonfigurasie moet ooreenstem.

Dit faal stil op die dag wanneer iemand die poel verander. Skryf die waarde een keer neer en behandel 'n wysiging op enige van die drie plekke as 'n wysiging aan al drie.

'n NAS of 'n Layer 3-skakelaar wat die diens huisves, het dieselfde roete nodig, tensy hy alles deur 'n roeteerder stuur wat een het. Kontroleer die toestel wat die subnet termineer, nie net die een wat na die internet wys nie. Klein netwerke het dikwels drie toestelle met 'n mening oor roetering.

Vraag twee: kan die LAN ophou om kliëntadresse te sien?

Wanneer die roeteerder aan iemand anders behoort, verg vertaling op die VPN-bediener geen samewerking nie. Die LAN-gasheer sien die bediener se LAN-adres, antwoord daarop, en die bediener vertaal terug. Daarom gedra toestelle en NAT-gebaseerde afstandtoegang-rolle hulle so.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Die prys is toeskrywing: adresse per kliënt verdwyn uit LAN-logs. Enige toelaatlys op die LAN-gasheer moet dan die bediener noem in plaas van die poel.

Kies vertaling wanneer samewerking onbeskikbaar is, nie wanneer dit bloot ongerieflik is nie. Dit versteek die kliënt vir elke toekomstige ondersoek, ook die waar jy moet weet watter skootrekenaar 'n verbinding oopgemaak het. Dit kan ook protokolle breek wat adresse in vragte inbed, want die vertaling sit in die kop. Nie een van die twee opsies is meer gevorderd nie; hulle beantwoord verskillende vrae oor eienaarskap.

Vraag drie: is die bediener self 'n kliënt van 'n ander tonnel?

Stel jou die ander topologie voor: die VPN-bediener skakel ook by 'n kommersiële verskaffer in, so hy het twee tonnele en twee stelle adresse. Verkeer wat hy vir sy eie kliënte aanstuur, verlaat deur die verskaffer, wat antwoorde nie terug na poeladresse sal roeteer nie. Daarom verdwyn antwoorde selfs al is albei tonnele gesond.

Die oplossing is om ook die uitgaande tonnel te masjereer, sodat die verskaffer net die bediener se tonneladres sien. Die omgekeerde rigting het sy eie reël nodig, want die bediener wat 'n verbinding na een van sy eie kliënte begin, is 'n ander vloei. Sonder daardie reël antwoord die kliënt na 'n adres wat hy nie kan roeteer nie. Plaas die smal reël voor enige breë masjerasie sodat die spesifieke vertaling wen.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Multihomed gashere voeg 'n verwante fout by wat van die kliënt se kant identies lyk. Die antwoord verlaat die stelsel deur die koppelvlak met die laer metrieke omdat die bronadres uit 'n ander tabel gekies is. Kontroleer die terugpad met 'n soektog eerder as om te aanvaar dat die heenpad dit impliseer.

Verifieer dan albei rigtings en albei groottes

Ping ná die verandering van die kliënt na 'n LAN-gasheer, dan van die LAN-gasheer na die kliënt. Die tweede rigting is die een wat mense oorslaan, en dit is die een wat 'n onvolledige vertaalreël blootlê. Teken albei resultate met tydstempels aan sodat 'n latere regressie vergelykbaar is.

Beweeg dan werklike data, want 'n klein ping wat slaag terwyl 'n groot oordrag vassteek, is 'n MTU-simptoom. Daardie fout verskyn net nadat jy jouself gelukgewens het met die regmaak van die roete.

Toets laastens weer ná 'n herbegin. Runtime-roete- en brandmuurbevele oorleef nie een nie, en 'n oplossing wat by die volgende herbegin verdwyn, sal weer gediagnoseer word deur iemand met minder konteks. Maak die verandering blywend op die manier wat jou stelsel al gebruik, en herbegin dan een keer doelbewus.