pfSense као VPN сервер и клијент: две стазе, један рутер
Долазни сервис и одлазни излазни тунел могу да деле један уређај. Три услова одлучују да ли њихове руте, превод и откази остају одвојени.
Један уређај може гледати у два смера истовремено: роаминг корисници се повезују унутра, а иста кутија се повезује напоље ка провајдеру излаза тако да изабрани саобраћај излази кроз другу мрежу. Укључивање оба сервиса траје минуте; њихово заједничко постојање захтева пројекат, јер друга улога преписује табелу рутирања на коју се прва ослања. Три услова одлучују да ли распоред ради, наиме да ли долазни сервис задржава сопствену повратну путању, да ли одлазни тунел још увек стиже до свог партнера и да ли се саобраћај који сте намеравали да проследе бира за излаз. Погрешите једно и добијате два тунела која оба извештавају да су повезана док између њих не прелази ништа корисно. Провере испод успостављају сваки услов редом којим се откази обично појављују.
Именујте две улоге пре него што дотакнете било које подешавање
Запишите четири чињенице за сваку инстанцу: њеног удаљеног партнера, материјал за аутентификацију, базен адреса који дели и мреже иза ње. Две инстанце су одвојени објекти на уређају и треба да остану одвојени и у вашим белешкама. Скоро сваки збуњујући симптом касније долази од мешања њихових вредности, а две инстанце које деле један скуп бележака су начин на који погрешан базен заврши у погрешном пољу.
Долазном сервису потребна је тунелска мрежа која се не преклапа са адресама одлазног тунела ни са било којом приватном мрежом коју уређај рутира. Преклапање је једина грешка која истовремено ствара симптоме у обе улоге, и далеко је јефтиније ухватити је на папиру. Упоредите оба базена и сваку рутирану приватну мрежу на једном месту пре него што конфигуришете било који од сервиса.
Дељени хардвер не значи дељене акредитиве, а клијентски сертификат из базена за удаљени приступ не треба да буде употребљив према провајдеру излаза. Одвојен материјал такође претвара опозив у локалну одлуку уместо догађаја за целу флоту.
Држите одговоре сервера на путањи WAN
Одговори које сам уређај генерише прва су жртва немаровитог подразумеваног пута. Када стигне инкапсулирани пакет роаминг корисника, одговор је локално настао саобраћај и мора да изађе кроз интерфејс којим је тај корисник дошао. Ако је одлазни клијент инсталирао подразумевани пут који га хвата, одговор улази у погрешан тунел и сесија стаје док сервис још изгледа здрав.
Не постоји једно поље за потврду које то решава, јер одлука се односи на то који саобраћај одлазни клијент сме да хвата. Или не повлачите никакве руте и усмеравајте само оно што одаберете, или повуците руте и додајте изузетке који одржавају сопствене сервисе уређаја у погону. Запишите избор поред инстанце, иначе ће следећа особа претпоставити други.
netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn
Читајте табелу рутирања по најдужем подударању, а не по редоследу којим сте било шта конфигурисали. Питање је који запис побеђује за адресу партнера излаза и који запис побеђује за одговор долазног сервиса, а та два одговора могу да се разликују.
Не дозволите одлазном тунелу да поједе сопствену крајњу тачку
Одлазни клијент мора да стигне до јавне адресе свог партнера да би уопште успоставио тунел. Ако је та адреса сама рутирана у тунел, клијент јури сопствени реп: транспорт се никада не подиже, или се подигне и падне у тренутку када се рута инсталира. Дневник изгледа као истек времена за аутентификацију, а не као дефект рутирања, зато рута заслужује прву проверу.
Проверите руту пре акредитива и поново након што се тунел подигне, јер запис може бити тачан при подизању и погрешан минут касније. Адреса партнера мора да показује на обичну путању WAN, никад на тунелски уређај. Када се транспорт стабилизује, занимљиво питање прелази на прослеђени саобраћај, што је следећа одлука.
netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10
Изаберите који корисници добијају излаз
Политика извора припада улазу где саобраћај улази у уређај, зато изаберите базен за удаљени приступ или уже идентитете у њему. Сачувајте приватна одредишта и изузетке за управљање који никад не смеју да иду на излаз, и поставите та правила пре широког. Путања излаза затим тражи сопствени превод или рутирани распоред повратка, што за већину пројеката значи одлазни NAT на излазном интерфејсу који покрива базен. Превод не бира излаз; он само преписује оно што је већ отишло, па правило за NAT на неповезаном WAN не мења ништа у избору.
Потврдите да удаљена страна дозвољава прослеђени саобраћај из овог пројекта, јер неки провајдери дозвољавају а неки не. Разлика се види као тунел који се повеже и не носи ништа, што је лако прочитати као локални дефект. Тестирајте три тока одвојено, јер они отказују независно, а два од три је напола изграђен пројекат.
openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health
Прва команда је спољна веза роаминг корисника, и ради када клијент извести да је низ за иницијализацију завршен. Друга, покренута са тог повезаног преносног рачунара, треба да извести адресу провајдера излаза уместо ваше адресе WAN. Трећа ради на уређају везана за адресу из базена, и тестира политику извора за прослеђени саобраћај без икаквог укључивања удаљеног корисника. Ако уместо тога одговори са WAN, политика се није поклопила, и никакво уређивање NAT не поправља проблем избора.
Одлучите шта се дешава када излаз откаже
Запишите понашање при отказу пре него што се догоди: када одлазни тунел падне, да ли се корисници враћају на обичан WAN или су блокирани док се излаз не врати? Оба одговора су одбрањива, а уређај неће изабрати уместо вас. Уклоњена рута или политика која показује на мртву капију не дају аутоматски потпуно блокиран резултат. Ако желите блокирање, политика то мора експлицитно да каже, и мора да се тестира уклањањем излаза, а не размишљањем о њему. Ако желите повратак, објавите то корисницима, јер саобраћај који тихо узима обичну путању је управо онај саобраћај за који је неко мислио да је покривен.
Онемогућите инстанцу клијента, погледајте до чега повезан корисник још стиже, па је поново покрените. Захтев који истекне је резултат потпуног блокирања који сте тражили; онај који одговори адресом WAN је повратак који нисте документовали. Поновите проверу за IPv6 и за DNS, јер политика написана за IPv4 не каже ништа о саобраћају AAAA и резолвер који било који тунел прогура одговара одонуд одакле захтев заиста излази.
pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2
Netgate-ов рецепт за рутирани OpenVPN показује како се политика извора, додела интерфејса и одлазни превод уклапају, а његов обухват од локације до локације је део који не треба копирати у целини. Оно што вам неће рећи јесте који је од три услова горе ваш пројекат већ прекршио.