Tvö bilanir koma alltaf frá sama tegund hýsils. Í þeirri fyrri sannvotta biðlarar sig og ná svo engu handan göngunnar. Í þeirri seinni fer VPN-ið upp og eigin vefsíða þjónsins hættir að svara, sem er það alvarlegra því það lítur út eins og aukaskemmdir. Á VPS sem byggir á gámum fer hvort tveggja venjulega aftur í sama stutta athuganalistann, og röðin skiptir máli: tækið fyrst, þýðingin önnur, umfangið þriðja.

Staðfestið að gámurinn geti búið til tun-tæki

Ekkert annað skiptir máli ef gönguviðmótið getur ekki verið til. Athugið að /dev/net/tun sé til staðar og að búið til prófunartæki takist, því margir þjónustuaðilar slökkva á tun í gámum að sjálfgefnu. Ekkert firewall-vinna vegur upp tæki sem var aldrei búið til.

Ef tækið vantar geta aðeins hýsillinn eða þjónustuaðilinn virkjað það. Önnur áætlun er oft ódýrari en opinn stuðningsþráður sem stendur í eina viku. Staðfestið þetta áður en þið lesið eina einustu línu úr OpenVPN-skrá. Annars eyðið þið kvöldinu í að stilla reglur sem munu aldrei sjá pakka.

Ákveðið hvað MASQUERADE gerir á þessu viðmóti

Á venjulegri sýndarvél er venjulega útleiðarreglan POSTROUTING MASQUERADE út aðalviðmótið. Í OpenVZ-gámi er sýnilega tækið oft venet0, sýndarviðmót sem hýsillinn stýrir en ekki beint netkort, og MASQUERADE hagar sér þar ekki alltaf eins og kennsluefni gera ráð fyrir.

Virkjanleg mynd er skýr þýðing yfir á netfangið sem biðlararnir ná þegar til, með framsendingu leyfða í báðar áttir. Að skipta um poolið úr stillingum þjónsins skiptir jafn miklu máli og að skipta um netfangið. Lesið hverja línu áður en þið límið hana.

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

Án framsendingarreglnanna fer þýðingin samt fram og kjarninn neitar samt að framsenda. Sú samsetning skapar ruglingslegt ástand þar sem teljarar á NAT-reglunni hækka á meðan biðlarinn fær ekkert. Einnig þurfa tvær FORWARD-línurnar að standa á undan hverri víðtækri drop-reglu í sömu keðju. Röðin er hluti af stillingunni, ekki útfærsluatriði.

Takmarkið regluna við eitt poól og eitt viðmót

Seinna einkennið hefur aðra orsök: POSTROUTING-regla án takmörkunar á uppruna og án takmörkunar á útleið. Slík regla endurskrifar hvern pakka sem yfirgefur hýsilinn.

Þjónustur sem byggja á upprunalega upprunanum hegða sér þá illa. Vefþjónn bak við staðbundið proxy getur hætt að svara, og endurræsing breytir engu því reglan er enn á leiðinni. Umferð sem hýsillinn sendir á eigið opinbert netfang verður líka fyrir áhrifum, og þess vegna getur bilunin litið út eins og DNS- eða vottorðsvandamál frekar en firewall-vandamál. Reglan var nánast örugglega bætt við til að laga fyrra einkennið.

Lausnin er að þrengja samsvörunina að göngupoolinu og útleiðarviðmótinu, og bæta svo við einni reglu fyrir hvert poól í stað þess að víkka eina reglu til að ná yfir fleiri.

Gerðu reglurnar varanlegar og finnið út hver annar á þær

Reglur sem bætt er við í höndunum hverfa við endurræsingu, svo vistið þær með iptables-save eða stýrið þeim gegnum netfilter-persistent þar sem það er uppsett. Staðfestið að endurheimtin keyri áður en OpenVPN byrjar. Endurræsið svo einu sinni viljandi í stað þess að uppgötva bilið í miðju atviki.

Á gáma-hýsli, staðfestið einnig að varanleikaskráin sé í skrifanlegu geymslurými gámsins og að þjónustuaðilinn skipti ekki um síun við ræsingu. Sumir vettvangar stýra stefnu utan gámsins, þar sem staðbundnar reglur eru annað hvort hunsaðar eða rekast á við eigin reglur hýsilsins.

Sannreynið með teljurum og einu skráðu flæði

Frá tengdum biðlara, athugið opinbera netfangið sem utanaðkomandi þjónusta greinir frá. Ef það passar við netfang þjónsins virkar þýðingin; ef ekki fer pakkinn út um aðra leið eða fer alls ekki út. Prófið svo bæði þjónustu sem hýst er á þjóninum og eina á opinberu internetinu, því þær fara mismunandi leiðir gegnum sama reglusettið.

Á þjóninum, lesið pakkateljarana á NAT- og FORWARD-reglunum með iptables -t nat -L -v -n og fylgist með einu flæði í skráningu. Ef netfang biðlarans birtist í skráningunni og ekkert svar fylgir, er bilið á bakaleiðinni eða í síun þjónustuaðilans, ekki í prófílnum biðlarans. Berið saman skráða upprunann við netfangið sem reglan þýðir yfir á, því misræmi þýðir að önnur regla passaði fyrst. Eitt athugað flæði sker úr meira en ein síða af stillingalestri.

Haldið poolinu, þýdda netfanginu og nafni viðmótsins saman í breytingaskránni. Regla sem er rétt fyrir eitt poól þýðir það næsta rangt.

Tengdir greinar