pfSense as VPN-bediener en -kliënt: twee paaie, een router

Een toestel kan gelyktydig in twee rigtings kyk: rondlopergebruikers verbind in, en dieselfde boks verbind uit na ’n uitgangsverskaffer sodat gekose verkeer deur ’n ander netwerk vertrek. Om albei dienste te aktiveer neem minute; om hulle saam te laat werk, verg ’n ontwerp, want die tweede rol herskryf die roetekaart waarop die eerste een staatmaak. Drie voorwaardes bepaal of die reëling werk, naamlik of die inkomende diens sy eie terugroete behou, of die uitgaande tonnel nog sy eweknie kan bereik, en of die verkeer wat jy bedoel het om aan te stuur, vir die uitgang gekies word. Kry een verkeerd en jy kry twee tonnels wat albei verbind rapporteer terwyl niks nuttigs tussen hulle oorsteek nie. Die kontroles hieronder vestig elke voorwaarde in die volgorde waarin die foute gewoonlik verskyn.

Benoem die twee rolle voordat jy aan ’n instelling raak

Skryf vier feite vir elke instansie neer: sy afgeleë eweknie, sy stawingsmateriaal, die adrespoel wat dit uitdeel en die netwerke agter hom. Die twee instansies is aparte objekte op die toestel en moet ook in jou notas apart bly. Byna elke verwarrende simptoom later kom uit die vermenging van hulle waardes, en twee instansies wat een stel notas deel, is hoe die verkeerde poel in die verkeerde veld beland.

Die inkomende diens benodig ’n tonnelnetwerk wat nie met die uitgaande tonnel se adresse of enige privaatnetwerk wat die toestel roeteer, oorvleuel nie. Oorvleueling is die een fout wat simptome in albei rolle gelyktydig veroorsaak, en dit is baie goedkoper om op papier te betrap. Vergelyk albei poele en elke gerouteerde privaatnetwerk op een plek voordat jy een van die dienste konfigureer.

Gedeelde hardeware beteken nie gedeelde geloofsbriewe nie, en ’n kliëntsertifikaat uit die rondlopertoegangspoel behoort nie teen die uitgangsverskaffer te werk nie. Aparte materiaal maak ook herroeping ’n plaaslike besluit in plaas van ’n vlootwye gebeurtenis.

Hou die bediener se antwoorde op die WAN-pad

Antwoorde wat die toestel self genereer, is die eerste slagoffer van ’n sorgelose verstekroete. Wanneer ’n rondlopergebruiker se ingekapselde pakket aankom, is die antwoord plaaslik oorsprongverkeer en dit moet vertrek deur die koppelvlak waardeur daardie gebruiker gekom het. As die uitgaande kliënt ’n verstek geïnstalleer het wat dit vasvang, gaan die antwoord in die verkeerde tonnel in en die sessie stal terwyl die diens nog gesond lyk.

Daar is geen enkele merkkassie wat dit besleg nie, want die besluit gaan oor watter verkeer die uitgaande kliënt mag vasvang. Trek óf geen roetes nie en stuur net wat jy kies, óf trek roetes en voeg die uitsonderings by wat die toestel se eie dienste laat werk. Skryf die keuse langs die instansie neer, anders sal die volgende persoon die ander een aanneem.

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

Lees die roetekaart volgens die langste passing eerder as volgens die volgorde waarin jy enigiets gekonfigureer het. Die vraag is watter inskrywing wen vir die uitgang-eweknie se adres en watter inskrywing wen vir die inkomende diens se antwoord, en daardie twee antwoorde kan verskil.

Moenie toelaat dat die uitgangstonnel sy eie eindpunt opeet nie

Die uitgaande kliënt moet sy eweknie se publieke adres bereik om die tonnel hoegenaamd te vestig. As daardie adres self in die tonnel gerouteer word, jaag die kliënt sy eie stert: die vervoer kom nooit op nie, of dit kom op en val dan die oomblik wanneer die roete installeer. Die log lyk soos ’n stawingstydverstreking eerder as ’n roetefout, en daarom verdien die roete eerste kontrole.

