pfSense kiel VPN-servilo kaj kliento: du vojoj, unu enkursigilo
Envena servo kaj elvena tunelo povas dividi unu aparaton. Tri kondiĉoj decidas ĉu iliaj itineroj, tradukado kaj paneoj restas apartaj.
Unu aparato povas rigardi al du direktoj samtempe: migrantaj uzantoj konektiĝas al ene, kaj la sama skatolo konektiĝas al ekstere al elira provizanto tiel ke la elektita trafiko ekiras tra alia reto. Ŝalti ambaŭ servojn daŭras minutojn; igi ilin kunekzisti postulas projektadon, ĉar la dua rolo reverkas la itinertabelon de kiu dependas la unua. Tri kondiĉoj decidas ĉu la aranĝo funkcias, nome ĉu la envena servo konservas sian propran revenan vojon, ĉu la elvena tunelo ankoraŭ povas atingi sian partneron, kaj ĉu la trafiko, kiun vi volis plusendi, estas elektita por la eliro. Eraru pri unu kaj vi ricevas du tunelojn, kiuj ambaŭ raportas konekton dum nenio utila transiras inter ili. La kontroloj sube starigas ĉiun kondiĉon laŭ la ordo en kiu la paneoj kutime aperas.
Nomu la du rolojn antaŭ ol tuŝi ajnan agordon
Notu kvar faktojn por ĉiu kazo: ĝian malproksiman partneron, ĝian aŭtentigan materialon, la adresaron kiun ĝi disdonas, kaj la retojn malantaŭ ĝi. La du kazoj estas apartaj objektoj sur la aparato kaj devus resti apartaj ankaŭ en viaj notoj. Preskaŭ ĉiu konfuza simptomo poste venas de miksado de iliaj valoroj, kaj du kazoj dividantaj unu notaron estas la maniero kiel la malĝusta adresaro finiĝas en la malĝusta kampo.
La envena servo bezonas tunelreton, kiu ne interkovras la adresojn de la elvena tunelo nek iun ajn privatan reton, kiun la aparato enkursigas. Interkovro estas la sola eraro, kiu produktas simptomojn en ambaŭ roloj samtempe, kaj surpapera kaptado estas multe pli malmultekosta. Komparu ambaŭ adresarojn kaj ĉiun enkursigitan privatan reton en unu loko antaŭ ol agordi iun ajn el la servoj.
Dividita aparataro ne implicas dividitajn akreditaĵojn, kaj klienta atestilo el la malproksima-aliro-adresaro ne devus esti uzebla kontraŭ la elira provizanto. Aparta materialo ankaŭ igas revokadon loka decido anstataŭ evento por la tuta floto.
Tenu la respondojn de la servilo sur la WAN-vojo
La respondoj, kiujn la aparato mem generas, estas la unua viktimo de senzorga apriora itinero. Kiam alvenas la enkapsuligita pako de migranta uzanto, la respondo estas loke originita trafiko kaj devas eliri tra la interfaco, tra kiu tiu uzanto venis. Se la elira kliento instaligis aprioran itineron, kiu ĝin kaptas, la respondo eniras la malĝustan tunelon kaj la sesio haltas dum la servo ankoraŭ aspektas sana.
Ne ekzistas unu markobutono, kiu solvas ĉi tion, ĉar la decido temas pri tio, kiun trafikon la elira kliento rajtas kapti. Aŭ tiru neniujn itinerojn kaj direktu nur tion, kion vi elektas, aŭ tiru itinerojn kaj aldonu la esceptojn, kiuj tenas la proprajn servojn de la aparato funkciantaj. Notu la elekton apud la kazo, alie la sekva persono supozos la alian.
netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn
Legu la itinertabelon laŭ la plej longa kongruo, ne laŭ la ordo en kiu vi agordis ion ajn. La demando estas, kiu ero venkas por la adreso de la elira partnero kaj kiu ero venkas por la respondo de la envena servo, kaj tiuj du respondoj povas malsami.
Ne lasu la elvan tunelon manĝi sian propran finpunkton
La elira kliento devas atingi la publikan adreson de sia partnero por eĉ starigi la tunelon. Se tiu adreso mem estas enkursigita en la tunelon, la kliento ĉasas sian propran voston: la transporto neniam leviĝas, aŭ ĝi leviĝas kaj tiam falas en la momento, kiam la itinero instaliĝas. La protokolo aspektas kiel aŭtentiga tempolimo anstataŭ itinera paneo, kaj tial la itinero meritas la unuan kontrolon.
Kontrolu la itineron antaŭ la akreditaĵoj kaj denove post kiam la tunelo staras, ĉar ero povas esti ĝusta ĉe lanĉo kaj malĝusta minuton poste. La adreso de la partnero devas montri al la ordinara WAN-vojo, neniam al la tunela aparato. Kiam la transporto stabiliĝas, la interesa demando translokiĝas al plusendita trafiko, kio estas la sekva decido.
netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10
Elektu, kiuj uzantoj ricevas la eliron
Fontpolitiko apartenas al la enirejo, kie trafiko eniras la aparaton, do elektu la malproksima-aliro-adresaron aŭ pli mallarĝajn identecojn ene de ĝi. Konservu la privatajn celojn kaj administrajn esceptojn, kiuj neniam estu sendataj al la eliro, kaj metu tiujn regulojn antaŭ la vasta. La elira vojo tiam bezonas sian propran tradukon aŭ enkursigitan revenan aranĝon, kio por la plej multaj projektoj signifas eliran NAT sur la elira interfaco kovrante la adresaron. Tradukado ne elektas eliron; ĝi nur reverkas tion, kio jam foriris, do NAT-regulo sur nerilata WAN ŝanĝas nenion en la elekto.
Konfirmu, ke la malproksima flanko permesas plusenditan trafikon el ĉi tiu projekto, ĉar kelkaj provizantoj jesas kaj kelkaj ne. La diferenco montriĝas kiel tunelo, kiu konektiĝas kaj portas nenion, kion oni facile legas kiel lokan paneon. Testu la tri fluojn aparte, ĉar ili paneas sendepende, kaj du el tri estas duone konstruita projekto.
openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health
La unua komando estas la ekstera konekto de la migranta uzanto, kaj ĝi funkcias kiam la kliento raportas la sekvencon de pravalorigo finita. La dua, lanĉita el tiu konektita tekkomputilo, devus raporti la adreson de la elira provizanto anstataŭ vian WAN-adreson. La tria kuras sur la aparato ligita al adreso el la adresaro, kaj ĝi testas la fontpolitikon por plusendita trafiko tute ne engaĝante malproksiman uzanton. Se ĝi anstataŭe respondas el la WAN, la politiko ne kongruis, kaj neniu kvanto de NAT-redaktado riparas elekto-problemon.
Decidu, kio okazas kiam la eliro paneas
Notu la panean konduton antaŭ ol ĝi okazas: kiam la elira tunelo falas, ĉu uzantoj refalas al la ordinara WAN aŭ estas blokataj ĝis la eliro revenas? Ambaŭ respondoj estas defendeblaj, kaj la aparato ne elektos por vi. Forigita itinero aŭ politiko montranta al morta enirejo ne aŭtomate produktas plene blokitan rezulton. Se vi volas blokadon, la politiko devas tion eksplicite diri, kaj ĝi devas esti testata forprenante la eliron anstataŭ pripensante ĝin. Se vi volas refalon, publikigu tion al uzantoj, ĉar trafiko, kiu silente prenas la ordinaran vojon, estas ĝuste la trafiko, kiun iu kredis kovrita.
Malŝaltu la klientan kazon, observu kion konektita uzanto ankoraŭ povas atingi, kaj poste relanĉu ĝin. Peto, kiu tempolimas, estas la plene blokita rezulto, kiun vi petis; unu, kiu respondas per la WAN-adreso, estas la refalo, kiun vi ne dokumentis. Ripetu la kontrolon por IPv6 kaj por DNS, ĉar politiko skribita por IPv4 diras nenion pri AAAA-trafiko, kaj solvilo puŝita de iu ajn el la tuneloj respondas de kie la demando efektive eliras.
pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2
La Netgate-recepto por enkursigita OpenVPN montras, kiel fontpolitiko, interfaca asigno kaj elira tradukado kunfalas, kaj ĝia amplekso inter ejoj estas la parto, kiun oni ne kopiu tutan. Kion ĝi ne diros al vi, estas kiun el la tri kondiĉoj supre via propra projekto jam rompis.