Rajaa OpenVPN SNAT -sääntö ennen kuin se rikkoo nginxin

Kaksi vikaa saapuu jatkuvasti samantyyppiseltä isännältä. Ensimmäisessä asiakkaat todennetaan ja he eivät sitten tavoita mitään tunnelin ulkopuolelta. Toisessa VPN nousee ja palvelimen oma verkkosivusto lakkaa vastaamasta, mikä on huolestuttavampi, koska se näyttää sivulliselta vahingolta. Konttipohjaisella VPS:llä molemmat johtuvat yleensä samasta lyhyestä tarkistuslistasta, ja järjestys on tärkeä: ensin laite, toiseksi käännös, kolmanneksi laajuus.

Varmista, että kontti voi luoda tun-laitteen

Millään muulla ei ole väliä, jos tunneliliitäntä ei voi olla olemassa. Tarkista, että /dev/net/tun on olemassa ja että testilaitteen luonti onnistuu, koska monet tarjoajat poistavat tunin käytöstä konteissa oletuksena. Mikään firewall-työ ei korvaa laitetta, jota ei koskaan luotu.

Jos laite puuttuu, vain isäntä tai tarjoaja voi ottaa sen käyttöön. Toinen paketti on usein halvempi kuin viikon kestävä avoin tukiketju. Varmista tämä ennen kuin luet yhtäkään OpenVPN-lokin riviä. Muuten vietät illan säätäen sääntöjä, jotka eivät koskaan näe pakettia.

Päätä, mitä MASQUERADE tekee tällä liitännällä

Tavallisella virtuaalikoneella tavallinen lähtösääntö on POSTROUTING MASQUERADE pääliitännästä. OpenVZ-kontissa näkyvä laite on usein venet0, isännän hallitsema virtuaaliliitäntä eikä reititetty verkkokortti, ja MASQUERADE ei käyttäydy siellä aina niin kuin oppaat olettavat.

Toimiva muoto on eksplisiittinen käännös osoitteeseen, johon asiakkaat jo pääsevät, ja edelleenlähetys on sallittu molempiin suuntiin. Poolin korvaaminen palvelimen kokoonpanosta on yhtä tärkeää kuin osoitteen korvaaminen. Lue jokainen rivi ennen liittämistä.

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Ilman edelleenlähetyssääntöjä käännös tapahtuu silti ja ydin kieltäytyy silti lähettämästä edelleen. Tämä yhdistelmä luo hämmentävän tilan, jossa NAT-säännön laskurit kasvavat, kun asiakas ei saa mitään. Myös kahden FORWARD-rivin on oltava ennen mitä tahansa laajaa drop-sääntöä samassa ketjussa. Järjestys on osa kokoonpanoa, ei toteutuksen yksityiskohta.

Rajaa sääntö yhteen pooliin ja yhteen liitäntään

Toisella oireella on eri syy: POSTROUTING-sääntö, jossa ei ole lähde- eikä lähtörajoitusta. Sellainen sääntö kirjoittaa uudelleen jokaisen isännältä lähtevän paketin.

Palvelut, jotka riippuvat alkuperäisestä lähteestä, käyttäytyvät sen jälkeen väärin. Paikallisen välityspalvelimen takana oleva verkkopalvelin voi lakata vastaamasta, eikä uudelleenkäynnistys muuta mitään, koska sääntö on yhä polulla. Myös liikenne, jonka isäntä lähettää omaan julkiseen osoitteeseensa, kärsii, minkä vuoksi vika voi näyttää DNS- tai varmenneongelmalta eikä firewall-ongelmalta. Sääntö lisättiin lähes varmasti ensimmäisen oireen korjaamiseksi.

Ratkaisu on kaventaa vastaavuus tunnelipooliin ja lähtöliitäntään ja lisätä sitten yksi sääntö poolia kohden sen sijaan, että yhtä sääntöä laajennettaisiin usean kattamiseksi.

Tee säännöistä pysyviä ja selvitä, kuka muu omistaa ne

Käsin lisätyt säännöt katoavat uudelleenkäynnistyksessä, joten tallenna ne iptables-save:lla tai hallitse niitä netfilter-persistent:n kautta siellä, missä se on asennettu. Varmista, että palautus ajetaan ennen kuin OpenVPN käynnistyy. Käynnistä sitten kerran tarkoituksella uudelleen sen sijaan, että löytäisit aukon kesken incidentin.

Kontti-isännällä varmista myös, että pysyvyystiedosto sijaitsee kirjoitettavassa kontin tallennustilassa ja että tarjoaja ei korvaa suodatusta käynnistyksessä. Jotkin alustat hallitsevat käytäntöä kontin ulkopuolella, missä paikalliset säännöt joko ohitetaan tai ne taistelevat isännän omien kanssa.

Varmista laskureilla ja yhdellä kaapatulla virtauksella

Tarkista yhdistetyltä asiakkaalta julkinen osoite, jonka ulkoinen palvelu raportoi. Jos se vastaa palvelimen osoitetta, käännös toimii; jos ei, paketti lähtee toista reittiä tai ei lähde lainkaan. Kokeile sitten sekä palvelimella isännöityä palvelua että julkisen internetin palvelua, koska ne kulkevat eri reittejä saman sääntöjoukon läpi.

Lue palvelimella pakettilaskurit NAT- ja FORWARD-säännöiltä iptables -t nat -L -v -n:llä ja seuraa yhtä virtausta kaappauksessa. Jos asiakkaan osoite näkyy kaappauksessa eikä vastausta seuraa, aukko on paluupolulla tai tarjoajan suodatuksessa, ei asiakasprofiilissa. Vertaa kaapattua lähdettä osoitteeseen, johon sääntö kääntää, koska ero tarkoittaa, että toinen sääntö osui ensin. Yksi havaittu virtaus ratkaisee enemmän kuin sivu kokoonpanon lukemista.

Pidä pool, käännetty osoite ja liitännän nimi yhdessä muutoskirjauksessa. Yhdelle poolille oikea sääntö kääntää seuraavan väärin.