Kontroleer die roete voor die geloofsbriewe en weer nadat die tonnel op is, want ’n inskrywing kan by die opstart korrek wees en ’n minuut later verkeerd. Die adres van die eweknie moet na die gewone WAN-pad wys, nooit na die tonneltoestel nie. Sodra die vervoer stabiel is, skuif die interessante vraag na aangestuurde verkeer, wat die volgende besluit is.

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

Kies watter gebruikers die uitgang kry

Bronbeleid hoort by die ingang waar verkeer die toestel binnekom, so kies die rondlopertoegangspoel, of nouer identiteite daarbinne. Bewaar die privaat bestemmings en bestuursuitsonderings wat nooit na die uitgang gestuur moet word nie, en plaas daardie reëls voor die breë een. Die uitgangspad benodig dan sy eie vertaling of gerouteerde terugkeerreëling, wat vir die meeste ontwerpe uitgaande NAT op die uitgangkoppelvlak beteken wat die poel dek. Vertaling kies nie ’n uitgang nie; dit herskryf net wat reeds vertrek het, so ’n NAT-reël op ’n onverwante WAN verander niks aan die keuse nie.

Bevestig dat die verre kant aangestuurde verkeer uit hierdie ontwerp toelaat, want sommige verskaffers doen dit en sommige nie. Die verskil wys as ’n tonnel wat verbind en niks dra nie, wat maklik as ’n plaaslike fout verkeerd gelees word. Toets die drie vloeie apart, want hulle faal onafhanklik en twee uit drie is ’n halfgeboude ontwerp.

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

Die eerste opdrag is die rondlopergebruiker se buitenste verbinding, en dit werk wanneer die kliënt die inisialiseringsreeks as voltooid rapporteer. Die tweede, uitgevoer vanaf daardie gekoppelde skootrekenaar, behoort die uitgangsverskaffer se adres te rapporteer eerder as jou WAN-adres. Die derde loop op die toestel gebind aan ’n poeladres, en dit toets die bronbeleid vir aangestuurde verkeer sonder om hoegenaamd ’n afgeleë gebruiker te betrek. As dit eerder uit die WAN antwoord, het die beleid nie gepas nie, en geen hoeveelheid NAT-redigering regstel ’n keuseprobleem nie.

Besluit wat gebeur wanneer die uitgang faal

Skryf die falinggedrag neer voordat dit gebeur: wanneer die uitgaande tonnel val, val gebruikers terug na die gewone WAN of word hulle geblokkeer totdat die uitgang terugkeer? Albei antwoorde is verdedigbaar, en die toestel sal nie vir jou kies nie. ’n Verwyderde roete of ’n beleid wat na ’n dooie poort wys, lewer nie outomaties ’n toestand waarin alles geblokkeer bly nie. As jy blokkering wil hê, moet die beleid dit eksplisiet sê, en dit moet getoets word deur die uitgang weg te neem eerder as deur daaroor te redeneer. As jy terugval wil hê, publiseer dit vir gebruikers, want verkeer wat stilweg die gewone pad neem, is juis die verkeer wat iemand geglo het gedek was.

Deaktiveer die kliëntinstansie, kyk wat ’n gekoppelde gebruiker nog kan bereik, en begin dit dan weer. ’n Versoek wat uittyd is die resultaat waarin alles geblokkeer bly, wat jy gevra het; een wat met die WAN-adres antwoord, is die terugval wat jy nie gedokumenteer het nie. Herhaal die kontrole vir IPv6 en vir DNS, want ’n beleid vir IPv4 sê niks oor AAAA-verkeer nie en ’n oplosser wat deur enige van die tonnels gestoot word, antwoord van waar die navraag werklik vertrek.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

Die Netgate-resep vir gerouteerde OpenVPN wys hoe bronbeleid, koppelvlaktoewysing en uitgaande vertaling inmekaar pas, en sy werf-tot-werf-bestek is die deel wat ’n mens nie heelkop moet kopieer nie. Wat dit jou nie sal sê nie, is watter van die drie voorwaardes hierbo jou eie ontwerp reeds gebreek het.