Mihin pakettiin kahden WANin VPN-käytännön pitää osua?

Pyynnöt reitittää VPN toisen uplinkin kautta kuvaavat vähintään kahta eri työtä, eikä toisen korjaava käytäntö kosketa toista. Ensimmäisessä työssä kahden päätepisteen välinen salattu siirto siirtyy toiseen WAN-osoitteeseen. Toisessa yhteydessä olevan käyttäjän purettu sovellusvirta poistuu kohti toista seuraavaa hyppyä. Molemmat ovat laillisia, molemmat käyttävät reititystä, ja kumpikin tarvitsee osuman pakettiin, joka on olemassa päätöksentekopisteessä. Käy alla olevat tarkistukset järjestyksessä läpi, koska ensimmäinen määrää, mihin pakettiin myöhempien sääntöjen on viitattava.

Nimeä kaksi keskustelua

Kuvittele etätyöntekijä, joka on kytketty toimiston yhdyskäytävään ja avaa HTTPS:n sisäiseen sovelluspalvelimeen. Johdolla on kaksi riippumatonta keskustelua, ja niillä on eri osoitteet kummassakin päässä. Ulompi keskustelu kulkee kahden VPN-päätepisteen välillä: yhdyskäytävän osoitteesta vertaisosoitteeseen, siinä protokollassa ja portissa, josta käyttöönotto sopi. Sisempi keskustelu kulkee asiakkaalle annetusta osoitteesta sovelluspalvelimen osoitteeseen portissa 443.

Sovelluksen kohdeportti ei ole VPN:n siirtoportti, eikä mikään määrä käytäntöä TCP 443:ssa siirrä tunnelia. Samoin sääntö, joka ohjaa vertaisen siirtoosoitteen uudelleen, ei kerro mitään siitä, mihin kyseisen käyttäjän HTTP-pyyntö purkamisen jälkeen menee. Kirjoita molemmat keskustelut todellisilla osoitteillaan ennen kuin kosket sääntöön, koska suurin osa tämän alueen sekaannuksesta syntyy siitä, että toinen nimetään ja toinen määritetään.

Selvitä, missä käytäntösi todella näkee paketin

Osuma on arvioitava siinä ketjussa ja nimiavaruudessa, jossa paketti on vielä kuvaamassasi muodossa. LAN-sisäänkäyntiin liitetty sääntö näkee sisemmän paketin salaamattomana ennen kuin se reititetään tunnelia kohti. Paikallisesti syntyvään liikenteeseen sovellettu sääntö näkee paketit, jotka yhdyskäytävä itse luo, eikä se automaattisesti kata liikennettä, jonka yhdyskäytävä vain välittää. Kapseloitu lähtevä liikenne on taas kolmas tapaus, jota yleensä käsitellään tunnelia kantavassa rajapinnassa eikä LAN-puolella.

Siksi sama määrityksen pätkä käyttäytyy eri tavalla kahdella alustalla: kiinnityspisteet eroavat, ja toimittajan käytäntökoukku voi olla ennen salausvaihetta tai sen jälkeen. Lue paketin polku kyseiselle tuotteelle sen sijaan, että olettaisit järjestyksen toisen toimittajan kaaviosta.

Vahvista sopimasi siirto

UDP:hen kapseloidun IPsecin tapauksessa RFC 3948 sijoittaa ESP:n UDP:n sisään ja käyttää merkkiä, joka ei ole ESP, jotta IKE pysyy erotettavana jaetussa portissa. Pelkkä ESP on IP-protokolla, ei TCP- tai UDP-portti, joten portin numeroon kirjoitettu palomuurisääntö ei osu siihen lainkaan. Tämä ero ratkaisee, tarvitseeko WAN-käytäntösi UDP-säännön, protokollasäännön vai molemmat.

Sovitut arvot voittavat muistetut. Lue liitoksen nykyiset portit ja osoitteet laitteesta sen sijaan, että lisäisit TCP 4500:n tai vanhan toimittajan portin varmuuden vuoksi, mikä nappaa asiattoman liikenteen ja peittää todellisen luokitteluongelman.

Tarkista paluupolku ennen sitoutumista

Lähtevän suunnan onnistuminen todistaa puolet suunnittelusta. Etäasiakkaiden altaaseen palaava paketti ei ole enää näkyvissä asiakkaan osoitteen alla, kun kapselointi korvaa sen: ulompi kohde on vertaisen siirtoosoite. Jos toinen uplink saavuttaa kyseisen vertaisen toisen operaattorin kautta, sen käännös ja suodatus voivat olla eri mieltä ensimmäisen kanssa, ja liitos voi vaatia uudelleenrakentamisen migraation sijaan.

Verkko-osoitteiden käännöksen tila on WAN-vaihdon tavallinen uhri. Kirjaa valittu uplink, odotettu ulompi lähdeosoite, käytössä oleva käännös ja vertaisen tavoitettavuus sinne takaisin, pidä sitten siirto tavoitettavana lähettämättä sitä kantamaansa tunneliin.

Tarkista molemmat kerrokset kahdella kaappauksella

Yksi kaappaus WAN-rajapinnalla ja yksi tunnelin sisällä ratkaisevat kysymyksen nopeammin kuin mikään määritysten vertailu. Aja ne yhdyskäytävältä, kun hyväksytty asiakas tekee yhden pyynnön, ja säilytä molemmat tiedostot.

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

Ensimmäisen kaappauksen pitäisi näyttää ulompi keskustelu poistumassa rajapinnalta, jonka tarkoitit, odotetulla lähdeosoitteella. Toisen pitäisi näyttää sisempi keskustelu kerran, ei kahdesti, asiakkaan osoite lähteenä ja sovelluspalvelin kohteena. Reittihaku vahvistaa, mitä taulukkoa reititin käyttäisi kyseiselle lähde-kohde-parille, ja juuri siellä käytäntövirhe yleensä näkyy. Jos jompikumpi kaappaus ei ilmesty, päätöspiste on jossain muualla kuin siinä, mihin sääntö liitettiin, ja korjaus kuuluu sinne eikä laajempaan osumaan.