Yhden portin ohittaminen VPN:stä vaatii käytäntöpohjaista reititystä

Pyyntö on aina saman lauseen muunnelma: pidä VPN selailua varten, mutta anna SSH:n tai varmuuskopiointityön käyttää tavallista yhteyttä. Asiaa kiertävä neuvo, portin välittäminen iptablesin NAT-säännöillä, ei tee sitä. NAT-sääntö kirjoittaa uudelleen vuon sisäisiä osoitteita ja portteja; se ei koskaan valitse, mistä liitännästä paketti lähtee. Päätös kuuluu reitityshakuun, ja reitityshaku tarvitsee apua nähdäkseen portin.

Miksi tavallinen reitti ei voi osua porttiin

Linux valitsee reitin hakemalla kohdeosoitteen taulusta, kun ehdokastaulut on ensin suodatettu käytäntösäännöillä. Ne säännöt voivat osua palomuurimerkkiin, lähdeosoitteeseen, saapuvaan liitäntään tai UID:hen. Reittimerkinnällä itsellään ei ole porttikenttää, koska reitti valitaan ennen kuin kuljetusotsake merkitsee.

Nykyiset iproute2 ja ytimet laajentavat säännön valitsinta: ipproto, sport ja dport hyväksytään, joten ip rule add ipproto tcp dport 22 table 100 ilmaisee aikomuksen yhdellä rivillä. Suorita ip rule add help oikealla isännällä ja katso, listaako koontiversiosi dport. Jos listaa, olet valmis yhdellä komennolla; jos ei, alla oleva merkkipolku on vastaava.

Kummassakin tapauksessa sääntö on vain osoitin. Taulu 100 tarvitsee silti reitin, ja juuri sen osan ihmiset unohtavat.

Kolme osaa tai yksi

Nykymuoto on yllä oleva yksittäinen sääntö sekä reitti vaihtoehtoisessa taulussa. Klassinen muoto lisää netfilterin väliin: merkitse paketti ja sovita sitten merkki säännössä. Molemmat päättyvät samaan hakuun; ne eroavat siinä, missä portti luetaan.

Merkkimenetelmä on olemassa, koska netfilter näkee kuljetusotsakkeen ja reitityskoodi ei historiallisesti nähnyt. Se on koko mekanismi, ja se selittää, miksi varavaihtoehto on kolme yhteistyössä toimivaa osaa eikä yksi ovela komento.

Kolme osaa järjestyksessä

Merkitse ensin ne vuot, jotka haluat ohjata toisaalle, ketjussa, joka ajetaan tarpeeksi aikaisin, jotta merkki on olemassa ennen reittipäätöstä:

nft add table inet vpnexempt
nft 'add chain inet vpnexempt out { type route hook output priority mangle; }'
nft add rule inet vpnexempt out tcp dport 22 meta mark set 0x1

Lähetä toiseksi merkityt paketit erilliseen tauluun:

ip rule add fwmark 0x1/0x1 table 100

Anna kolmanneksi sille taululle oletusreitti fyysisen linkin kautta. Osoitteet ovat esimerkinomaisia; korvaa ne omillasi:

ip route add default via 192.168.1.1 dev wlan0 table 100

Jätä kolmas vaihe väliin, niin merkitty paketti ei löydä reittiä taulusta 100 ja epäonnistuu. Oire näyttää siltä kuin sääntö olisi rikkonut verkon, vaikka se todellisuudessa poisti ainoan polun, joka paketille oli jäljellä.

Mikä pitää sen toiminnassa ensimmäisen paketin jälkeen

Merkit koskevat lähteviä paketteja. Vastaus saapuu fyysiselle liitännälle osoitteella, jonka linkki on määrittänyt, ja päätaulu voi yhä suosia tunnelia kyseiselle kohteelle. Kaksi mekanismia pitää vastauspolun johdonmukaisena: lähdeperusteinen sääntö linkin osoitteelle ja yhteyksien seuranta, joka säilyttää päätöksen koko vuon eliniän. Merkin tallentaminen conntrackiin ja palauttaminen vastauksessa on tavallinen tapa tehdä tilallisesta poikkeuksesta vakaa.

Käänteisen polun suodatus on toinen hiljainen tappaja. Jos ydin validoi paluupolun tiukasti ja vastaus saapuu liitännälle, jota päätaulu ei valitsisi, paketti pudotetaan ilman ilmoitusta. rp_filter oletusarvot vaihtelevat jakelun mukaan ja sen mukaan, välitetäänkö liitäntää, joten lue todellinen arvo sen sijaan että olettaisit sen olevan pois päältä.

Älä merkitse tunnelin omaa kuljetusta. WireGuard- tai UDP OpenVPN -tunneli ei ole TCP 22, joten yllä oleva resepti on turvallinen, mutta poikkeus, joka on kirjoitettu muotoon kaikki paitsi tunnelin kohde, voi napata salatut paketit ja rikkoa tunnelin tavalla, joka näyttää reitityssilmukalta.

Tarkista sen sijaan että olettaisit

Kysy ytimeltä, minkä polun se valitsisi, kohteen ja portin osalta, ja aja sitten todellinen siirto:

ip route get 203.0.113.10
ip rule show
nft list ruleset

Jos merkki on olemassa mutta laskurit eivät koskaan liiku, sääntö ei osu. Laskurit ovat ero kirjoittamasi kokoonpanon ja ytimen soveltaman käytännön välillä.

Milloin tämä on väärä työkalu

Porttiin perustuvat poikkeukset ovat luonteeltaan hauraita. Palvelut vaihtavat portteja, HTTP/3 saapuu UDP 443:na, ja yksi sovellus voi avata useita erilaisia vuotoja. Jos todellinen vaatimus on, että tämä ohjelma käyttää tavallista linkkiä, reitityskerros on väärä paikka; verkkonimiavaruus tai sovelluskohtainen välityspalvelin sopii paremmin.

Jos vaatimus on, että tämä aliverkko käyttää tavallista linkkiä, jätä merkit kokonaan pois ja lisää täsmällisempi reitti. Se on yksinkertaisempi, näkyy yhdessä taulussa, ja seuraava henkilö voi auditoida sen lukematta sääntöjoukkoa.

Kirjoita ylös, mikä kolmesta vaatimuksesta sinulla todella on, ennen kuin kosket palomuuriin. Yllä oleva mekanismi on täsmällinen, ja väärään kerrokseen sovellettu täsmällisyys on vain pidempi katkos.