pfSense OpenVPN: teise ruuteri taga olevasse võrku pääsemine

Sinu sülearvuti jõuab VPN-i kaudu pfSense'i LAN-i, kuid ei suuda ikkagi jõuda teenuseni, mis on veel kahe hüppe kaugusel, ja erinevus on üks marsruutimisotsus omaniku kohta. Kolm seadet peavad kokku leppima, enne kui pakett oma edasi-tagasi teekonna lõpetab: klient, tulemüür ja ruuter, millele sihtvõrk tegelikult kuulub. Kui üks neist puudub, näeb sümptom välja identne.

Järgi ühte paketti nende kolme otsuse kaudu enne reegli muutmist, sest igal omanikul on erinev juhtimine ja erinev tõrkerežiim.

Üks pakett, kolm marsruutimisotsust

Klient otsustab, kas sihtkoht kuulub tunnelisse, ja ta saab otsustada ainult selle põhjal, mida ta teab: lükatud marsruut, kohalik marsruut või vaikimisi marsruut, mis juba katab kõik. pfSense otsustab, kuhu pakett järgmisena saata, mis tähendab teise ruuteri taga oleva võrgu jaoks staatilist marsruuti läbi kättesaadava lüüsi õigel liidesel. Allavoolu ruuter otsustab, kas ta teab teed tagasi VPN-i basseini, ja kui ei tea, visatakse vastus ära või saadetakse kasutusse mittekuuluvasse kohta. Iga otsus on kahest teisest sõltumatu.

Ükskõik millise neist tõrge annab sama kasutajateate. Seetõttu loeb silumise järjekord rohkem kui tööriistad.

Anna kliendile prefiks, mitte oletus

pfSense SSL/TLS-serveris, mille IPv4 tunnelivõrk on suurem kui /30, jagab väli IPv4 Local network(s) marsruute klientidele nende ühendamisel. Lisa allavoolu prefiks sinna, selle asemel et loota, et klient selle ise välja mõtleb. Seejärel loe kliendi tegelikku tabelit pärast ühendamist, sest profiil koos route-nopull või marsruudifilter võib eirata seda, mida server saatis. Server võib olla täiesti korrektne, samal ajal kui klient ei paigalda midagi.

Teistel serverirežiimidel ja topoloogiatel on erinevad piirid ning kliendi- või ühendusepõhine poliitika võib muuta seda, mida konkreetne klient saab. Kontrolli sellel kliendil, mis on oluline, mitte sellel, mida juhtusid esimesena testima.

Suuna pfSense sisemisele ruuterile

Staatiline marsruut pfSense'is vajab määratletud ja kättesaadavat lüüsi ning selle lüüsi jaoks valitud liides peab olema see, mis sinna tegelikult jõuab, nagu kirjeldab Netgate'i staatiliste marsruutide juhend. Illustratiivses paigutuses on transiitlink tulemüüril 192.168.77.1 ja sisemisel ruuteril 192.168.77.2, teenusvõrk on selle taga 172.16.30.0/25. Seejärel nimetab marsruut prefiksi ja järgmise hüppe, mitte teenuse aadressi. Kauge võrgu aadressi kasutamine lüüsina on tavaline viis ehitada marsruut, mis näeb õige välja ega edasta kuhugi.

Liidesele nime andmine ei kirjelda selle taga olevaid võrke. Staatiline marsruut on see kirjeldus.

Kaugem pool peab basseini teadma

Allavoolu ruuter vajab basseini jaoks tagasiteed, selles näites 10.55.0.0/24 läbi 192.168.77.1, kui vaikimisi marsruut või dünaamiline protokoll ei paku seda juba. Teenusehosti enda lüüs peab viima selle ruuteri poole, mis on tavaliselt tõsi, kui ruuter on selle vaikelüüs, ja vale, kui host seadistati käsitsi. Tulemüüri poliitikapõhine marsruutimine võib samuti tabelit konkreetse liikluse jaoks mööda minna, seega kontrolli, kas reegel valib teise lüüsi, enne kui järeldad, et marsruut on vale.

See lahendus ei vaja tõlkimist ja kliendi lähteaadressi nähtavana hoidmine lubab allavoolu võrgul rakendada oma poliitikat.

Vastuvõtu jaoks jälgi üht uut päringut tunnelisse sisenemisest, tulemüüri sisemisest väljumisest ja sihtkohast tulevast vastusest. Kui selle asemel kasutatakse teadlikult tõlkimist, pane kirja, millist allikat allavoolu võrk näeb ja kuidas vastus peaks tagasi tulema.

Salvesta kolme omaniku plaan koos lubatud rakendusega, et järgmine administraator saaks tee rekonstrueerida, mitte selle uuesti avastada.