pfSense OpenVPN: sasniegt tīklu aiz cita maršrutētāja

Jūsu klēpjdators sasniedz pfSense LAN caur VPN un joprojām nesasniedz pakalpojumu vēl divus lēcienus tālāk, un atšķirība ir viens maršrutēšanas lēmums katram īpašniekam. Trim ierīcēm jāvienojas, pirms pakete pabeidz savu ceļu turp un atpakaļ: klientam, ugunsmūrim un maršrutētājam, kuram patiešām pieder galamērķa tīkls. Ja kāds no tiem iztrūkst, simptoms izskatās identisks.

Pirms maināt noteikumu, izsekojiet vienai paketei cauri šiem trim lēmumiem, jo katram īpašniekam ir cita kontrole un cits atteices režīms.

Viena pakete, trīs maršrutēšanas lēmumi

Klients izlemj, vai galamērķis pieder tunelim, un viņš var izlemt tikai no tā, ko zina: stumta maršruta, vietējā maršruta vai noklusējuma maršruta, kas jau aptver visu. pfSense izlemj, kur paketi sūtīt tālāk, un tīklam aiz cita maršrutētāja tas nozīmē statisku maršrutu caur sasniedzamu vārteju pareizajā saskarnē. Apakšējais maršrutētājs izlemj, vai zina ceļu atpakaļ uz VPN baseinu, un, ja nezina, atbilde tiek izmesta vai nosūtīta uz neizdevīgu vietu. Katrs lēmums ir neatkarīgs no pārējiem diviem.

Jebkura no tiem atteice dod vienu un to pašu lietotāja ziņojumu. Tāpēc atkļūdošanas secība ir svarīgāka par rīkiem.

Dodiet klientam prefiksu, nevis minējumu

pfSense SSL/TLS serverī, kura IPv4 tuneļa tīkls ir lielāks par /30, lauks IPv4 Local network(s) pievienošanās laikā izplata maršrutus klientiem. Pievienojiet tur apakšējo prefiksu, nevis paļaujieties, ka klients to izdomās. Pēc tam pēc pievienošanās izlasiet klienta faktisko tabulu, jo profils ar route-nopull vai maršrutu filtrs var ignorēt to, ko serveris nosūtīja. Serveris var būt pilnīgi pareizs, kamēr klients neko neinstalē.

Citiem servera režīmiem un topoloģijām ir citas robežas, un politika katram klientam vai savienojumam var mainīt to, ko saņem konkrēts klients. Pārbaudiet uz tā klienta, kuram ir nozīme, nevis uz tā, kuru nejauši pārbaudījāt pirmo.

Pavērsiet pfSense uz iekšējo maršrutētāju

Statiskam maršrutam pfSense ir vajadzīga definēta un sasniedzama vārteja, un šai vārtejai izvēlētajai saskarnei jābūt tai, kas to patiešām sasniedz, kā apraksta Netgate statisko maršrutu rokasgrāmata. Ilustratīvā izkārtojumā tranzīta saite ir 192.168.77.1 uz ugunsmūra un 192.168.77.2 uz iekšējā maršrutētāja, un pakalpojumu tīkls ir 172.16.30.0/25 aiz tā. Tad maršruts nosauc prefiksu un nākamo lēcienu, nevis pakalpojuma adresi. Adreses no tālā tīkla izmantošana kā vārteja ir izplatīts veids, kā izveidot maršrutu, kas izskatās pareizs un nekur nepārsūta.

Saskarnes nosaukšana neapraksta aiz tās esošos tīklus. Statiskais maršruts ir tas apraksts.

Tālajai pusei jāzina baseins

Apakšējam maršrutētājam vajadzīgs atgriešanās maršruts uz baseinu, šajā piemērā 10.55.0.0/24 caur 192.168.77.1, ja vien noklusējuma maršruts vai dinamiskais protokols jau nenodrošina tādu. Paša pakalpojuma resursdatora vārtejai jāved uz šo maršrutētāju, kas parasti ir taisnība, ja maršrutētājs ir tā noklusējuma vārteja, un nav taisnība, ja resursdators tika konfigurēts manuāli. Politikas maršrutēšana uz ugunsmūra arī var ignorēt tabulu konkrētam trafikam, tāpēc pirms secināt, ka maršruts ir nepareizs, pārbaudiet, vai noteikums neizvēlas citu vārteju.

Šim risinājumam tulkošana nav nepieciešama, un klienta avota adreses redzamība ļauj apakšējam tīklam piemērot savu politiku.

Pieņemšanai izsekojiet vienam jaunam pieprasījumam cauri tuneļa ieejai, ugunsmūra iekšējai izejai un atbildei no galamērķa. Ja tā vietā apzināti tiek izmantota tulkošana, pierakstiet, kādu avotu redz apakšējais tīkls un kā atbildei paredzēts atgriezties.

Saglabājiet trīs īpašnieku plānu līdzās atļautajai lietojumprogrammai, lai nākamais administrators varētu atjaunot ceļu, nevis to no jauna atklāt.