pfSense OpenVPN: maabot ang network sa likod ng isa pang router
Kailangan ng kliyente ng itinulak na prefix, kailangan ng pfSense ng maabot na susunod na hop, at kailangan ng malayong router ng daan pabalik sa pool. Tatlong may-ari, tatlong ruta.
Naabot ng iyong laptop ang LAN ng pfSense sa pamamagitan ng VPN at nabigo pa rin itong maabot ang isang serbisyong dalawang hop pa ang lalim, at ang pagkakaiba ay isang desisyon sa pagruruta bawat may-ari. Tatlong device ang dapat magkasundo bago makumpleto ng isang packet ang paglalakbay nito pabalik-balik: ang kliyente, ang firewall at ang router na aktwal na nagmamay-ari ng patutunguhang network. Kapag may napalampas sa kanila, magmumukhang pareho ang sintomas.
Sundan ang isang packet sa tatlong desisyong iyon bago baguhin ang isang patakaran, dahil bawat may-ari ay may ibang kontrol at ibang paraan ng pagkabigo.
Isang packet, tatlong desisyon sa pagruruta
Nagpapasya ang kliyente kung kabilang ang patutunguhan sa tunnel, at makakapagpasya lamang ito mula sa alam nito: isang itinulak na ruta, isang lokal na ruta o isang default na sumasaklaw na sa lahat. Nagpapasya ang pfSense kung saan ipapadala ang packet sa susunod, na para sa isang network sa likod ng isa pang router ay nangangahulugan ng static na ruta sa pamamagitan ng maabot na gateway sa tamang interface. Nagpapasya ang router sa ibaba kung kilala nito ang daan pabalik sa pool ng VPN, at kung hindi, itinatapon ang sagot o ipinapadala sa walang silbing lugar. Ang bawat desisyon ay malaya sa dalawa pa.
Ang pagkabigo ng alinman sa kanila ay nagbibigay ng parehong ulat ng user. Iyon ang dahilan kung bakit ang pagkakasunod-sunod ng pag-debug ay mas mahalaga kaysa sa mga tool.
Bigyan ang kliyente ng prefix, hindi hula
Sa isang pfSense SSL/TLS server na may IPv4 tunnel network na mas malaki sa /30, ang field na IPv4 Local network(s) ay namamahagi ng mga ruta sa mga kliyente kapag kumonekta sila. Idagdag doon ang lower prefix sa halip na umasa na ang kliyente ay mag-imbento ng isa. Pagkatapos basahin ang aktwal na talahanayan ng kliyente pagkatapos kumonekta, dahil ang isang profile na may route-nopull o isang filter ng ruta ay maaaring huwag pansinin ang ipinadala ng server. Ang server ay maaaring ganap na tama habang ang kliyente ay walang ini-install.
Ang iba pang mode ng server at topolohiya ay may iba't ibang limitasyon, at ang patakaran bawat kliyente o koneksyon ay maaaring magbago ng natatanggap ng isang partikular na kliyente. I-verify sa kliyenteng mahalaga, hindi sa kliyenteng nagkataong una mong sinubukan.
Ituro ang pfSense sa panloob na router
Ang isang static na ruta sa pfSense ay nangangailangan ng gateway na tinukoy at maabot, at ang interface na pinili para sa gateway na iyon ay dapat ang aktwal na nakakarating doon, gaya ng inilalarawan ng gabay sa static na ruta ng Netgate. Sa isang halimbawang layout, ang transit link ay 192.168.77.1 sa firewall at 192.168.77.2 sa panloob na router, at ang service network ay nasa 172.16.30.0/25 sa likod nito. Pagkatapos ay pinapangalanan ng ruta ang prefix at ang susunod na hop, hindi ang address ng serbisyo. Ang paggamit ng address mula sa malayong network bilang gateway ay karaniwang paraan upang makabuo ng rutang mukhang tama at hindi nagpapasa kahit saan.
Ang pagbibigay ng pangalan sa isang interface ay hindi naglalarawan sa mga network sa likod nito. Ang static na ruta ang paglalarawang iyon.
Dapat alam ng malayong panig ang pool
Kailangan ng router sa ibaba ng return route para sa pool, sa halimbawang ito 10.55.0.0/24 sa pamamagitan ng 192.168.77.1, maliban kung may ibinibigay nang default na ruta o dynamic na protocol. Ang gateway ng host ng serbisyo mismo ay dapat patungo sa router na iyon, na karaniwang totoo kapag ang router ang default gateway nito at mali kapag mano-manong na-configure ang host. Ang policy routing sa firewall ay maaari ring lampasan ang talahanayan para sa partikular na trapiko, kaya tingnan kung may patakarang pumipili ng ibang gateway bago maghinuha na mali ang ruta.
Walang pagsasalin na kailangan para sa disenyong ito, at ang pagpapanatiling nakikita ang source address ng kliyente ay nagbibigay-daan sa lower network na ilapat ang sarili nitong patakaran.
Para sa pagtanggap, sundan ang isang bagong kahilingan sa pagpasok ng tunnel, panloob na labasan ng firewall at sagot mula sa patutunguhan. Kung sadyang pagsasalin ang ginagamit sa halip, itala kung anong pinagmulan ang nakikita ng lower network at paano inaasahang babalik ang sagot.
I-save ang plano ng tatlong may-ari kasama ng pinapayagang application, upang ang susunod na administrator ay makapagbuo muli ng landas sa halip na muling tuklasin ito.