Kannettavasi pääsee pfSense-LANiin VPN:n kautta eikä silti tavoita palvelua kaksi hyppyä kauempaa, ja ero on yksi reitityspäätös omistajaa kohden. Kolmen laitteen on sovittava ennen kuin paketti suorittaa edestakaisen matkansa: asiakas, palomuuri ja reititin, joka todella omistaa kohdeverkon. Jos jokin niistä puuttuu, oire näyttää samalta.

Seuraa yhtä pakettia näiden kolmen päätöksen läpi ennen säännön muuttamista, koska jokaisella omistajalla on eri hallinta ja eri vikatila.

Yksi paketti, kolme reitityspäätöstä

Asiakas päättää, kuuluuko kohde tunneliin, ja se voi päättää vain sen perusteella, mitä tietää: työnnetty reitti, paikallinen reitti tai oletusreitti, joka jo kattaa kaiken. pfSense päättää, minne paketti lähetetään seuraavaksi, mikä toisen reitittimen takana olevalle verkolle tarkoittaa staattista reittiä tavoitettavan yhdyskäytävän kautta oikealla liitännällä. Alempi reititin päättää, tunteeko se paluutien VPN-altaaseen, ja jos ei tunne, vastaus hylätään tai lähetetään hyödyttömään paikkaan. Jokainen päätös on riippumaton kahdesta muusta.

Minkä tahansa niistä pettäminen tuottaa saman käyttäjäraportin. Siksi vianetsinnän järjestys on tärkeämpi kuin työkalut.

Anna asiakkaalle etuliite, älä arvausta

pfSense SSL/TLS-palvelimella, jonka IPv4-tunneliverkko on suurempi kuin /30, kenttä IPv4 Local network(s) jakaa reitit asiakkaille niiden yhdistäessä. Lisää alemman tason etuliite sinne sen sijaan, että luottaisit asiakkaan keksivän sellaisen. Lue sitten asiakkaan todellinen taulukko yhdistämisen jälkeen, koska profiili, jossa on route-nopull, tai reittisuodatin voi jättää huomiotta sen, mitä palvelin lähetti. Palvelin voi olla täysin oikeassa, kun asiakas ei asenna mitään.

Muilla palvelintiloilla ja topologioilla on eri rajat, ja asiakas- tai yhteyiskohtainen käytäntö voi muuttaa sitä, mitä tietty asiakas saa. Vahvista asiakkaalla, jolla on merkitystä, älä sillä, jonka satuit testaamaan ensin.

Suuntaa pfSense sisäiseen reitittimeen

Staattinen reitti pfSensessä tarvitsee määritellyn ja tavoitettavan yhdyskäytävän, ja kyseiselle yhdyskäytävälle valitun liitännän on oltava se, joka todella tavoittaa sen, kuten Netgaten staattisten reittien opas kuvaa. Havainnollisessa asetelmassa läpikulkulinkki on 192.168.77.1 palomuurilla ja 192.168.77.2 sisäisellä reitittimellä, ja palveluverkko on 172.16.30.0/25 sen takana. Sitten reitti nimeää etuliitteen ja seuraavan hypyn, ei palvelun osoitetta. Kaukoverkon osoitteen käyttäminen yhdyskäytävänä on yleinen tapa rakentaa reitti, joka näyttää oikealta eikä välitä mihinkään.

Liitännän nimeäminen ei kuvaa sen takana olevia verkkoja. Staattinen reitti on se kuvaus.

Kaukaisen puolen on tunnettava allas

Alempi reititin tarvitsee paluureitin altaalle, tässä esimerkissä 10.55.0.0/24 kautta 192.168.77.1, ellei oletusreitti tai dynaaminen protokolla jo tarjoa sellaista. Palvelun isäntäkoneen oma yhdyskäytävä on johdettava kohti tuota reititintä, mikä on yleensä totta, kun reititin on sen oletusyhdyskäytävä, ja epätotta, kun isäntä konfiguroitiin käsin. Palomuurin käytäntöpohjainen reititys voi myös ohittaa taulukon tietylle liikenteelle, joten tarkista, valitseeko sääntö toisen yhdyskäytävän, ennen kuin päättelet reitin olevan väärä.

Tämä rakenne ei vaadi käännöstä, ja asiakkaan lähdeosoitteen näkyvänä pitäminen antaa alemman verkon soveltaa omaa käytäntöään.

Hyväksyntää varten seuraa yhtä uutta pyyntöä tunnelin sisäänkäynnin, palomuurin sisäisen ulostulon ja kohteen vastauksen läpi. Jos käännöstä sen sijaan käytetään tarkoituksella, kirjaa, minkä lähteen alempi verkko näkee ja miten vastauksen odotetaan palaavan.

Tallenna kolmen omistajan suunnitelma sallitun sovelluksen viereen, jotta seuraava ylläpitäjä voi rakentaa polun uudelleen sen sijaan, että löytäisi sen uudestaan.

Aiheeseen liittyvät artikkelit