Omejite pravilo SNAT za OpenVPN, preden pokvari nginx
Odjemalci se overijo, a nič se ne usmerja, ali pa stran po vzpostavitvi VPN umre. Preverite dostop do tun in nato omejite prevajanje na pool in en vmesnik.
Dve napaki prihajata vedno z iste vrste gostitelja. V prvi se odjemalci overijo in nato ne dosežejo ničesar za tunelom. V drugi se VPN dvigne in lastna spletna stran strežnika preneha odgovarjati, kar je bolj zaskrbljujoče, ker je videti kot stranska škoda. Na VPS, ki temelji na vsebnikih, se oboje običajno vrne na isti kratek seznam preverjanj, in vrstni red je pomemben: najprej naprava, nato prevajanje, nazadnje obseg.
Preverite, ali lahko vsebnik ustvari napravo tun
Nič drugega ni pomembno, če vmesnik tunela ne more obstajati. Preverite, ali je /dev/net/tun prisoten in ali ustvarjanje preskusne naprave uspe, ker mnogi ponudniki v vsebnikih privzeto izklopijo tun. Nobeno delo s firewallom ne nadomesti naprave, ki ni bila nikoli ustvarjena.
Če naprave ni, jo lahko omogočita le gostitelj ali ponudnik. Drug načrt je pogosto cenejši od odprte podporne niti, ki traja teden dni. To potrdite, preden preberete eno samo vrstico dnevnika OpenVPN. Sicer boste večer preživeli z nastavljanjem pravil, ki ne bodo nikoli videla paketa.
Odločite, kaj MASQUERADE počne na tem vmesniku
Na običajnem navideznem stroju je običajno pravilo odhoda POSTROUTING MASQUERADE iz glavnega vmesnika. V vsebniku OpenVZ je vidna naprava pogosto venet0, navidezni vmesnik, ki ga upravlja gostitelj, in ne usmerjena mrežna kartica, MASQUERADE pa se tam ne obnaša vedno tako, kot predvidevajo vadnice.
Delujoča oblika je izrecno prevajanje na naslov, ki ga odjemalci že dosežejo, s prepuščanjem dovoljenim v obe smeri. Zamenjava pool iz konfiguracije strežnika je enako pomembna kot zamenjava naslova. Preberite vsako vrstico, preden jo prilepite.
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 ACCEPTBrez pravil za prepuščanje se prevajanje še vedno dogaja in jedro še vedno zavrača prepuščanje. Ta kombinacija ustvari zbegano stanje, v katerem števci na pravilu NAT naraščajo, medtem ko odjemalec ne prejme ničesar. Tudi dve vrstici FORWARD morata stati pred vsakim širokim pravilom drop v isti verigi. Vrstni red je del konfiguracije, ne podrobnost izvedbe.
Omejite pravilo na en pool in en vmesnik
Druga težava ima drug vzrok: pravilo POSTROUTING brez omejitve vira in brez omejitve izhoda. Takšno pravilo prepiše vsak paket, ki zapusti gostitelja.
Storitve, ki so odvisne od izvornega vira, se nato obnašajo napačno. Spletni strežnik za lokalnim posrednikom lahko preneha odgovarjati in ponovni zagon ne spremeni ničesar, ker je pravilo še vedno na poti. Prizadet je tudi promet, ki ga gostitelj pošilja na svoj javni naslov, zato je napaka lahko videti kot težava z DNS ali potrdilom, ne pa s firewallom. Pravilo je bilo skoraj zagotovo dodano, da odpravi prvi znak.
Rešitev je zožiti ujemanje na pool tunela in izhodni vmesnik, nato pa dodati eno pravilo na pool, namesto da bi eno pravilo razširili na več.
Naredite pravila trajna in ugotovite, kdo jih še ima v lasti
Pravila, dodana ročno, po ponovnem zagonu izginejo, zato jih shranite z iptables-save ali jih upravljajte prek netfilter-persistent tam, kjer je nameščen. Potrdite, da se obnovitev izvede pred zagonom OpenVPN. Nato enkrat namerno znova zaženite, namesto da bi vrzel odkrili med incidentom.
Na gostitelju vsebnikov tudi potrdite, da je datoteka trajnosti v zapisljivem shrambi vsebnika in da ponudnik ob zagonu ne zamenja filtriranja. Nekatere platforme upravljajo politiko zunaj vsebnika, kjer se lokalna pravila bodisi ignorirajo bodisi bijejo z lastnimi pravili gostitelja.
Preverite s števci in enim zajetim tokom
S povezanega odjemalca preverite javni naslov, ki ga sporoča zunanja storitev. Če se ujema z naslovom strežnika, prevajanje deluje; če ne, paket odhaja po drugi poti ali sploh ne odhaja. Nato preskusite storitev, gostovano na strežniku, in storitev na javnem internetu, ker gresta po različnih poteh skozi isti nabor pravil.
Na strežniku preberite števce paketov na pravilih NAT in FORWARD s iptables -t nat -L -v -n in opazujte en tok v zajemu. Če se naslov odjemalca pojavi v zajemu in odgovora ni, je vrzel na povratni poti ali v filtriranju ponudnika, ne v profilu odjemalca. Primerjajte zajeti vir z naslovom, na katerega prevaja pravilo, ker neskladje pomeni, da se je najprej ujemalo drugo pravilo. En opazovan tok razreši več kot stran branja konfiguracije.
Držite pool, prevedeni naslov in ime vmesnika skupaj v zapisu sprememb. Pravilo, ki je pravilno za en pool, napačno prevede naslednjega.