Beperk die OpenVPN-SNAT-reël voordat dit nginx breek

Twee foute bly opduik by dieselfde soort gasheer. In die eerste geval verifieer kliënte en bereik dan niks verby die tonnel nie. In die tweede geval kom die VPN op en die bediener se eie webwerf hou op om te antwoord, wat die mees kommerwekkende een is omdat dit na byskade lyk. Op ’n houer-gebaseerde VPS herlei albei gewoonlik na dieselfde kort lys kontroles, en die orde maak saak: toestel eerste, vertaling tweede, omvang derde.

Bevestig dat die houer ’n tun-toestel kan skep

Niks anders maak saak as die tonnelkoppelvlak nie kan bestaan nie. Kontroleer dat /dev/net/tun teenwoordig is en dat die skep van ’n toetsapparaat slaag, want baie verskaffers skakel tun in houers by verstek af. Geen hoeveelheid firewall-werk vergoed vir ’n toestel wat nooit geskep is nie.

As die toestel ontbreek, kan net die gasheer of die verskaffer dit aktiveer. ’n Ander plan is dikwels goedkoper as ’n oop ondersteuningsdraad wat ’n week duur. Bevestig dit voordat jy ’n enkele OpenVPN-logreël lees. Andersins spandeer jy die aand aan die instel van reëls wat nooit ’n pakkie sal sien nie.

Bepaal wat MASQUERADE op hierdie koppelvlak doen

Op ’n gewone virtuele masjien is die gebruiklike uitgangsreël gewoonlik ’n POSTROUTING MASQUERADE uit die hoofkoppelvlak. In ’n OpenVZ-houer is die sigbare toestel dikwels venet0, ’n gasheer-bestuurde virtuele koppelvlak eerder as ’n gerouteerde NIC, en MASQUERADE gedra hom nie altyd daar soos handleidings aanneem nie.

Die werkbare vorm is eksplisiete vertaling na die adres wat kliënte reeds bereik, met deurstuur in beide rigtings toegelaat. Die vervanging van die poel uit die bedienerkonfigurasie maak net soveel saak as die vervanging van die adres. Lees elke reël voordat jy dit plak.

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

Sonder die deurstuur-reëls gebeur die vertaling steeds en die kernel weier steeds om te deurstuur. Daardie kombinasie skep die verwarrende toestand waar tellers op die NAT-reël klim terwyl die kliënt niks ontvang nie. Die twee FORWARD-reëls moet ook voor enige breë drop-reël in dieselfde ketting staan. Orde is deel van die konfigurasie, nie ’n implementeringsbesonderheid nie.

Beperk die reël tot een poel en een koppelvlak

Die tweede simptoom het ’n ander oorsaak: ’n POSTROUTING-reël sonder ’n bron- of ’n uitvoerbeperking. So ’n reël herskryf elke pakkie wat die gasheer verlaat.

Dienste wat op die oorspronklike bron staatmaak, gedra hom dan verkeerd. ’n Webserver agter ’n plaaslike instaanbediener kan ophou antwoord, en om dit te herbegin verander niks omdat die reël steeds in die pad is. Verkeer wat die gasheer na sy eie publieke adres stuur, word ook geraak, en daarom kan die fout na ’n DNS- of sertifikaatprobleem lyk eerder as ’n firewall-een. Die reël is byna seker bygevoeg om die eerste simptoom op te los.

Die oplossing is om die passing tot die tonnelpoel en die uitgangskoppelvlak te vernou, en dan een reël per poel by te voeg eerder as om ’n enkele reël te verbreed om verskeie te dek.

Maak die reëls blywend en vind uit wie anders hulle besit

Handmatig bygevoegde reëls verdwyn by herlaai, so stoor hulle met iptables-save of bestuur hulle deur netfilter-persistent waar dit geïnstalleer is. Bevestig dat die herstel voor OpenVPN begin hardloop. Herlaai dan een keer doelbewus eerder as om die gaping tydens ’n voorval te ontdek.

Op ’n houergasheer, bevestig ook dat die blywendheidslêer in beskryfbare houerberging woon en dat die verskaffer nie filtering by selflaai vervang nie. Sommige platforme bestuur beleid buite die houer, waar plaaslike reëls óf geïgnoreer word óf met die gasheer se eie stryd.

Verifieer met tellers en een vasgevangde stroom

Vanaf ’n gekoppelde kliënt, kontroleer die publieke adres wat ’n eksterne diens rapporteer. As dit met die bediener se adres ooreenstem, werk die vertaling; as dit nie doen nie, verlaat die pakkie via ’n ander pad of verlaat glad nie. Toets dan beide ’n diens wat op die bediener gehuisves word en een op die publieke internet, want dié neem verskillende paaie deur dieselfde reëlstel.

Op die bediener, lees die pakkietellers op die NAT- en FORWARD-reëls met iptables -t nat -L -v -n en kyk na een stroom in ’n opname. As die kliënt se adres in die opname verskyn en geen antwoord volg nie, is die gaping op die terugpad of in verskafferfiltering eerder as in die kliëntprofiel. Vergelyk die vasgevangde bron met die adres waarna die reël vertaal, want ’n wanverhouding beteken ’n ander reël het eerste gepas. Een waargenome stroom besleg meer as ’n bladsy konfigurasielees.

Hou die poel, die vertaalde adres en die koppelvlaknaam saam in die veranderingsrekord. ’n Reël wat vir een poel korrek is, vertaal die volgende een verkeerd.