Begrenzt d’OpenVPN-SNAT-Reeg, ier se nginx bricht

Zwee Feeler kommen ëmmer erëm vum selwechten Typ Host. Am éischten authentifizéiere sech d’Cliente an erreechen duerno näischt iwwer den Tunnel eraus. Am zweeten kënnt de VPN erop an d’Websäit vum Server selwer äntwert net méi, wat dat alarmantst ass, well et wéi Kollateralsschued ausgesäit. Op engem containerbaséierte VPS ginn déi zwee normalerweis op déiselwecht kuerz Lëscht vu Kontrollen zeréck, an d’Reiefolleg ass wichteg: d’Apparat fir d’éischt, d’Iwwersetzung duerno, de Beräich zum Schluss.

Bestätegt, datt de Container en tun-Apparat ka erstellen

Näischt anescht ass wichteg, wann d’Tunnel-Interface net ka existéieren. Préift, datt /dev/net/tun do ass an datt d’Erstelle vun engem Testapparat geléngt, well vill Fournisseuren den tun an Containere standardméisseg desaktivéieren. Keng Aarbecht um firewall kompenséiert en Apparat, deen ni erstallt gouf.

Wann den Apparat feelt, kann nëmmen den Host oder de Fournisseur en aktivéieren. En anere Plang ass dacks méi bëlleg wéi en oppene Supportthread, deen eng Woch dauert. Bestätegt dat, ier Dir eng eenzeg Zeil vum OpenVPN-Log liest. Soss verbréngt Dir den Owend domat, Reegelen ze justéieren, déi ni e Pak gesinn.

Entscheet, wat MASQUERADE op dëser Interface mécht

Op enger gewéinlecher virtueller Maschinn ass déi gewéinlech Ausgangsreegel POSTROUTING MASQUERADE aus der Haaptinterface. An engem OpenVZ-Container ass den sichtbaren Apparat dacks venet0, eng hostverwalt virtuell Interface amplaz enger gerouteter NIC, an MASQUERADE verhält sech do net ëmmer sou, wéi Tutoriale viraussetzen.

Déi praktikabel Form ass eng explizit Iwwersetzung op d’Adress, déi d’Cliente schonn erreechen, mat erlaabter Weiderleitung an zwou Richtungen. De Pool aus der Serverkonfiguratioun ze ersetzen ass esou wichteg wéi d’Adress ze ersetzen. Liest all Zeil, ier Dir se affügt.

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

Ouni d’Weiderleitungsreegele geschitt d’Iwwersetzung nach ëmmer an de Kernel refuséiert nach ëmmer weiderzeleeden. Déi Kombinatioun erzeugt de verwirrenden Zoustand, an deem d’Zieler op der NAT-Reeg klammen, während de Client näischt kritt. Déi zwou FORWARD-Zeile mussen och virun all breeder drop-Reeg an der selwechter Kette stoen. D’Reiefolleg ass Deel vun der Konfiguratioun, keen Implementatiounsdetail.

Begrenzt d’Reeg op ee Pool an eng Interface

Dat zweet Symptom huet eng aner Ursaach: eng POSTROUTING-Reeg ouni Quell- an ouni Ausgangsbegrenzung. Esou eng Reeg schreift all Pak ëm, deen den Host verléisst.

D’Servicer, déi op déi ursprénglech Quell ugewise sinn, verhale sech duerno falsch. E Webserver hannert engem lokale Proxy kann ophalen ze äntweren, an en Neistart ännert näischt, well d’Reeg nach ëmmer am Wee ass. Och den Traffic, deen den Host op seng eegen ëffentlech Adress schéckt, ass betraff, dofir kann de Feeler wéi en DNS- oder Zertifikatsproblem ausgesinn an net wéi e firewall-Problem. D’Reeg gouf bal sécher derbäigemaach, fir dat éischt Symptom ze behiewen.

D’Léisung ass, d’Iwwereneestëmmung op den Tunnelpool an d’Ausgangsinterface ze verengen, an dann eng Reeg pro Pool derbäizesetzen, amplaz eng eenzeg Reeg ze verbreeden, fir méi ze decken.

Maacht d’Reegele persistent a fannt eraus, wien nach se besëtzt

Reegele vun Hand derbäigemaach verschwannen beim Neistart, also späichert se mat iptables-save oder verwalt se iwwer netfilter-persistent, wou en installéiert ass. Bestätegt, datt d’Restauratioun leeft, ier OpenVPN ufänkt. Start dann eng Kéier bewosst nei, amplaz de Gruef während engem Incident ze entdecken.

Op engem Containerhost bestätegt och, datt d’Persistenzdatei am schreifbaren Containerspäicher läit an datt de Fournisseur d’Filterung beim Booten net ersetzt. E puer Plattforme verwalten d’Politik ausserhalb vum Container, wou lokal Reegelen entweder ignoréiert ginn oder mat deene vum Host selwer kollidéieren.

Verifizéiert mat Zieler an engem opgehollene Floss

Vun engem verbonnenen Client préift d’ëffentlech Adress, déi en externen Service mellt. Wann se mat der Adress vum Server iwwerenee stëmmt, funktionéiert d’Iwwersetzung; wann net, verléisst de Pak den Host iwwer en anere Wee oder verléisst en iwwerhaapt net. Test dann souwuel e Service, deen um Server gehost gëtt, wéi och een um ëffentlechen Internet, well se iwwer verschidde Weeër duerch déiselwecht Reegele ginn.

Liest um Server d’Pakzieler op den NAT- an FORWARD-Reegele mat iptables -t nat -L -v -n a beobachtet ee Floss an enger Opnam. Wann d’Adress vum Client an der Opnam erschéngt an keng Äntwert duerno kënnt, ass de Gruef um Réckwee oder an der Filterung vum Fournisseur, net am Clientprofil. Vergläicht d’opgehollen Quell mat der Adress, op déi d’Reeg iwwersetzt, well eng Ongereimtheet heescht, datt eng aner Reeg als éischt gepasst huet. Een observéierte Floss entscheet méi wéi eng Säit Konfiguratiounslieserei.

Halt den Pool, d’iwwersat Adress an den Numm vun der Interface beienee am Ännerungsprotokoll. Eng Reeg, déi fir ee Pool richteg ass, iwwersetzt déi nächst falsch.