Behein de OpenVPN-SNAT-regel foar’t er nginx brekt

Twa flaters komme hieltiten fan itselde soart host. Yn ’e earste ferifiearje kliïnten en berikke dan neat foarby de tunnel. Yn ’e twadde komt de VPN omheech en de eigen website fan ’e server hâldt op mei antwurdzjen, wat de meast alaarmearjende is om’t it op kollaterale skea liket. Op in container-basearre VPS liede beide meastentiids werom nei deselde koarte list fan kontrôles, en de folchoarder is wichtich: apparaat earst, oersetting twadde, omfang tredde.

Kontrolearje dat de container in tun-apparaat oanmeitsje kin

Neat oars is fan belang as de tunnel-ynterface net bestean kin. Kontrolearje dat /dev/net/tun oanwêzich is en dat it oanmeitsjen fan in testapparaat slagget, om’t in protte providers tun yn containers standert útskeakelje. Gjin firewall-wurk kompensearret in apparaat dat nea makke is.

As it apparaat mist, kin allinnich de host of de provider it ynskeakelje. In oar plan is faak goedkeaper as in iepen stipe-tried dy’t in wike duorret. Befêstigje dit foardat jo ien rigel fan it OpenVPN-log lêze. Oars bringe jo de jûn troch mei it bystellen fan regels dy’t nea in pakket sille sjen.

Bepale wat MASQUERADE op dit ynterface docht

Op in gewoane firtuele masine is de gewoane útgongsregel POSTROUTING MASQUERADE út it haadynterface. Yn in OpenVZ-container is it sichtbere apparaat faak venet0, in troch de host beheare firtueel ynterface yn stee fan in rûtele NIC, en MASQUERADE draacht him dêr net altyd sa’t tutorials oannimme.

De wurkber foarm is eksplisite oersetting nei it adres dat kliïnten al berikke, mei trochstjoeren tastien yn beide rjochtingen. It ferfangen fan ’e pool út ’e serverkonfiguraasje is like wichtich as it ferfangen fan it adres. Lês elke rigel foardat jo him plakke.

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

Sûnder de trochstjoerregels bart de oersetting noch altyd en wegeret de kernel noch altyd troch te stjoeren. Dy kombinaasje makket de betiizjende tastân dêr’t tellers op ’e NAT-regel omheech geane wylst de kliïnt neat ûntfangt. De twa FORWARD-rigels moatte ek foar elke brede drop-regel yn deselde keten stean. Oarder is diel fan ’e konfiguraasje, gjin ymplemintaasjedetail.

Behein de regel ta ien pool en ien ynterface

It twadde symptoom hat in oare oarsaak: in POSTROUTING-regel sûnder boarne- of útgongsbeheining. Sa’n regel skriuwt elk pakket oer dat de host ferlit.

Tsjinsten dy’t fan ’e oarspronklike boarne ôfhinklik binne, dogge it dan ferkeard. In webserver efter in lokale proxy kin ophâlde mei antwurdzjen, en him opnij starte feroaret neat om’t de regel noch altyd yn ’e dyk sit. Ferfeark dat de host nei syn eigen iepenbiere adres stjoert, wurdt ek rekke, en dêrom kin de flater op in DNS- of sertifikaatprobleem lykje yn stee fan in firewall-probleem. De regel is hast wis tafoege om it earste symptoom te ferhelpen.

De oplossing is de oerienkomst te fernearenjen ta de tunnelpool en it útgongsynterface, en dan ien regel per pool ta te foegjen yn stee fan ien regel te ferbreedzjen om ferskate te dekken.

Meitsje de regels duorsum en fyn út wa’t se noch mear hat

Mei de hân tafoege regels ferdwine by it opnij opstarten, bewarje se dêrom mei iptables-save of behear se fia netfilter-persistent wêr’t dat ynstallearre is. Befêstigje dat it weromsetten rint foardat OpenVPN start. Start dan ien kear mei opsetsin opnij yn stee fan it gat ûnder in ynsidint te ûntdekken.

Op in containerhost, befêstigje ek dat it duorsumheidsbestân yn skriuwbere containeropslach libbet en dat de provider it filterjen by it opstarten net ferfangt. Guon platfoarms beheare belied bûten de container, dêr’t lokale regels of negearre wurde of fjochtsje mei dy fan ’e host sels.

Ferifiearje mei tellers en ien fêstleine stream

Fan in ferbûne kliïnt, kontrolearje it iepenbiere adres dat in eksterne tsjinst rapportearret. As it oerienkomt mei it adres fan ’e server, wurket de oersetting; as net, ferlit it pakket fia in oare dyk of ferlit hielendal net. Test dan sawol in tsjinst op ’e server as ien op it iepenbiere ynternet, om’t dy ferskate diken nimme troch deselde regelset.

Op ’e server, lês de pakkettellers op ’e NAT- en FORWARD-regels mei iptables -t nat -L -v -n en besjoch ien stream yn in opname. As it adres fan ’e kliïnt yn ’e opname ferskynt en der folget gjin antwurd, dan sit it gat op ’e weromwei of yn it filterjen fan ’e provider, net yn it kliïntprofyl. Ferlykje de fêstleine boarne mei it adres dêr’t de regel nei oerset, om’t in mismatch betsjut dat in oare regel earst oerienkaam. Ien observearre stream beslist mear as in side konfiguraasje lêze.

Hâld de pool, it oersette adres en de namme fan it ynterface byinoar yn it feroaringsregister. In regel dy’t foar ien pool korrekt is, oerset de folgjende ferkeard.