VPN on yhdistetty, mutta palomuuri estää silti: miten selvittää kumpi

Asiakas ilmoittaa yhteyden muodostetuksi, resurssi kieltäytyy edelleen, ja tavallinen seuraava askel on kytkeä jotain pois päältä. Tuon lauseen molemmat valvonnat tekevät eri työtä: VPN rakentaa polun katetulle liikenteelle ja palomuuri päättää yhteyksittäin, saako liikenne kulkea. Toimiva tunneli kieltäytyvällä käytännöllä näyttää käyttäjän tuolilta täsmälleen rikkinäiseltä tunnelilta, joten tehtävä on löytää, mikä kerros vastaa. Tässä on järjestys, jota noudatan, sekä lukeminen, joka käskee pysähtyä.

Erottele polku käytännöstä

Aloita vian muodosta, koska se on ilmaista tietoa. Paketin pudottaminen tuottaa aikakatkaisun: asiakas yrittää uudelleen, mitään ei tule takaisin ja komento roikkuu, kunnes se luovuttaa. Hylkäys tuottaa kieltäytymisen tai nollauksen: jokin vastasi ja sanoi ei. Palvelu, joka ei kuuntele, kieltäytyy itse isännällä, ilman palomuuria lainkaan.

Nämä kolme lopputulosta osoittavat eri kerroksiin. Aikakatkaisu tarkoittaa, että jossain käytäntö pudottaa hiljaa, tai että reitti ei koskaan poistu koneesta. Hylätty tarkoittaa, että pääsit isäntään ja sen pino tai paikallinen palomuuri kieltäytyi. Täysi hiljaisuus, kun tunnelin liitäntä on ylhäällä eikä reittiä kohteeseen ole, tarkoittaa, että polku on väärä eikä mikään palomuurisääntö korjaa sitä.

Lue polku yhdellä kierroksella

Varmista, että tunneli kattaa kohteen, ennen kuin katsot yhtäkään sääntöä. Jaettu tunneli, joka kuljettaa vain toimiston aliverkkoa, ei reititä pyyntöä toiseen alueeseen, ja silloin vika näyttää palomuurin estolta, jota se ei ole:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

Reitin tuloste nimeää liitännän, josta paketti lähtee, ja lähdeosoitteen, jota se kantaa. Jos tuo liitäntä on fyysinen verkkokorttisi eikä tunneli, ongelma on reitityksessä tai tunnelin sallituissa alueissa, ja se kuuluu VPN:n kokoonpanoon eikä palomuuriin.

Yksi VPN:lle ominainen ansa ansaitsee oman tarkistuksensa. WireGuardissa vertaisparin AllowedIPs on samalla reitti ja salaussuodatin: paketti, jonka lähdeosoite ei kuulu parin sallittuun joukkoon, pudotetaan ennen kuin yhtäkään palomuurisääntöä tutkitaan. Niinpä täysin oikea isäntäpalomuuri voi olla hiljaisen pudotuksen takana, joka näyttää käytännöltä, ja korjaus on avaimen kokoonpanorivi eikä sääntö.

Lue käytäntö kerroksessa, joka vastaa

Kun polku on oikea, käy käytäntö läpi isännästä ulospäin ja seuraa sitä yhtä kerrosta, jonka laskurit liikkuvat:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

Kuunteleva pistoke vastaa eri kysymykseen kuin säännöt. Jos portilla ei kuuntele mikään, ydin kieltäytyy yhteydestä eikä mikään saapuva sääntö ole merkityksellinen. Jos pistoke on olemassa ja yhteys etäasiakkaasta aikakatkeaa, pudotus tapahtuu jossain polulla, ja sääntöjen laskurit kertovat, tapahtuuko se täällä.

Kytke kirjaus päälle profiilille tai ketjulle, jota epäilet, sen sijaan että arvaisit ulkopuolelta. Yksi kirjattu pudotus, joka nimeää lähteen, kohteen ja portin, tunnistaa kerroksen ja säännön, ja se myös todistaa, että paketti saapui, mitä mikään asiakaspuolen testi ei voi todeta.

Lue yhdyskäytävän päätös, kun tunneli päättyy sinne

Sivusto-sivusto- tai etäkäyttöyhdyskäytävässä VPN todentaa käyttäjän ja käytäntö valtuuttaa resurssin, ja ne ovat erillisiä myönnytyksiä. Tunneliin päästetty käyttäjä ei pääse automaattisesti jokaiseen sisäiseen isäntään, ja kieltäytyminen tulee usein edelleenlähetyssäännöstä, kun itse tunneli on kunnossa. Sama erottelu näkyy IPsecissä, jossa liikenteen valitseva tietoturvakäytäntö eroaa suodattimesta, joka päästää sen läpi, ja siksi ne on dokumentoitu eri mekanismeina RFC 4301.

Tarkista paluupolku yhtä huolellisesti kuin lähtevä. Tilallinen suodatus tarvitsee nähdä vastauksen, joten epäsymmetrinen reititys tunnelin kautta toiseen suuntaan ja sen ympäri toiseen tuottaa pudotuksia, jotka näyttävät satunnaisilta ja toistuvat vain joillakin asiakkailla. Jos liikenne saapuu yhdyskäytävälle ja pysähtyy, lue edelleenlähetyssääntö ja paluureitti yhdessä ennen kuin laajennat mitään.

Yhdyskäytävä on myös paikka, jossa NAT- tai maskeraussääntö voi piilottaa todellisen lähteen. Jos sisäiset isännät näkevät yhdyskäytävän osoitteen asiakkaan sijaan, niiden isäntäpalomuurin säännöt, joiden pitäisi osua asiakaspooliin, eivät koskaan osu, ja korjaus kuuluu yhdyskäytävälle, ei jokaiselle palvelimelle.

Muuta kapeinta kerrosta ja tarkista sitten

Vastusta laajaa korjausta. Isäntäpalomuurin poiskytkeminen, kaiken sallivan säännön lisääminen tai jokaisen liitännän pakottaminen luotettuun profiiliin poistaa kulloinkin valvonnan, joka teki työnsä, ja muutos elää tapauksen yli. Lähdealueeseen ja kyseiseen porttiin rajattu sääntö on helpompi tarkistaa, helpompi poistaa, ja se jättää koneen muun käytännön ennalleen.

Tarkista samalla testillä, joka epäonnistui, samalta asiakkaalta, ja sitten vielä kerran uudelleenyhdistämisen jälkeen, koska sääntö, joka osui ennen kuin tunneli neuvottelee uudelleen, voi lakkautua osumasta sen jälkeen:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Ennen kuin suljet asian:

• Reitti kohteeseen lähtee tunnelin liitännästä, ja lähdeosoite vastaa sitä, mitä käytäntö odottaa.
• Portilla kuuntelee jotain, ja kieltäytyminen tai aikakatkaisu kohdistetaan nimettyyn sääntöön eikä oleteta.
• Yhdyskäytävä välittää molempiin suuntiin, ja kohde näkee lähteen, jota varten sääntösi kirjoitettiin.
• Yhtäkään valvontaa ei kytketty pois testin läpäisemiseksi, ja tekemäsi muutos nimeää yhden lähdealueen ja yhden portin.