OpenVPN-kliënte deur Cloudflare lei? Kyk eers na die rol
’n Toestelkliënt is nie ’n router nie. Bevestig dat die Cloudflare-rol ander gashere se pakkette aanstuur en hou dan die bediener se eie tonnel op sy ou pad.
Jy het ’n werkende OpenVPN-bediener en ’n gasheer wat ook Cloudflare se toestelsagteware laat loop, en die voor die hand liggende volgende stap lyk soos om kliëntverkeer daarheen te stuur. Twee werkende verbindings op een masjien maak nie saam ’n deurgangsportaal nie. Wat ontbreek, is ’n rol wat gedokumenteer is om pakkette vir iemand anders aan te stuur, en ’n beleid wat daardie pakkette klassifiseer wanneer hulle aankom.
Vier vrae kom voor enige reël: watter verkeer inkom, waar dit volgende heen gaan, hoe die antwoorde terugkom, en wat die ontwerp doen wanneer daardie tweede pad faal. Die eerste twee is vermoëvrae.
Twee dienste op een gasheer is nie ’n deurgangspad nie
’n Toestelkliënt is gebou om verkeer te hanteer wat op die masjien ontstaan waar dit loop. Dit onderskep naamoplossing, of geselekteerde toepassingsverkeer, en stuur dit deur sy eie tonnel, en sy beleid is geskryf vir daardie toestel se gebruiker en daardie toestel se prosesse. ’n Pakket wat vanaf ’n OpenVPN-kliënt aangestuur word, is nie plaaslike uitset nie, so dieselfde reëls klassifiseer dit nie. Dit is nie ’n konfigurasiedetail wat jy met ’n breër reël kan oorbrug nie, want dit bepaal of die sagteware die pakket hoegenaamd sien.
Daarom is die ontwerpvraag ’n vermoëvraag. Óf die geïnstalleerde produk het ’n gedokumenteerde rol wat verkeer vir ander netwerke aanstuur, óf die deurgangsfunksie hoort heeltemal elders.
Watter Cloudflare-rol mag aanstuur
Cloudflare se toestelkliënt bied modusse wat in omvang verskil: slegs naamoplossing, verkeer vanaf die toestel, en soms albei. Geen van daardie modusse maak die gasheer ’n router vir ’n privaat reeks wat oor ’n ander tonnel aankom nie. Die toegewyde roeteringsrol is ’n aparte produk met sy eie connector, inskrywing en netwerkmodel.
| Question | What has to answer it |
|---|---|
| Does the installed product forward packets from other hosts? | A documented routing or connector role, not a device mode |
| Which prefixes does the connector advertise? | Its own configuration and status output |
| Does the server's own transport still take the old path? | ip route get for the endpoint, before and after |
| Do replies return through the same path? | Connection tracking counters on the forward rule |
Kontroleer die geïnstalleerde rol voordat jy roetes daaromheen ontwerp. Lees watter koppelvlak die connector skep, of dit spesifieke voorvoegsels of ’n verstek adverteer, en of plaaslike beleid op aangestuurde pakkette sowel as plaaslike pakkette van toepassing is. Indien slegs plaaslike verkeer hanteer word, kan die OpenVPN-bediener nie die deurgangspunt wees nie, maak nie saak hoe die vertaalreël geskryf is nie.
Dit is ook waar ’n openbare uitgangsvereiste presies gestel moet word. ’n Cloudflare-voorsiene uitgang vir aangestuurde kliëntverkeer is ’n spesifieke gebruiksgeval, en dit moet teen die diens wat jy werklik het, bevestig word.
Hou die buitenste tonnel onafhanklik van die nuwe roete
Die oomblik wanneer jy ’n verstekroete na die nuwe koppelvlak byvoeg, begin die bediener se eie uitgaande verkeer daarom meeding, en dit sluit antwoorde aan die OpenVPN-kliënte en jou SSH-sessie na die boks in. Die gewone simptoom is ’n tonnel wat vestig en dan sterf, of ’n administrateur wat toegesluit word terwyl dit lyk of die verandering gewerk het. Vergelyk ip route get vir die eindpunt voor en ná, en gebruik beleidsroetering of ’n gasheerroete om die bediener se eie vervoer te hou waar dit was. Voer daardie vergelyking vanaf die boks self uit, want die bediener se siening van sy eie roete is die een wat saak maak.
’n Uitsondering vir die bediener se openbare adres is nie op sigself genoeg nie, want elke afgeleë administrateur se terugpad is ’n ander vloei. Besluit watter van daardie vloeie die verandering moet oorleef, en verifieer dan elkeen eerder as om aan te neem die eerste dek die res.
Beperk die aanstuur en vertaling tot een vloei
Ontvangde pakkette volg die aanstuurpad, nie die plaaslike uitsetpad nie, so die reël wat saak maak, leef in die forward-hak. Waar die volgende koppelvlak vertaling nodig het, beperk die bron tot die kliëntpoel, die bestemming tot wat toegelaat word en die uitgang tot daardie enkele koppelvlak. ’n Masquerade-reël wat net aan ’n koppelvlak gekoppel is, kies self geen roete nie en laat nie aanstuur verby enige ander filter toe nie.
Besluit die fail-closed-gedrag vooraf, en toets dit dan. Stop die volgende pad en bevestig dat kliënte die beoogde uitgang verloor eerder as om stilweg na die gewone uplink terug te val, want dit is die uitkoms wat niemand raaksien voordat verkeer deur die verkeerde deur uitgaan nie. Herhaal die kontrole vir naamoplossing en vir IPv6, want ’n stel reëls slegs vir v4 laat ’n v6-pad oop.
Skryf die vier antwoorde neer waarop jy besluit het en die waarneming wat elkeen demonstreer. ’n Deurgangspad wat jy kan beskryf, is een wat jy by die volgende voorvallevaluering kan verdedig.