VPN-reitti vai palomuurisääntö: kumpi pudottaa paketin?

Samaan pakettiin kohdistuu kaksi riippumatonta päätöstä, ja kumpi tahansa voi lopettaa pyynnön äänettömästi. Reittihaku valitsee rajapinnan ja seuraavan hypyn, sitten pakettisuodatin päättää, sallitaanko tuo yhdistelmä. Aikakatkaisu kertoo, että toinen kahdesta kieltäytyi, ei kumpi. Käy vaiheet järjestyksessä läpi, ja korjaus lakkaa yleensä olemasta arvaus.

Kaksi päätöstä, yksi paketti, kaksi omistajaa

Reittihaku kysyy ensin käytäntösäännöt, sitten taulun, johon ne osoittavat, ja valitsee tarkimman etuliitteen, joka vastaa kohdetta. Asiakas, joka on asentanut tunnelireitin, omistaa tämän päätöksen, eikä mikään palomuurisäännössä voi korvata sitä. Kun haku osoittaa odottamattomaan paikkaan, jokainen myöhempi vaihe työstää väärää pakettia.

Suodatus on erillistä. Linux-isännässä netfilter-koukut jakavat liikenteen sen mukaan, kenelle paketti on: lähtö poistuu koneesta, tulo päättyy siihen, edelleenlähetys kulkee sen läpi. Yhdyskäytävä, joka ottaa vastaan VPN-asiakkaita ja reitittää ne lähiverkkoon, tarvitsee edelleenlähetyspolun, ja juuri sen ketjun useimmat oletusasetukset jättävät tyhjäksi.

Lähteen valinta kuuluu samaan päätökseen, ja siihen useimmat epäsopivuudet kätkeytyvät. Ydin valitsee lähdeosoitteen lähtevältä rajapinnalta, ellei reitti nimeä yhtä, joten lähiverkolle kirjoitettu suodatinsääntö ei koskaan osu pakettiin, joka lähtee tunneliosoitteella.

Lue, minkä haku todella valitsi

Tulosta päätös sen sijaan, että päättelet sen. Alla oleva komento selvittää reitin, jota ydin käyttäisi kyseiseen kohteeseen, mukaan lukien rajapinta ja lähde, jonka se valitsisi:

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

VPN-asiakkaat asentavat usein käytäntösääntöjä päätaulun alapuolelle, joten puhdas päätaulukko ei todista itsessään mitään. Vertaa sääntöjen prioriteetteja tauluihin, jotka ne valitsevat, ja tarkista, säilyykö tunnelireitti uudelleenyhdistämisen jälkeen sen sijaan, että se lisättäisiin kerran käsin.

Käytäntöpohjainen IPsec lisää kolmannen sovitusvaiheen, jota reititys ei kata, kuten strongSwanin edelleenlähetysmuistiinpanot kuvaavat tunnelia ja siirtoa koskeville asetuksille. Suojauskäytäntö valitsee liikenteen etuliitteen ja protokollan mukaan, kun taas reitti päättää vain, minne suojaamaton paketti menisi. Aliverkko, joka on reititetty mutta jolla ei ole vastaavaa valitsinta, joko jää suojaamatta tai pudotetaan asetuksista riippuen, eikä kumpikaan lopputulos näytä palomuuriongelmalta. Tulosta käytäntö ja vertaa sen valitsimia etuliitteisiin, joiden odotit tunnelin kuljettavan.

Suodatus vaikuttaa koukussa, ei reitillä

Sääntö, joka sallii VPN-kuuntelijan, on sääntö yhdyskäytävälle itselleen osoitetusta liikenteestä. Se ei kerro mitään asiakkaista, jotka saavuttavat isäntiä tuon yhdyskäytävän takana, koska edelleenlähetetty liikenne kulkee eri ketjun läpi. Sääntökokonaisuuden lukeminen yhtenä litteänä listana on tavallinen syy siihen, ettei oikealta näyttävä sääntö koskaan laukea.

Laskurit ratkaisevat kysymyksen nopeasti. Sääntöön, jonka pakettilaskuri on nolla, ei koskaan päästy, mikä viittaa väärään ketjuun, väärään rajapintaan tai aiempaan pudotukseen. Sääntö, jonka laskuri kasvaa pudotuskäytännön alla, on etsimäsi raja, ja paketti hylätään eikä reititetä väärin.

Lähetä koe samaa polkua pitkin, jota asiakas käyttää

Yhdyskäytävällä itsellään ajetut testit kulkevat lähdön ja tulon kautta yhdyskäytävän omalla lähdeosoitteella. Se on eri polku kuin asiakkaan edelleenlähettämä pyyntö, joten onnistunut paikallinen curl todistaa vähemmän kuin näyttää. Testaa koneelta, joka epäonnistuu, tai kiinnitä rajapinta ja lähde nimenomaisesti.

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

Kaappaus molemmissa päissä erottaa jäljellä olevat tapaukset. SYN, joka lähtee asiakkaalta eikä koskaan saavu, tarkoittaa reititystä, salausta tai ylävirran käyttöluetteloa. SYN, joka saapuu eikä saa vastausta, tarkoittaa palvelua tai sen isäntäsuodatinta, eikä tunneli ollut koskaan ongelma.

Paluuliikenne ansaitsee oman katsauksensa. Epäsymmetrinen reititys ja käänteisen polun suodatus pudottavat vastaukset, jotka saapuvat väärälle rajapinnalle, mikä näkyy yksisuuntaisena yhteytenä eikä estettynä porttina. Tarkista sysctl-arvo ennen kuin syytät palomuuria oireesta, jota se ei aiheuttanut.

Lokitus toimii toisena mielipiteenä, ei ensimmäisenä askeleena. Tilapäinen lokilause edelleenlähetysketjussa nimeää rajapinnan ja osoitteet, jotka osuivat siihen, ja se on helppo poistaa jälkeenpäin. Jätä se pysyväksi, niin olet rakentanut vastauksen sijaan lokimääräongelman.

Sijoita jokainen muutos sinne, missä se säilyy uudelleenyhdistämisen yli

Komennolla ip route add lisätty reitti elää, kunnes rajapinta menee alas. Tallenna se sen sijaan yhteyden profiiliin: NetworkManager hyväksyy ylimääräiset reitit yhteydelle, ja netplan säilyttää ne käynnistysten yli. Sama sääntö koskee asiakaspuolen palomuuripoikkeusta, joka on poissa seuraavan uudelleenlatauksen jälkeen.

Palvelinpuolen säännöt kuuluvat asetustiedostoon, jonka palvelu lataa käynnistyessään, eivät interaktiiviseen istuntoon, joka päättyy, kun suljet sen. Kirjoita sääntö, lataa uudelleen ja vahvista, että laskuri liikkui, koska syntaksin hylännyt uudelleenlataus jättää vanhan sääntökokonaisuuden äänettömästi paikoilleen.

Toista sitten alkuperäinen sovelluspyyntö päästä päähän ja kirjaa, mikä kerros muuttui. Reittikorjaus, joka tarvitsi myös suodatinmuutoksen, epäonnistuu silti, ja toinen epäonnistuminen on paljon helpompi lukea, kun tiedät, että ensimmäinen on poissa. Merkitse päivämäärä ja asiakasversio tuloksen viereen, koska sekä reitityksen että suodatuksen oletukset liikkuvat versioiden välillä. Pidä merkintä tikettissä, jotta seuraava aloittaa siitä, mihin sinä lopetit, sen sijaan että toistaisi kaksivaiheisen kierroksen.