Openbare voorvoegsel deur OpenVPN: die terugpad regstel

Kyk hoe die tonnel opkom en die kliënt die ander kant ping, en dan antwoord ’n openbare adres wat agter die VPN hoort van iewers anders, of glad nie. Daardie simptoom het gewoonlik niks met die syfer of die sertifikate te make nie. ’n Voorvoegsel wat die verskaffer routeer, word as ’n IP-roete afgelewer, en om dit oor OpenVPN te dra beteken om daardie roete op twee vlakke te herproduseer en die bronadres op die terugpad te bewaar. Om die WAN te oorbrug is nie nodig nie, en om die adres by ’n koppelvlak te voeg skep nie die opstroomroete nie.

Die voorvoegsel moet eers na jou gerouteer word

Vra die verskaffer hoe die blok afgelewer word. ’n Voorvoegsel wat na jou bediener se hoofadres gerouteer word, is ’n ander ding as adresse wat die verskaffer verwag om direk op ’n WAN-segment te bereik. Net die eerste model werk met die ontwerp hier.

As die verskaffer 198.51.100.64/28 na jou intreebediener routeer, kom pakkette vir daardie reeks by die bediener aan en stop daar tensy jy dit aanstuur. As die verskaffer die reeks eerder op jou opstroomkanaal oorbrug, moet die bediener ARP daarvoor antwoord, wat ’n ander probleem is.

Toets die afleweringsmodel voordat jy aan OpenVPN raak: ping van buite ’n adres in die blok en kyk watter koppelvlak dit ontvang. As niks aankom nie, sal geen hoeveelheid tonnelkonfigurasie help nie. As die adres direk op die WAN antwoord, oorbrug die verskaffer eerder as om te routeer, en die ontwerp hieronder geld nie.

Twee routeringsvlakke: kerneiroete en iroute

OpenVPN het die voorvoegsel op twee plekke nodig. Die kern moet weet dat die voorvoegsel aan die tonneltoestel behoort, sodat aangestuurde pakkette OpenVPN binnegaan in plaas van die verstekroete. OpenVPN moet ook weet watter geauthentiseerde kliënt die voorvoegsel besit, en dit is die iroute-inskrywing in die kliëntspesifieke gids.

Die bedienerkant se roete lyk so, met die voorvoegsel en masker wat by die toekenning pas:

ip route add 198.51.100.64/28 dev tun0

Die kliëntspesifieke konfigurasie wys eienaarskap toe. Sit dit in die CCD-lêer wat na die kliëntsertifikaat se algemene naam vernoem is, en bevestig dat daardie gids die een is wat die bediener werklik lees:

iroute 198.51.100.64 255.255.255.240

Die OpenVPN-dokumentasie oor gerouteerde netwerke beskryf beide vlakke en waarom hulle apart is. ’n Kerneiroete sonder iroute stuur pakkette sonder eienaar in die tonnel in, en OpenVPN laat vaar hulle. ’n iroute sonder die kerneiroete laat pakkette op die bediener se verstekpad. Albei foute lyk van die kliëntkant soos ’n stukkende tonnel.

Waar die diensadres woon

Die gedelegeerde voorvoegsel is nie dieselfde ding as die tonnel se eie adresse nie. Hou die skakel gerus uit die private ruimte genommer, en plaas die openbare diensadres waar die diens werklik loop.

Op ’n Linux-kliënt wat die diens plaaslik termineer, is ’n enkele gasheradres genoeg:

ip address add 198.51.100.70/32 dev lo

As die voorvoegsel verder na ’n VM-gasheer of ’n ander LAN gerouteer word, konfigureer eerder daardie afstroompad en sy terugroete. Om elke adres in die blok aan die VPN-kliënt toe te ken, is nie nodig nie en skep later konflikte.

Hou die openbare bron op die terugpad

’n Antwoord uit die gedelegeerde voorvoegsel moet deur die tonnel uitgaan en die verskaffer se roete bereik. As die afgeleë gasheer dit via sy eie ISP stuur, lyk die bronadres vervals, en die verskaffer of die bestemming laat vaar dit. Die oplossing is ’n brongebaseerde reël of ’n toegewyde routeringstabel, nie ’n wyer NAT nie. Sonder dit werk die diens vanaf die tonnelmaat en misluk van oral elders.

By die intreebediener is ’n breë masquerade-reël die gewone skuldige. Dit herskryf die openbare bron na die bediener se hoofadres, en die kliënt sien nooit die regte een nie:

iptables -t nat -S POSTROUTING

Beperk NAT tot die private VPN-kliënte wat dit nodig het en laat die gedelegeerde voorvoegsel onvertaal. Bevestig dan dat die bediener die voorvoegsel hoegenaamd aanstuur, want ’n aanstuurketting wat by verstek weier, laat dit stilweg vaar.

Verifieer albei rigtings voordat jy dit vertrou

Verifikasie is vier waarnemings, nie een nie. Bevestig dat die verskaffer se roete aankom, die kern die voorvoegsel in die tonnel stuur, OpenVPN dit aan die regte kliënt toeken, en die antwoord met die openbare bron ongeskonde terugkeer. Elke waarneming het sy eie opdrag, sodat ’n mislukking na ’n laag wys eerder as na die hele ontwerp. Voer hulle in daardie volgorde uit ná elke konfigurasieverandering.

Vra die kern watter pad ’n gedelegeerde adres volg, en kyk na die tonnel terwyl ’n versoek loop:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Omgekeerde-padfiltering kan ’n korrekte roete ongedaan maak. Kontroleer die effektiewe instelling op die tonnel en op die opstroomkanaal, en onthou dat ’n streng modus verkeer verwerp wie se bron nie pas by die koppelvlak waarop dit aangekom het nie:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Toets laastens die foutgeval. Stop die tonnel en bevestig dat die openbare voorvoegsel nie uit die gewone opstroomkanaal lek nie. Die herstel van die VPN behoort die diens terug te bring sonder om te verbreed watter poorte die gasheer blootstel.